OWASP - User contributions [en]

Category:Java

2016-11-04T17:26:16Z

Ari Elias-Bachrach: /* Validation */ adding apache commons validator

= Main =
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

== About ==

The OWASP Java™ and JVM Technology Knowledge Base is the clearing house for all information related to building secure web/distributed applications and services based on Java and JVM technologies. The focus of these pages is on guidance for developers and architects using Java frameworks and JVM based technologies for web application development, on OWASP components that use Java and on participation in OWASP projects that use Java and JVM technologies. Moreover, we aim to provide security related guidance for system administrators managing Java and JVM based applications and tools.

The project is not limited to Java. It aims to also address topics around the JVM in general.

Community content is key to security information. The project depends on content from developers throughout the Java and JVM ecosystem.

==Purpose==

* Provide deep, rich guidance for Java developers in using the security features of Java and of Java frameworks.
* Address security in relation to the Java Virtual Machine and derived technologies.
* Guide system administrators in managing Java and JVM related components and applications.
* Create guidance for use of OWASP components that are designed for use with Java or other JVM languages.
* Focus on information about working with and on OWASP tools built using Java or other JVM technologies.
* Provide a stream of security related information, like vulnerabilities and security patches, related to the Java and JVM universe.
* Build an ecosystem allowing to all actors interested to discuss, share and learn.

== Licensing ==

OWASP Java™ and JVM Technology Knowledge Base is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Oracle® and Java™ are [http://www.oracle.com/us/legal/trademarks/index.html|registered trademarks of Oracle] and/or its affiliates. Other names may be trademarks of their respective owners.

== What's Hot! ==

See the "Tasks and Roadmap" tab for more information.

[[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2015/2016]]

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

[[File:OWASP_Java_Wiki_logo.png|frame]]

<br/>

== Meta ==

Last Update: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

<br/>

== Other Resources ==

[http://lists.owasp.org/mailman/listinfo/java-project Mailing List]

[https://github.com/owasp GitHub (OWASP)]

<br/>

== Related Projects ==

* [[OWASP_Project|OWASP Project Repository]]
* [[Language|Languages Repository]]
* [[OWASP_.NET_Project|.NET Project]]
* [[Ruby|Ruby]]
* [[PHP|PHP]]
* [[Perl|Perl]]
* [[Python|Python]]
* [[JavaScript|JavaScript]]
* [[C/C++|C/C++]]
* [[SQL|SQL, PL/SQL, DB Scripting]]
* [[OWASP_Internet_of_Things_Project|OWASP IoT Security]]
* [[OWASP_Mobile_Security_Project|OWASP Mobile Security]]

|}

= Related OWASP Projects =

== Security Tools ==

{| width="100%"
| colspan="2" | [[OWASP_Dependency_Check|OWASP Dependency Check]]
|-
| width="20" |  
| Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently <b>Java</b>, .NET, Ruby, Node.js, and Python projects are supported.
|-
| colspan="2" | [[OWASP_SonarQube_Project|OWASP SonarQube Project]]
|-
| width="20" |  
| The first goal of the OWASP SonarQube Project is to a create a referential of check specifications targeting OWASP vulnerabilities that can be detected by SAST tools (Static Application Security Testing). From there, the second goal is to provide a reference implementations of most of those checks in the Open Source SonarQube language analyzers (<b>Java</b>, JavaScript, PHP and C#). SonarQube is an Open Source platform for managing code quality.
|}

== Secure Coding Libraries ==

{| width="100%"
|-
| colspan="2" | [[OWASP_AppSensor_Project|OWASP AppSensor]]
|-
| width="20" |  
| The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.
|-
| colspan="2" | [[CSRFGuard|OWASP CSRFGuard]]
|-
| width="20" |  
| CSRFGuard is a Java library that implements a variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.
|-
| colspan="2" | [[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]]
|-
| width="20" |  
| The OWASP Java Encoder is a Java 1.5+ simple-to-use drop-in high-performance encoder class with no dependencies and little baggage. This project will help Java web developers defend against Cross Site Scripting.
|-
| colspan="2" | [[OWASP_Java_HTML_Sanitizer|OWASP Java HTML Sanitizer]]
|-
| width="20" |  
| The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS.
|-
| colspan="2" | [[OWASP_Security_Logging_Project|OWASP Security Logging Project]]
|-
| width="20" |  
| The OWASP Security Logging project provides developers and ops personnel with APIs for logging security-related events. The aim is to let developers use the same set of logging APIs they are already familiar with from over a decade of experience with Log4J and its successors, while also adding powerful security features.
|-
| colspan="2" | [[OWASP_ESAPI|OWASP Enterprise Security API (ESAPI)]]
|-
| width="20" |  
| ESAPI (The OWASP Enterprise Security API) for Java is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. This project has seen major updates as recently as February 2016.
|}

== General Documents ==

{| width="100%"
| [[OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
| [[OWASP_Codes_of_Conduct|OWASP Codes of Conduct]]
| [[Cheat_Sheets|OWASP Cheat Sheets Series]]
|-
| [[OWASP_Testing_Project|OWASP Testing Project]]
| [[OWASP_Top_Ten_Project|OWASP Web Top 10]]
| [[OWASP_Vulnerable_Web_Applications_Directory_Project|OWASP Vulnerable Web Applications Directory]]
|}

= Related 3rd Party Projects =

A list of third party (i.e. not part of Java SE or EE) security frameworks. This page contains a list of Java security libraries and frameworks and indicates which security features each library supports.

==Enterprise==
* [http://shiro.apache.org/ Apache Shiro] is a Java security framework that performs authentication, authorization, cryptography, and session management.
* [http://projects.spring.io/spring-security/ Spring Security] provides security services for Java EE-based enterprise software applications. Services include authentication, authorization and protection against attacks like session fixation, clickjacking and cross site request forgery.
* [http://www.hdiv.org/ HDIV] A web application security framework that provides a number of functions.

== Access Control (Authentication and Authorization) ==
* [http://oaccframework.org/ OACC] is an application security framework for Java designed for fine grained (object level) access control. OACC uses the abstraction of a ''resource'' for the application objects being secured. This key abstraction enables OACC to provide a rich API that includes grant, revoke and query capabilities for storing and managing the application's security relationships.
* [http://picketlink.org/appsecurity/ PicketLink] provides authentication, single sign on, permission based access control and other security features.

== Encryption ==
* [https://github.com/google/keyczar Keyczar] is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys.
* [http://www.bouncycastle.org/ Bouncycastle] is a lightweight Java cryptography API <i>provider</i>.
* [http://www.jasypt.org/ Jasypt] is a Java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

== XML Security ==
* The [http://santuario.apache.org/ Apache Santuario] project is aimed at providing implementation of the primary security standards for XML: XML-Signature Syntax and Processing and XML Encryption Syntax and Processing.

== Validation ==
* [http://www.sapia-oss.org/projects/vlad/home.html Vlad] stands for "validation". This projects indeed aims at offering a simple, high-level, extensible, generic validation framework that can easily be integrated into existing applications.
* [https://www.owasp.org/index.php/Protect_FileUpload_Against_Malicious_File This OWASP article] and [https://github.com/righettod/document-upload-protection code snippet] proposes a way to protect a file upload feature against submission of files that may contain malicious code.
* [http://commons.apache.org/proper/commons-validator/ The Apache Common's validator] can be used to perform validation.

= Resources =

== Mailing List ==

[http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Technologies Mailing List]

== Code Repository ==

[https://github.com/owasp GitHub OWASP Global Repository]

== Related Project Resources ==

[[OWASP_Project|OWASP Project Repository]]

[[Language|Languages Repository]]

[[OWASP_.NET_Project|.NET Project]]

[[Ruby|Ruby Technology Knowledge Base]]

[[PHP|PHP Technology Knowledge Base]]

[[Perl|Perl Technology Knowledge Base]]

[[Python|Python Technology Knowledge Base]]

[[JavaScript|JavaScript Technology Knowledge Base]]

[[C/C++|C/C++ Technology Knowledge Base]]

[[SQL|SQL, PL/SQL and DB Scripting Technology Knowledge Base]]

[[OWASP_Internet_of_Things_Project|OWASP IoT Security Project]]

[[OWASP_Mobile_Security_Project|OWASP Mobile Security Project]]

= Tasks and Roadmap =

== Roadmap ==

* [[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2016]] General review of all Java and JVM related pages in the wiki.
* Build Java and JVM security related net resources guide
* The OWASP Java and JVM Technology Knowledge Base is principally about creating deep, rich guidance for Java and JVM developers using all kind of security resources. The idea is to have an effort of building a internet resource guide for everything around the JVM universe. Information, blogs, articles, tools, test servers and more. Important however is that this list is seriously curated.
* Concrete guideline for Java and JVM developers
* Clear checklists, around various topics, language, servers and frameworks.

<br/>

= Get involved =

The first step would be to establish contact with the project leaders and/or the entire team. This can be done using a direct and private message, or by joining the public mailing list to say hello.

When it comes to participating in project activities, everything depends on the time you are willing and able to invest. It is however very important to not jump into too many things at the beginning, later having to back out or to let unfinished things behind you. It is much better to start with small tasks, increasing intensity and investment over time.

Please also be patient with expecting the "merge" of your work into the existing project pages and code. As everywhere in live, trust has to be built-up.

The Java and JVM knowledge base has currently multiple tasks open, which can be found on the adequate section of this page. Not all tasks require a wiki account. Please take something you are interested in and start participating. Work load is not the only outcome when participating in open projects. You are getting a lot of things back: recognition, satisfaction, knowledge and contacts, sometime friends.

Sounds cool? Then jump in...

To get involved join the mailing list, follow this link: [http://lists.owasp.org/mailman/listinfo/java-project OWASP Java and JVM Mailing List]

= Archives =

The previous version of this JAVA Project home page is archived here: [[OWASP Java Project Archive (8.2010)]]

<br/>

<hr/>

__NOTOC__
<headertabs />

<br/>

'''IMPORTANT: all pages of these project are currently under review. A lot are outdated and are in the process of being removed or updated.''' The review effort is coordinated on this page: [[OWASP Java Project WIPRO 1 2015|Wiki Pages Review Operation - 2015/2016]].

(The pages in the "old" category "OWASP Java Project" have to be moved into the category "Java". Work is in progress).

<categorytree mode=pages>OWASP Java Project</categorytree>



[[Category:Technology]]
[[Category:Language]]

Cross-Site Request Forgery (CSRF)

2016-11-02T17:19:55Z

Ari Elias-Bachrach: /* Related Security Activities */ contraction needs an apostophe

{{Template:Attack}}

[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

==Related Security Activities==

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues|review code for CSRF vulnerabilities]].

===How to Test for CSRF Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing_for_CSRF_(OTG-SESS-005)|test for CSRF vulnerabilities]].

===How to Prevent CSRF Vulnerabilities===

See the [[CSRF Prevention Cheat Sheet]] for prevention measures.

Listen to the [http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3 OWASP Top Ten CSRF Podcast].

Most frameworks have built-in CSRF support such as [http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms Joomla], [http://blog.eyallupu.com/2012/04/csrf-defense-in-spring-mvc-31.html Spring], [http://web.securityinnovation.com/appsec-weekly/blog/bid/84318/Cross-Site-Request-Forgery-CSRF-Prevention-Using-Struts-2 Struts], [http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf Ruby on Rails], [http://www.troyhunt.com/2010/11/owasp-top-10-for-net-developers-part-5.html .NET] and others.

Use [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]] to add CSRF protection to your Java applications. You can use [[CSRFProtector Project]] to protect your php applications or any project deployed using Apache Server. There is a [[.Net CSRF Guard]] at OWASP as well, but it's old and doesn't look complete.

John Melton also has an [http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/ excellent blog post] describing how to use the native anti-CSRF functionality of the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI].

==Description==

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.

CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests.

It's sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called "stored CSRF flaws". This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

=== Synonyms ===

CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

=== Prevention measures that do '''NOT''' work ===

== Using a secret cookie ==
Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

== Only accepting POST requests ==
Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker's Website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks the form will do something else.

A number of flawed ideas for defending against CSRF attacks have been developed over time. Here are a few that we recommend you avoid.

== Multi-Step Transactions ==

Multi-Step transactions are not an adequate prevention of CSRF. As long as an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.

== URL Rewriting ==

This might be seen as a useful CSRF prevention technique as the attacker cannot guess the victim's session ID. However, the user’s session ID is exposed in the URL. We don't recommend fixing one security flaw by introducing another.

== HTTPS ==

HTTPS does nothing to defend against CSRF.

==Examples==

===How does the attack work?===

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using the ''bank.com'' web application that is vulnerable to CSRF. Maria, an attacker, wants to trick Alice into sending the money to her instead. The attack will comprise the following steps:

# building an exploit URL or script
# tricking Alice into executing the action with [[Social Engineering|social engineering]]

====GET scenario====

If the application was designed to primarily use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following exploit URL which will transfer $100,000 from Alice's account to her account. She takes the original command URL and replaces the beneficiary name with herself, raising the transfer amount significantly at the same time:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

The [[Social Engineering|social engineering]] aspect of the attack tricks Alice into loading this URL when she's logged into the bank application. This is usually done with one of the following techniques:

* sending an unsolicited email with HTML content
* planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking

The exploit URL can be disguised as an ordinary link, encouraging the victim to click it:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Or as a 0x0 fake image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0"></nowiki>

If this image tag were included in the email, Alice wouldn't see anything. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

A real life example of CSRF attack on an application using GET was a [http://xs-sniper.com/blog/2008/04/21/csrf-pwns-your-box/ uTorrent exploit] from 2008 that was used on a mass scale to download malware.

====POST scenario====

The only difference between GET and POST attacks is how the attack is being executed by the victim. Let's assume the bank now uses POST and the vulnerable request looks like this:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1

acct=BOB&amount=100

Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tag:

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>
</form>

This form will require the user to click on the submit button, but this can be also executed automatically using JavaScript:

<body onload="document.forms[0].submit()">
<form...

====Other HTTP methods====

Modern web application APIs frequently use other HTTP methods, such as PUT or DELETE. Let's assume the vulnerable bank uses PUT that takes a JSON block as an argument:

PUT <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1

{ "acct":"BOB", "amount":100 }

Such requests can be executed with JavaScript embedded into an exploit page:

<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","<nowiki>http://bank.com/transfer.do</nowiki>",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"acct":"BOB", "amount":100}));
}
</script>
<body onload="put()">

Fortunately, this request will '''not''' be executed by modern web browsers thanks to [[Same-Origin Policy|same-origin policy]] restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker's (or everyone's) origin by using [[HTML5 Security Cheat Sheet#Cross_Origin_Resource_Sharing|CORS]] with the following header:

Access-Control-Allow-Origin: *


==Related [[Attacks]]==

* [[Cross-site Scripting (XSS)]]
* [[Cross Site History Manipulation (XSHM)]]


==Related [[Controls]]==

* Add a per-request nonce to the URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (e.g., Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* Add a hash (session id, function name, server-side secret) to all forms.
* For .NET, add a session identifier to ViewState with MAC (described in detail in [[Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Viewstate_(ASP.NET) | the CSRF Prevention Cheat Sheet]]).
* Checking the referrer header in the client's HTTP request can prevent CSRF attacks. Ensuring that the HTTP request has come from the original site means that attacks from other sites will not function. It is very common to see referrer header checks used on embedded network hardware due to memory limitations.
** XSS can be used to bypass both referrer and token based checks simultaneously. For instance, the [http://en.wikipedia.org/wiki/Samy_%28computer_worm%29 Samy worm] used an [[XHR]] to obtain the CSRF token to forge requests.
* "Although CSRF is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." --http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
* [[Tokenizing]]

==References==

* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.

* [http://owasp.org/index.php/CSRFProtector_Project OWASP CSRF Protector]
: a new anti CSRF method to mitigate CSRF in web applications. Currently implemented as a php library & Apache 2.x.x module

* [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf A Most-Neglected Fact About Cross Site Request Forgery (CSRF) ]
: Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.

* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.

* [http://code.google.com/p/pinata-csrf-tool/ Pinata-CSRF-Tool: CSRF POC tool]
: Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]
[[Category:Attack]]

Session Management Framework

2014-03-07T03:44:34Z

Ari Elias-Bachrach: created a start

=Session Management Framework=
==Overview==
Session management is an important underlying function in modern web applications. Keeping sessions secure is one of the most important things a framework must do to ensure that applications built on that framework do not suffer from security flaws.

==Session Data==
Session data should be stored server-side and never transmitted to the client unless necessary. The framework should also provide a simple and easy way for the developer to access, add, delete, or modify session data.

==Session ID==
===Generating===
The session ID should always be generated by the framework, and no other party should be able to manually select a session ID. The ID should be generated in a crytographically strong fashion. The session ID should always be generated based on random numbers, and it should never be created with any session specific or environment specific data.

===Storage===
The Session ID should be stored in a cookie which the client then submits to the server with every request. This cookie should have the HTTPONLY and SECURE flags set by default.

The framework should also provide an easy way for the developer to change the name of the session ID cookie to a custom value to avoid fingerprinting.

===Cookie rewriting===
URL rewriting is not recommended.

==Ending a session==
The framework should provide a simple method for a developer to remove a session. When that function is called, the session data itself should be purged from server memory, the session ID should no longer be kept as a valid ID, and the cookie should be removed from the client browser.

OWASP Security Frameworks Project

2014-03-07T03:33:56Z

Ari Elias-Bachrach: naming

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[Cheat Sheets]]
* [[OWASP Framework Security Project]]

| valign="top" style="padding-left:25px;width:200px;" |


== News and Events ==
* [22 Feb 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data Access Framework]]
* Password Storage
* Authentication Framework
* [[Session Management Framework]]
* Framework for Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-03-07T03:32:18Z

Ari Elias-Bachrach: wikifying link

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[Cheat Sheets]]
* [[OWASP Framework Security Project]]

| valign="top" style="padding-left:25px;width:200px;" |


== News and Events ==
* [22 Feb 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* [[Session Management]]
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-03-07T03:31:06Z

Ari Elias-Bachrach: fixing date

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[Cheat Sheets]]
* [[OWASP Framework Security Project]]

| valign="top" style="padding-left:25px;width:200px;" |


== News and Events ==
* [22 Feb 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* Session Management
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-02-26T03:35:06Z

Ari Elias-Bachrach: adding framework sec project

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[Cheat Sheets]]
* [[OWASP Framework Security Project]]

| valign="top" style="padding-left:25px;width:200px;" |


== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* Session Management
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Java Security Frameworks

2014-02-26T03:33:51Z

Ari Elias-Bachrach: adding hdiv

A list of third party (i.e. not part of Java SE or EE) security frameworks.

==Enterprise==
* [[ESAPI|OWASP Enterprise Security API]] a new OWASP project to provide all essential security services under one roof.
* [http://www.hdiv.org/ HDIV] A web application security framework that provides a number of functions.

== Access Control (Authentication and Authorisation) ==
* [http://sourceforge.net/projects/jguard jGuard] - jGuard is written in Java. Its goal is to provide a security framework based on JAAS (Java Authentication and Authorization Security). The framework is written for web and standalone applications, to easily provide solutions for access control problems.

== Encryption ==
* [http://www.bouncycastle.org/ Bouncycastle] - Lightweight Java cryptography APIs
* [http://www.jasypt.org/ Jasypt] - Jasypt is a java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of having deep knowledge on how cryptography works.

[[Category:OWASP Java Project]]

OWASP Security Frameworks Project

2014-02-23T06:32:58Z

Ari Elias-Bachrach: comment this out too

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[Cheat_Sheets]]

| valign="top" style="padding-left:25px;width:200px;" |


== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* Session Management
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-02-23T06:21:08Z

Ari Elias-Bachrach: just commenting this out till we get something useful to put there

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |


== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[OWASP_CISO_Survey]]
* [[Cheat_Sheets]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download when ready

== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* Session Management
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

Security Headers

2014-02-23T06:19:04Z

Ari Elias-Bachrach: first page for the project has been started

HTTP headers which should be included by default. Methods for modifying or removing the headers for specific instances should be provided, but by default there are secure settings which should be enabled unless there are other overriding concerns.
* X-Frame-Options: SAMEORIGIN [https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options|ref]
* X-XSS-Protection: 1; mode=block [http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx|ref]
* X-Content-Type-Options: nosniff
* Content-Type: text/html; charset=utf-8

Additionally, no headers should be included that needlessly divulge information about the server or it's configuration that an end user wouldn't need.

OWASP Security Frameworks Project

2014-02-23T06:05:24Z

Ari Elias-Bachrach: removing empty FAQ, adding content

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Security Frameworks Project? ==

OWASP Security Frameworks Project provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[OWASP_CISO_Survey]]
* [[Cheat_Sheets]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download when ready

== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=Security Frameworks=
List of guides:
* [[Data access]]
* Password Storage
* Authentication
* Session Management
* Handling Output
* [[Security Headers]]

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-02-23T05:13:46Z

Ari Elias-Bachrach: more updates

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Security Frameworks Project? ==

OWASP Security Frameworks Project provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

[[User:Ari_Elias-Bachrach|Ari Elias-Bachrach]]

== Related Projects ==

* [[OWASP_CISO_Survey]]
* [[Cheat_Sheets]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download when ready

== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
The OWASP security frameworks project is developed by a worldwide team of volunteers. The primary contributors to date have been:

* Ari Elias-Bachrach
* Mike McCabe
* Ken Johnson

==Others==
* your name here, just volunteer :-)

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of this project is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* volunteer to write (or help write) a design pattern document

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

OWASP Security Frameworks Project

2014-02-23T05:03:15Z

Ari Elias-Bachrach: added some text, cleanup

=Main=

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Security Frameworks==

The OWASP Security Frameworks Project is a series of design patterns that can be used by language designers and architects to create secure frameworks for developers, thereby relieving developers of the work of implementing security themselves.

==Introduction==

Providing a secure environment to a developer will lead to a more secure final product. Developers need to work in an environment which is secure by default and which relieves them of the burden of implementing their own security controls. That task often falls to the developers who create languages, or enterprise architects. We aim to create a library of design patterns and instructions that should be implemented by architects to create secure languages and environments for developers.

==Description==

The project aims to provide language independent advice targeted at enterprise architects and people who design programming languages. The intent is to make security functionality a part of the framework that a developer builds upon, so that the developer doesn't have to implement their own security functions. The ultimate goal is to have as much security as possible built into the programming environment so that developer mistakes and omissions are less likely to lead to security vulnerabilities.

==Licensing==
The OWASP Security Framework is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== What is the OWASP Security Frameworks Project? ==

OWASP Security Frameworks Project provides:

* xxx
* xxx

== Presentation ==

Link to presentation

== Project Leader ==

Ari Elias-Bachrach

== Related Projects ==

* [[OWASP_CISO_Survey]]

| valign="top" style="padding-left:25px;width:200px;" |

== Quick Download ==

* Link to page/download

== News and Events ==
* [22 Nov 2014] Project initiated

== In Print ==
This project can be purchased as a print on demand book from Lulu.com

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
|}

|}

=FAQs=

; Q1
: A1

; Q2
: A2

= Acknowledgements =
==Volunteers==
XXX is developed by a worldwide team of volunteers. The primary contributors to date have been:

* xxx
* xxx

==Others==
* xxx
* xxx

= Road Map and Getting Involved =
As of February 2014, the priorities are:

The plan is to develop a series of documents that cover the various features an architecture should provide. We'll have a document on XSS prevention, database access, authentication, CSRF prevention, etc. Each one will contain the design patterns that should be implemented in order to provide those functions in a secure manner. They'll each be free standing documents which can eventually be combined together into one large pdf or book when we're "done".

Involvement in the development and promotion of XXX is actively encouraged!
You do not have to be a security expert in order to contribute.
Some of the ways you can help:
* xxx
* xxx

=Project About=
{{:Projects/OWASP_Security_Frameworks_Project}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]

DN BOFinder

2014-02-07T15:55:12Z

Ari Elias-Bachrach: spelling

DN_BOFinder v0.2 - Feb 2007

The DN_BOFinder (DotNet Buffer Overflow Finder) is a semi-intelligent tool designed to find Buffer Overflows type vulnerabilities in COM objects used by .NET Assemblies (and mistakes in unsafe .Net code blocks).

This project was created by Dinis Cruz.

== Download ==

The latest version (0.2) can be downloaded from SourceForge: [http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=105632&release_id=519695]

==== Features ====

Here are some of its features:

* Supports fuzzing of individual methods, *.dll files and entire directories
* Works by using Reflection to create 'live instances' of classes and then fuzzing each of the exposed methods
* there are currently 16 different payloads for basic types (int, unint, char) and strings
* Fully automated use of cdb to find issues (i.e. you can start the fuzzer and go for lunch)
* use of an 'FuzzedMethods' list for each fuzzed dll to avoid re-fuzzing the same methods
* stored of exception information in an 'ExceptionData' file (per dll)
* use of an 'ExcludeList'to list the classes/methods that should be further analyzed
* auto detection of methods that consume large amounts of memory (currently set to 20M) and auto-detection of methods that 'hang' (some callbacks or windows pop-ups have this behaviour).The methods identified are automatically added to the 'ExcludeList'
* The results are current quite conservative (i.e. only the really bad exceptions are shown). this means that there might be several exploitable vulnerabilities that are currently reported as 'Normal CLR exception'
* A big blind spot at the moment is that the current version does not fuzz certain static methods (which can be invoked without need of a constructor (i.e. a live instance))
* When it finds an interface it tries to find who implements that interface and tries to create an instance of them (supports caching of objects for performance reasons). The problem here is that the class created is not documented, and ideally we should be fuzzing each of those implementations (especially in the cases where that Interface is used as a parameter)
* When in auto mode, it auto-restarts fuzzing session after a predefined number of seconds (this also helps in long fuzzing sessions since the process is refreshed regularly, which of course might also introduce some blind spots)

* Files:
** The binary (DN_BOFinder.exe) can be found on the DN_BOFinder_V0.2\binary folder
** The results will inside the DN_BOFinder_V0.2\binary\_fuzz_results folder (created on first run)
** The source code is in DN_BOFinder_V0.2\Source Code

====fuzzing modes====

There are 5 operational fuzzing modes:
* File ::: to Fuzz a file (in this mode a CLR crash will also crash the fuzzer)
* File Auto ::: to Fuzz a file automatically (in this mode new processes of DN_BOFinder are started in the 'File' Mode under cdb (Microsoft's Command Line Debugger). The cdb output is analyzed for unhandled exception data which when discovered is appended to the 'ExepctionData'
* Dir ::: to fuzz directories (basically invoking 'File Auto' for each *.dll in the target directory
* Method ::: to fuzz a method directly
* Method Auto ::: to fuzz a method automatically (this will invoke the method using the number of payloads specified)

==== Current limitations ====
* when one of the create parameters value is null, the method is not invoked (since it was throwing a lot of errors). This is a legacy from the first version of this fuzzer (before cdb automation) so it should be possible to remove this now
* Need to add support for call stack information (and sequence of methods invoked) since sometimes the exception is not thrown by the method we fuzzed (and we need those details to replicate the state of that issue)
* the fact that we don't fuzz the same method twice creates some blind spots (since some errors occur by state changes in previous methods)
* the payloads are still quite basic, in a future version the fuzzing of live objects (i.e. variation of it) will be implemented
* the creation of live instances is still not very cleaver and has problem with more complex types (like the ones that require a file to be loaded before some of its methods make sense). The plan is to implement a new fuzzing mode where we are able to use real objects created during an execution of an real application (for example an win32 gui app or an ASP.NET website) and fuzz them.

====Bugs and to-do-list====

* we should delete the 'ExcludeList'and 'ExceptionData' when nothing is found
* list the methods/classes that we couldn't fuzz
* Add a Gui
* Add code coverage
* export results in XML format
* add directory recursive capabilities to the 'Dir' fuzzing mode

== HOW-TO use instructions ==

''''Fuzzing MsCorLib''''

> binary\DN_BOFinder.exe file mscorlib.dll

by default if no path is included, DN_BOFinder will try to find the file in the current directory or in the main .Net 2.0 directory

If all goes well you will see a large number of entries that look like these:

[INFO]: Fuzzing mscorlib.dll (18372 methods, 1264 types): 0 type processed
...
>>> Fuzzing System.Object [0]<<<:
...
***************************************************
*********
********* System.Object[] - FuzzIndex: 0
*********
***************************************************
...
[6:03 AM] > Executing System.Int32.System.IConvertible.ToBoolean(System.IFormatProvider) [0]:
[6:03 AM] > Executing System.Int32.System.IConvertible.ToChar(System.IFormatProvider) [0]:
[6:03 AM] > Executing System.Int32.System.IConvertible.ToSByte(System.IFormatProvider) [0]:

while this is running, open the \DN_BOFinder_V0.2\binary\_fuzz_results folder and you will see three files in there:

* mscorlib.dll_ExceptionData.txt - Will contain details about exeptions discovered (only in auto or dir modes)
* mscorlib.dll_ExcludeList.txt - Will contain a list of methods to exclude (only in auto or dir modes)
* mscorlib.dll_FuzzedMethods.txt - will contain a list of methods and classes that have been fuzzed

now try

> DN_BOFinder file system.dll

and you should get a crash (of the CLR) in the method:

>>> Fuzzing System.Text.RegularExpressions.MatchEvaluator [0]<<<:

run it under a debugger:

> cdb DN_BOFinder file system.dll
(press g)

and you should get this exception data:

(d64.bb0): CLR exception - code e0434f4d (first chance)
(d64.bb0): CLR exception - code e0434f4d (first chance)
(d64.bb0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000000 edx=00000001 esi=0014d3d0 edi=00000000
eip=79eea7c3 esp=0012e944 ebp=0012e9b4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll -
mscorwks!IEE+0x13277:
79eea7c3 0fb708 movzx ecx,word ptr [eax] ds:0023:00000000=????
0:000>

Which is an error that occurred inside the mscorwks.dll and was the reason the .NET assembly crashed.
The exeption mscorwks!IEE+0x13277 is actually quite common, and I think it is a false positive since it looks like part of a method that checks for bad points (which is weird method to check it, but it seems to be quite common on the CLR). I need to load the symbols in my dev laptop (which is always offline btw :) ) to see where mscorwks!IEE+0x13277 resolves to.

Now that we have an issue you have two choices:

1) add manually the signature of the offending class System.Text.RegularExpressions.MatchEvaluator to the _fuzz_results\system.dll_ExcludeList.txt file or

2) run

> DN_BOFinder file auto system.dll

which will do that for you :)

the output of "DN_BOFinder file auto system.dll" should be something like:

*********************************************
*******
******* DotNet BOFinder v0.2 (12 Mar 2007)
*******
*********************************************
....
Populating ByPassList
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 3 type processed
Normal CLR Exception in System.Text.RegularExpressions.MatchEvaluator [0]
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 4 type processed
System.Collections.CollectionBase.set_Capacity(Int32) Forced Exception - iPageMemorySize64 Grew by 1048MB
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 23 type processed
Normal CLR Exception in System.CodeDom.CodeMemberMethod.add_PopulateParameters(System.EventHandler) [0]
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 41 type processed
Normal CLR Exception in System.CodeDom.CodeMemberMethod.remove_PopulateParameters(System.EventHandler) [0]
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 42 type processed
Normal CLR Exception in System.CodeDom.CodeMemberMethod.add_PopulateStatements(System.EventHandler) [0]
[INFO]: Fuzzing system.dll (12676 methods, 889 types): 43 type processed
Normal CLR Exception in System.CodeDom.CodeMemberMethod.remove_PopulateStatements(System.EventHandler) [0]

so what is happening here is, you get an [INFO] every time a fuzzing session starts (i.e. new process) and we have a bunch of 'Normal CLR Exception' entries (which crash the CLR but I think are false positives (I would actually put money that some of these might be exploitable (most are null pointers)). Note for example that the case I shown above (System.Text.RegularExpressions.MatchEvaluator) is here shown as a 'Normal CLR Exception'

Every time a 'CLR Exception' occurs, its signature is added to the MethodsFuzzed list and the process restarts (only in the cases where the error doesn't match one of my hard-coded signatures the methods are added to the ExcludeList and its data added to the ExceptionData.

...

Eventually you start to get some more interesting issues like for example:

[INFO]: Fuzzing system.dll (12676 methods, 889 types): 167 type processed
System.Resources.ResourceManager.GetStream(System.String) [0] - via CDB
eax=00000000 ebx=0126853c ecx=00000000 edx=0126853c esi=0127ef20 edi=00000000
eip=039827df esp=0012ec74 ebp=0012ecc0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
039827df 8b01 mov eax,dword ptr [ecx] ds:0023:00000000=????????
0:000

which you can go to reflector and see its code:

class: System.Resources.ResourceManager
method: public UnmanagedMemoryStream GetStream(string name)

At this stage (after a bit of fuzzing) the system.dll_ExcludeList.txt should look like this:

System.Collections.CollectionBase.set_Capacity(Int32) Forced Exception - iPageMemorySize64 Grew by 1048MB
System.ComponentModel.ComponentResourceManager.ApplyResources(System.Object, System.String) [0] - via CDB
System.Resources.ResourceManager.ReleaseAllResources() [0] - via CDB
System.Resources.ResourceManager.GetString(System.String) [0] - via CDB
System.Resources.ResourceManager.GetObject(System.String) [0] - via CDB
System.Resources.ResourceManager.GetStream(System.String) [0] - via CDB
System.ComponentModel.TypeConverter.ConvertFromInvariantString(System.String) [0] - via CDB

Note: For non .NET Framework Assemblies (that are not placed on the v2 folder), you will need to pass the full path to the dll to fuzz.

Here for example is fuzzing a dll that is part of the .NET 2.0 SDK

> dn_boFinder file "c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\RequiredPermissions.dll"

This actually an interresting case since if you run it normally, you will not see a lot of exceptions, but if you run it under the cdb

> cdb dn_boFinder file "c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\RequiredPermissions.dll"

you will see a lot exceptions that look like these

[8:11 PM] > Executing ManagedMD.Utils.SafePointer.op_Implicit(ManagedMD.Utils.SafePointer) [0]: (1ac.634): Access violation
- code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=0012ed2c ecx=0012ed00 edx=00000000 esi=00181028 edi=00000000
eip=03684f95 esp=0012ecf4 ebp=0012ed10 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010216
03684f95 3b4204 cmp eax,dword ptr [edx+4] ds:0023:00000004=????????

so run it in auto mode to document them

> dn_boFinder file auto "c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\RequiredPermissions.dll"

(these type of cmp are another type of exceptions that I think are false positives)

== fuzzing methods ==

lets go back to the system.dll System.ComponentModel.ComponentResourceManager.ApplyResources(System.Object,System.String) discovered before

the final piece of the puzzle is to see if this method is exploitable (i.e. can we contol the CPU Registers from a variable that we control). So to do that, the easier way is to run just that method with all fuzzed combinations.

And that is what we can do with the method option. (you can also write a simple c# code to do that)

the format is

DN_BOFinder {full Path to Dll}!{full method signature (with no spaces)}!0 {number of fuzzed items to try (optional)}

so execute:

> DN_BOFinder.exe method auto c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\system.dll!System.ComponentModel.ComponentResourceManager.ApplyResources(System.Object,System.String)!0

which should give you something like:

*********************************************
*******
******* DotNet BOFinder v0.2 (12 Mar 2007)
*******
*********************************************
...
strDllToLoad: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\system.dll
strTypeToCreate: System.ComponentModel.ComponentResourceManager
strMethodToFuzz_FullName: System.ComponentModel.ComponentResourceManager.ApplyResources
strMethodToFuzz_Name: ApplyResources
strMethodToFuzz_Params: (System.Object,System.String)
Populating ByPassList
System.ComponentModel.ComponentResourceManager.ApplyResources [0] - via CDB
eax=00000000 ebx=012696b8 ecx=00000000 edx=012696b8 esi=01275460 edi=012696b8
eip=032d009f esp=0012eb74 ebp=0012ebc0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
032d009f 8b01 mov eax,dword ptr [ecx] ds:0023:00000000=????????
0:000
...
System.ComponentModel.ComponentResourceManager.ApplyResources [1] - via CDB
eax=00000000 ebx=012696b8 ecx=00000000 edx=012696b8 esi=01275460 edi=012696b8
eip=032d009f esp=0012eb74 ebp=0012ebc0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
032d009f 8b01 mov eax,dword ptr [ecx] ds:0023:00000000=????????
0:000
...
(other results omited)

so here one can see that the value of the CPU registers don't really change, which might mean that this is a false positive

==== interop.MediaPlayer ====

To see a better example of this, create a wrapper for the MediaPlayer control in a default xp sp2 installation in Visual Studio (i.e. the file Interop.MediaPlayer.dll) and fuzz it.

After a while you will get these two exceptions:

MediaPlayer.RadioPlayerClass.BindRadioMemory() [0] - via CDB
eax=7ffdf000 ebx=1d3063a8 ecx=1d363167 edx=00000000 esi=0039b6e4 edi=00000000
eip=1d363175 esp=0012ed4c ebp=0012ed74 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2f6e5:
1d363175 66c7076c00 mov word ptr [edi],6Ch ds:0023:00000000=????
0:000
...
MediaPlayer.RadioServerClass.Unregister(Int32) [0] - via CDB
eax=00000000 ebx=1d308fc0 ecx=03a40004 edx=001eeaca esi=003978f0 edi=f0000001
eip=1d3639f6 esp=0012ece0 ebp=0012ed04 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff66:
1d3639f6 8b07 mov eax,dword ptr [edi] ds:0023:f0000001=????????
0:000

the first one, MediaPlayer.RadioPlayerClass.BindRadioMemory(), seems to be one that is caused by some change of state on a previous fuzzed method, but the 2nd one looks much more interresting: MediaPlayer.RadioServerClass.Unregister(Int32)

Let's fuzz it using the auto method system:

DN_BOFinder.exe method auto d:\...\...\...\...\Interop.MediaPlayer.dll!MediaPlayer.RadioServerClass.Unregister(Int32)!0 15

*********************************************
*******
******* DotNet BOFinder v0.2 (12 Mar 2007)
*******
*********************************************
...
strDllToLoad: d:\...\...\...\...\Interop.MediaPlayer.dll
strTypeToCreate: MediaPlayer.RadioServerClass
strMethodToFuzz_FullName: MediaPlayer.RadioServerClass.Unregister
strMethodToFuzz_Name: Unregister
strMethodToFuzz_Params: (Int32)
Populating ByPassList
Fuzzing 15 objects
MediaPlayer.RadioServerClass.Unregister [0] - via CDB
eax=00000000 ebx=1d308fc0 ecx=034a0004 edx=001c7d3a esi=00397030 edi=f0000001
eip=1d3639f6 esp=0012ed40 ebp=0012ed64 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff66:
1d3639f6 8b07 mov eax,dword ptr [edi] ds:0023:f0000001=????????
0:000
....
MediaPlayer.RadioServerClass.Unregister [1] - via CDB
eax=00000000 ebx=1d308fc0 ecx=034a0004 edx=001a4c32 esi=00397030 edi=fff00001
eip=1d3639f6 esp=0012ed40 ebp=0012ed64 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff66:
1d3639f6 8b07 mov eax,dword ptr [edi] ds:0023:fff00001=????????
0:000
....
MediaPlayer.RadioServerClass.Unregister [6] - via CDB
eax=00000000 ebx=1d308fc0 ecx=034a0004 edx=001a4bca esi=00397030 edi=0fffffff
eip=1d3639f6 esp=0012ed40 ebp=0012ed64 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff66:
1d3639f6 8b07 mov eax,dword ptr [edi] ds:0023:0fffffff=????????
0:000
...
MediaPlayer.RadioServerClass.Unregister [7] - via CDB
eax=72006300 ebx=1d308fc0 ecx=034a0004 edx=001c7d3a esi=00397030 edi=00ffffff
eip=1d3639f8 esp=0012ed40 ebp=0012ed64 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff68:
1d3639f8 8b5808 mov ebx,dword ptr [eax+8] ds:0023:72006308=????????
0:000
...
MediaPlayer.RadioServerClass.Unregister [9] - via CDB
eax=00000000 ebx=1d308fc0 ecx=034a0004 edx=001c2392 esi=00397030 edi=0000ffff
eip=1d3639f6 esp=0012ed40 ebp=0012ed64 iopl=0 nv up ei pl zr ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010256
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\System32\msdxm.ocx -
msdxm!RunDll+0x2ff66:
1d3639f6 8b07 mov eax,dword ptr [edi] ds:0023:0000ffff=????????
0:000

and notice that we have direct control of EAX.

Now since you can only invoke this Interop.MediaPlayer.dll from Full Trust, this is not technically a vulnerability :)

== Development notes ==

1) to create and invoke private methods change in the utils/reflection.cs file

public static BindingFlags bfPublicNonPublicFlag = BindingFlags.Public;

with

public static BindingFlags bfBindingFlags_InsSta = bfPublicNonPublicFlag | BindingFlags.Instance | BindingFlags.Static;

{add more}

User:Ari Elias-Bachrach

2013-03-11T19:00:44Z

Ari Elias-Bachrach: redo user page

'''These days I spend most of my time:'''
* Delivering secure code training for Java developers
* Delivering secure coding training for .net developers
* Application assessments
* Explaining issues to developers and locating actionable solutions

'''And a smaller amount of time:'''
* Evaluating and deploying WAFs
* Independent research (current project: password policies)

If you want my resume, check my [http://www.linkedin.com/in/bachrach linkedin profile]

Codereview-Error-Handling

2011-06-22T20:23:32Z

Ari Elias-Bachrach: minor cleanup, a LOT more is needed.

{{LinkBar
| useprev=PrevLink | prev=Codereview-Input Validation | lblprev=Input Validation
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Codereview-Deployment | lblnext=Secure Deployment
}}
__TOC__

==Error Handling==
Error Handling is important in a number of ways. It may affect the state of the application, or leak system information to a user. The initial failure to prevent the error may cause the application to traverse into an insecure state. Weak error handling also aids the attacker, as the errors returned may assist them in constructing correct attack vectors. A generic error page for most errors is recommended. This approach makes it more difficult for attackers to identify signatures of potentially successful attacks. There are methods which can circumvent systems with leading error handling practices which should be kept in mind; Attacks such as blind SQL injection using booleanization or response time characteristics can be used to address such generic responses.

The other key area relating to error handling is the premise of "fail securely". Errors induced should not leave the application in an insecure state. Resources should be locked down and released, sessions terminated (if required), and calculations or business logic should be halted (depending on the type of error, of course).

An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application.

''The purpose of reviewing the Error Handling code is to assure that the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs. ''

For example, SQL injection is much tougher to successfully execute without some healthy error messages. It lessens the attack footprint, and an attacker would have to resort to using “blind SQL injection” which is more difficult and time consuming.

A well-planned error/exception handling strategy is important for three reasons:

# Good error handling does not give an attacker any information which is a means to an end, attacking the application
# A proper centralised error strategy is easier to maintain and reduces the chance of any uncaught errors “Bubbling up” to the front end of an application.
# Information leakage can lead to social engineering exploits.

Some development languages provide checked exceptions, which means that the compiler shall complain if an exception for a particular API call is not caught. Java and C# are good examples of this. Languages like C++ and C do not provide this safety net. Languages with checked exception handling still are prone to information leakage, as not all types of errors are checked for.

When an exception or error is thrown, we also need to log this occurrence. Sometimes this is due to bad development, but it can be the result of an attack or some other service your application relies on failing.

All code paths that can cause an exception to be thrown should check for success in order for the exception not to be thrown.

• To avoid a NullPointerException we should check if the object being accessed is not null.

===Error Handling Should Be Centralized if Possible===

When reviewing code it is recommended that you assess the commonality within the application from a error/exception handling perspective. Frameworks have error handling resources which can be exploited to assist in secure programming, and such resources within the framework should be reviewed to assess if the error handling is "wired-up" correctly.

* A generic error page should be used for all exceptions if possible.

This prevents the attacker from identifying internal responses to error states. This also makes it more difficult for automated tools to identify successful attacks.

'''Declarative Exception Handling'''

<exception key=”bank.error.nowonga”
path=”/NoWonga.jsp”
type=”mybank.account.NoCashException”/>

This could be found in the struts-config.xml file, a key file when reviewing the wired-up struts environment

===Java Servlets and JSP===

Specification can be done in web.xml in order to handle unhandled exceptions. When Unhandled exceptions occur, but are not caught in code, the user is forwarded to a generic error page:

<error-page>
<exception-type>UnhandledException</exception-type>
<location>GenericError.jsp</location>
</error-page>

Also in the case of HTTP 404 or HTTP 500 errors during the review you may find:

<error-page>
<error-code>500</error-code>
<location>GenericError.jsp</location>
</error-page>

===Failing Securely===
Types of errors:
*The result of business logic conditions not being met.
*The result of the environment wherein the business logic resides fails.
*The result of upstream or downstream systems upon which the application depends fail.
*Technical hardware / physical failure.

Failures are never expected, but they do occur. In the event of a failure, it is important not to leave the "doors" of the application open and the keys to other "rooms" within the application sitting on the table. In the course of a logical workflow, which is designed based upon requirements, errors may occur which can be programmatically handled, such as a connection pool not being available, or a downstream server not being contactable.

Such areas of failure should be examined during the course of the code review. It should be examined if all resources should be released in the case of a failure and during the thread of execution if there is any potential for resource leakage, resources being memory, connection pools, file handles etc.

The review of code should also include pinpointing areas where the user session should be terminated or invalidated. Sometimes errors may occur which do not make any logical sense from a business logic perspective or a technical standpoint;

e.g: "A logged in user looking to access an account which is not registered to that user and such data could not be inputted in the normal fashion."

Such conditions reflect possible malicious activity. Here we should review if the code is in any way defensive and kills the user’s session object and forwards the user to the login page. (Keep in mind that the session object should be examined upon every HTTP request).

===Information Burial===
Swallowing exceptions into an empty catch() block is not advised as an audit trail of the cause of the exception would be incomplete.

==Generic Error Messages==
We should use a localized description string in every exception, a friendly error reason such as “System Error – Please try again later”. When the user sees an error message, it will be derived from this description string of the exception that was thrown, and never from the exception class which may contain a stack trace, line number where the error occurred, class name, or method name.

Do not expose sensitive information in exception messages. Information such as paths on the local file system is considered privileged information; any internal system information should be hidden from the user. As mentioned before, an attacker could use this information to gather private user information from the application or components that make up the app.

Don’t put people’s names or any internal contact information in error messages. Don’t put any “human” information, which would lead to a level of familiarity and a social engineering exploit.

==How to Locate the Potentially Vulnerable Code==

===JAVA===
IIn Java we have the concept of an error object; the Exception object. This lives in the Java package java.lang and is derived from the Throwable object. Exceptions are thrown when an abnormal occurrence has occurred. Another object derived from Throwable is the Error object, which is thrown when something more serious occurs.

Information leakage can occur when developers use some exception methods, which ‘bubble’ to the user UI due to a poor error handling strategy. The methods are as follows:

printStackTrace()<br>
getStackTrace()

Also important to know is that the output of these methods is printed in System console, the same as System.out.println(e) where there is an Exception. Be sure to not redirect the outputStream to PrintWriter object of JSP, by convention called "out". Ex. printStackTrace(out);

Also another object to look at is the java.lang.system package:

setErr() and the System.err field.

===.NET===
In .NET a System.Exception object exists. Commonly used child objects such as ApplicationException and SystemException are used. It is not recommended that you throw or catch a SystemException this is thrown by runtime.

When an error occurs, either the system or the currently executing application reports it by throwing an exception containing information about the error, similar to Java. Once thrown, an exception is handled by the application or by the default exception handler. This Exception object contains similar methods to the Java implementation such as:

StackTrace <br>
Source <br>
Message <br>
HelpLink <br>

In .NET we need to look at the error handling strategy from the point of view of global error handling and the handling of unexpected errors. This can be done in many ways and this article is not an exhaustive list. Firstly, an Error Event is thrown when an unhandled exception is thrown.

This is part of the TemplateControl class.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebUITemplateControlClassErrorTopic.asp

Error handling can be done in three ways in .NET

*In the web.config file's customErrors section.
*In the global.asax file's Application_Error sub.
*On the aspx or associated codebehind page in the Page_Error sub

The order of error handling events in .NET is as follows:
# On the Page in the Page_Error sub.
# The global.asax Application_Error sub
# The web.config file

It is recommended to look in these areas to understand the error strategy of the application.

===Classic ASP===
Unlike Java and .NET, classic ASP pages do not have structured error handling in try-catch blocks. Instead they have a specific object called "err". This make error handling in a classic ASP pages hard to do and prone to design errors on error handlers, causing race conditions and information leakage. Also, as ASP uses VBScript (a subtract of Visual Basic), sentences like "On Error GoTo label" are not available.

==Vulnerable Patterns for Error Handling==

===Page_Error===

Page_Error is page level handling which is run on the server side.
Below is an example but the error information is a little too informative and hence bad practice.

<script language="C#" runat="server">
Sub Page_Error(Source As Object, E As EventArgs)
Dim message As String = <Font Color="red">Request.Url.ToString()& Server.GetLastError().ToString()</font>
Response.Write(message) // display message
End Sub
</script>

The text in the example above has a number of issues: Firstly, it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point, we are vulnerable to cross site scripting attacks!! Secondly, the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.

After the Page_Error is called, the Application_Error sub is called.

===Global.asax===

When an error occurs, the Application_Error sub is called. In this method we can log the error and redirect to another page.

<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(Object sender, EventArgs e) {
String Message = "\n\nURL: http://localhost/" + Request.Path
+ "\n\nMESSAGE:\n " + Server.GetLastError().Message
+ "\n\nSTACK TRACE:\n" + Server.GetLastError().StackTrace;
// Insert into Event Log
EventLog Log = new EventLog();
Log.Source = LogName;
Log.WriteEntry(Message, EventLogEntryType.Error);
Server.Redirect(Error.htm) // this shall also clear the error
}
</script>

Above is an example of code in Global.asax and the Application_Error method. The error is logged and then the user is redirected. Unvalidated parameters are being logged here in the form of Request.Path. Care must be taken not to log or redisplay unvalidated input from any external source.

===Web.config===
Web.config has custom error tags which can be used to handle errors. This is called last and if Page_error or Application_error is called and has functionality, that functionality shall be executed first. As long as the previous two handling mechanisms do not redirect or clear (Response.Redirect or a Server.ClearError), this will be called and you shall be forwarded to the page defined in web.config.

<customErrors defaultRedirect="error.html" mode="On|Off|RemoteOnly">
<error statusCode="statuscode" redirect="url"/>
</customErrors>

The “On" directive means that custom errors are enabled. If no defaultRedirect is specified, users see a generic error. The "Off" directive means that custom errors are disabled. This allows the displaying of detailed errors. "RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.

<customErrors mode="On" defaultRedirect="error.html">
<error statusCode="500" redirect="err500.aspx"/>
<error statusCode="404" redirect="notHere.aspx"/>
<error statusCode="403" redirect="notAuthz.aspx"/>
</customErrors>

== Leading Practice for Error Handling ==

===Try & Catch (Java/ .NET)===
Code that might throw exceptions should be in a try block and code that handles exceptions in a catch block. The catch block is a series of statements beginning with the keyword catch, followed by an exception type and an action to be taken. These are very similar in Java and .NET

'''Example:'''

'''Java Try-Catch:'''

public class DoStuff {
public static void Main() {
try {
StreamReader sr = File.OpenText("stuff.txt");
Console.WriteLine("Reading line {0}", sr.ReadLine());
}
catch(Exception e) {
Console.WriteLine("An error occurred. Please leave to room”);
logerror(“Error: “, e);
}
}
}

'''.NET Try–Catch'''

public void run() {
while (!stop) {
try {

// Perform work here

} catch (Throwable t) {
// Log the exception and continue
WriteToUser(“An Error has occurred, put the kettle on”);
logger.log(Level.SEVERE, "Unexception exception", t);
}
}
}

In general, it is best practice to catch a specific type of exception rather than use the basic catch(Exception) or catch(Throwable) statement in the case of Java.

In classic ASP there are two ways to do error handling, the first is using the err object with an On Error Resume Next.

Public Function IsInteger (ByVal Number)
Dim Res, tNumber
Number = Trim(Number)
tNumber=Number
On Error Resume Next 'If an error occurs continue execution
Number = CInt(Number) 'if Number is a alphanumeric string a Type Mismatch error will occur
Res = (err.number = 0) 'If there are no errors then return true
On Error GoTo 0 'If an error occurs stop execution and display error
re.Pattern = "^[\+\-]? *\d+$" 'only one +/- and digits are allowed
IsInteger = re.Test(tNumber) And Res
End Function

The second is using an error handler on an error page (http://support.microsoft.com/kb/299981).

Dim ErrObj
set ErrObj = Server.GetLastError()
'Now use ErrObj as the regular err object

===Releasing resources and good housekeeping===
If the language in question has a finally method, use it. The finally method is guaranteed to always be called. The finally method can be used to release resources referenced by the method that threw the exception. This is very important. An example would be if a method gained a database connection from a pool of connections, and an exception occurred without finally, the connection object shall not be returned to the pool for some time (until the timeout). This can lead to pool exhaustion. finally() is called even if no exception is thrown.

try {
System.out.println("Entering try statement");
out = new PrintWriter(new FileWriter("OutFile.txt"));
//Do Stuff….

} catch (Exception e) {
System.err.println("Error occurred!”);

} catch (IOException e) {
System.err.println("Input exception ");

} finally {

if (out != null) {
out.close(); // RELEASE RESOURCES
}
}

A Java example showing finally() being used to release system resources.

===Classic ASP===
For Classic ASP pages it is recommended to enclose all cleaning in a function and call it into an error handling statement after an "On Error Resume Next".

===Centralised exception handling (Struts Example)===
Building an infrastructure for consistent error reporting proves more difficult than error handling. Struts provides the ActionMessages and ActionErrors classes for maintaining a stack of error messages to be reported, which can be used with JSP tags like <html: error> to display these error messages to the user.

To report a different severity of a message in a different manner (like error, warning, or information) the following tasks are required:

# Register, instantiate the errors under the appropriate severity
# Identify these messages and show them in a consistent manner.

Struts ActionErrors class makes error handling quite easy:

ActionErrors errors = new ActionErrors()
errors.add("fatal", new ActionError("...."));
errors.add("error", new ActionError("...."));
errors.add("warning", new ActionError("...."));
errors.add("information", new ActionError("...."));
saveErrors(request,errors); // Important to do this

Now that we have added the errors, we display them by using tags in the HTML page.

<logic:messagePresent property="error">
<html:messages property="error" id="errMsg" >
<bean:write name="errMsg"/>
</html:messages>
</logic:messagePresent >

===Classic ASP===
For classic ASP pages you need to do some IIS configuration, follow the same link for more information http://support.microsoft.com/kb/299981

{{LinkBar
| useprev=PrevLink | prev=Codereview-Input Validation | lblprev=Input Validation
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Codereview-Deployment | lblnext=Secure Deployment
}}

[[Category:OWASP Code Review Project]]

Reviewing Code for Cross-site scripting

2011-06-22T20:03:02Z

Ari Elias-Bachrach: readability improvements

{{LinkBar
| useprev=PrevLink | prev=Reviewing Code for Data Validation | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Reviewing Code for Cross-Site Request Forgery | lblnext=
}}

==Overview==
Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application reflects user input without validation or encoding.

==Related Security Activities==

===Description of Cross-site Scripting Vulnerabilities===

See the OWASP article on [[Cross-site Scripting (XSS)]] Vulnerabilities.

===How to Avoid Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Phishing]].

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on [[Data Validation]].

===How to Test for Cross-site scripting Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for Cross site scripting|Test for Cross site scripting]] Vulnerabilities.

==Vulnerable Code example==
If the text inputted by the user is reflected back without proper encoding, the browser will interpret the inputted script as part of the mark up, and execute the code accordingly.

To mitigate this type of vulnerability we need to perform a number of security tasks in our code:

# Validate data
# Encode unsafe output

import org.apache.struts.action.*;
import org.apache.commons.beanutils.BeanUtils;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public final class InsertEmployeeAction extends Action {

public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception{

// Setting up objects and vairables.

Obj1 service = new Obj1();
ObjForm objForm = (ObjForm) form;
InfoADT adt = new InfoADT ();
BeanUtils.copyProperties(adt, objForm);

String searchQuery = objForm.getqueryString();
String payload = objForm.getPayLoad();
try {
service.doWork(adt); / /do something with the data
ActionMessages messages = new ActionMessages();
ActionMessage message = new ActionMessage("success", adt.getName() );
messages.add( ActionMessages.GLOBAL_MESSAGE, message );
saveMessages( request, messages );
request.setAttribute("Record", adt);
return (mapping.findForward("success"));
}
catch( DatabaseException de )
{
ActionErrors errors = new ActionErrors();
ActionError error = new ActionError("error.employee.databaseException" + “Payload: “+payload);
errors.add( ActionErrors.GLOBAL_ERROR, error );
saveErrors( request, errors );
return (mapping.findForward("error: "+ searchQuery));
}
}
}

The text above shows some common mistakes in the development of this struts action class. First, the data passed in the HttpServletRequest is placed into a parameter without being validated.

Focusing on XSS we can see that this action class returns a message, ActionMessage, if the function is successful. If an error the code in the Try/Catch block is executed, the data contained in the HttpServletRequest is returned to the user, unvalidated and exactly in the format in which the user inputted it.

import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;

public class HelloServlet extends HttpServlet
{
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException
{

String input = req.getHeader(“USERINPUT”);

PrintWriter out = res.getWriter();
out.println(input); // echo User input.
out.close();
}
}

Following is a second example of an XSS vulnerable function. Echoing un-validated user input back to the browser provides a large vulnerability footprint.

===.NET Example (ASP.NET version 1.1 ASP.NET version 2.0)===

The server side code for a VB.NET application may have similar functionality.

' SearchResult.aspx.vb
Imports System
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox
Protected cmdSearch As Button
Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..
// …………

lblResult.Text="You Searched for: " & txtInput.Text

// Display Search Results…..
// …………

End Sub
End Class

This is a VB.NET example of a vulnerable piece of search functionality which echoes back the data inputted by the user. To mitigate against this, we need proper data validation and in the case of stored XSS attacks, we need to encode known bad input (as mentioned before). Note that this code might not be vulnerable if the developers use a proper declarative validation (ASPX regexp validator or routine, and validateRequest not set to False).

===Classic ASP Example===
Classic ASP is also XSS prone, just like most Web technologies.
<pre>
<%
...
Response.Write "<div class='label'>Please confirm your data</div><br />"
Response.Write "Name: " & Request.Form("UserFullName")
...
%>
</pre>

==Protecting against XSS==
In the .NET framework there are some in-built security functions which can assist in data validation and HTML encoding, namely, ASP.NET 1.1 '''request validation '''feature and '''HttpUtility.HtmlEncode'''.

Microsoft in their wisdom state that you should not rely solely on ASP.NET request validation and that it should be used in conjunction with your own data validation, such as regular expressions (mentioned below).

The request validation feature is disabled on an individual page by specifying in the page directive.

'''<%@ Page validateRequest="false" %>'''

or by setting '''ValidateRequest="false"''' on the '''@ Pages''' element.

or in the '''web.config''' file:

You can disable request validation by adding a

<'''pages'''> element with '''validateRequest="false"'''

So when reviewing code, make sure the validateRequest directive is enabled and if not, investigate what method of data validation is being used, if any. Check that ASP.NET Request validation is enabled in '''Machine.config'''.
Request validation is enabled by ASP.NET by default. You can see the following default setting in the '''Machine.config''' file.

'''<pages validateRequest="true" ... /> '''

'''HTML Encoding:'''

Content to be displayed can easily be encoded using the HtmlEncode function. This is done by calling:

'''Server.HtmlEncode(string)'''

Using the HTML encoder example for a form:

Text Box: <%@ Page Language="C#" ValidateRequest="false" %>

<script runat="server">
void searchBtn _Click(object sender, EventArgs e) {
Response.Write(HttpUtility.HtmlEncode(inputTxt.Text)); }
</script>
<html>
<body>
<form id="form1" runat="server">
<asp:TextBox ID="inputTxt" Runat="server" TextMode="MultiLine" Width="382px" Height="152px">
</asp:TextBox>
<asp:Button ID="searchBtn" Runat="server" Text="Submit" OnClick=" searchBtn _Click" />
</form>
</body>
</html>

For Classic ASP pages the encoding function is used pretty much the same as in ASP.NET

Response.Write Server.HtmlEncode(inputTxt.Text)

===Stored Cross Site Script===
'''Using HTML encoding to encode potentially unsafe output.'''

Malicious scripts can be stored/persisted in a database and will not execute until retrieved by a user. This has been seen in bulletin boards and some early webmail applications. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script executes on the user’s browser.

The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.

In this case we cannot be 100% sure the data to be displayed to the user is safe (as it could have found its way in via another path in the enterprise). The approach to mitigate against this is to ensure that data sent to the browser with the purpose of being displayed literally is not going to be interpreted by the browser as mark-up.

We encode known bad to mitigate against this “enemy within”. This, in effect, assures that the browser interprets any special characters as data and markup.
How is this done?
HTML encoding usually means '''<''' becomes '''&lt;''', '''>''' becomes '''&gt;''', '''&''' becomes '''&amp;''', and '''"''' becomes '''&quot;'''.

{|
|-
! From !! To
|-
| < || &lt;
|-
| > || &gt;
|-
| ( || &#40;
|-
| ) || &#41;
|-
| # || &#35;
|-
| & || &amp;
|-
| "|| &quot;
|}

So, for example, if the application has a string "<script>" and it wants a browser to display it as "<script>", it can first HTML-encode it to the form "&lt;script&gt;" before including it in the web page that gets sent to the browser.

{{LinkBar
| useprev=PrevLink | prev=Reviewing Code for Data Validation | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Reviewing Code for Cross-Site Request Forgery | lblnext=
}}

[[Category:OWASP Code Review Project]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2011-01-12T20:54:00Z

Ari Elias-Bachrach: make link look nicer

= Introduction =

This article provides a simple positive model for preventing [[XSS]] using output escaping/encoding properly. While there are a huge number of XSS attack vectors, following a few simple rules can completely defend against this serious attack. This article does not explore the technical or business impact of XSS. Suffice it to say that it can lead to an attacker gaining the ability to do anything a victim can do through their browser.

These rules apply to all the different varieties of XSS. Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate escaping on the server-side. The use of an escaping/encoding library like the one in [[ESAPI]] is strongly recommended as there are many special cases. [[DOM Based XSS]] can be addressed by applying these rules on the client on untrusted data.

For a great cheatsheet on the attack vectors related to XSS, please refer to the excellent [http://ha.ckers.org/xss.html XSS Cheat Sheet] by RSnake. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

== Untrusted Data ==

Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, it might not have been perfectly validated. The [[Searching for Code in J2EE/Java|OWASP Code Review Guide]] has a decent list of methods that return untrusted data in various languages, but you should be careful about your own methods as well.

Untrusted data should always be treated as though it contains an attack. That means you should not send it '''anywhere''' without taking steps to make sure that any attacks are detected and neutralized. As applications get more and more interconnected, the likelihood of a buried attack being decoded or executed by a downstream interpreter increases rapidly.

Traditionally, [[Data Validation|input validation]] has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?

While input validation is important and should always be performed, it is not a complete solution for injection attacks. It's better to think of input validation as [[Defense in depth|defense in depth]] and use '''escaping''' as described below as the primary defense.

== Escaping (aka Output Encoding) ==

"[http://www.w3.org/TR/charmod/#sec-Escaping Escaping]" is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser. There are lots of different types of escaping, sometimes confusingly called output "encoding." Some of these techniques define a special "escape" character, and other techniques have a more sophisticated syntax that involves several characters.

Do not confuse output escaping with the notion of Unicode character [http://www.w3.org/TR/charmod/#sec-Digital encoding], which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does '''not''' defuse attacks. However, if there are misunderstandings about the intended charset between the server and browser, it may cause unintended characters to be communicated, possibly enabling XSS attacks. This is why it is still important to [http://www.w3.org/TR/charmod/#sec-Encodings specify] the Unicode character encoding (charset), such as UTF-8, for all communications.

Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is '''no harm''' in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

== Injection Theory ==

[[Injection Flaws|Injection]] is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used. A data context is like <div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this <div>data < script>alert("attack")</script> context</div>.

XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML document. HTML is easily the worst mashup of code and data of all time, as there are so many possible places to put code and so many different valid encodings. HTML is particularly difficult because it is not only hierarchical, but also contains many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).

To really understand what's going on with XSS, you have to consider injection into the hierarchical structure of the [http://www.w3schools.com/HTMLDOM/default.asp HTML DOM]. Given a place to insert data into an HTML document (that is, a place where a developer has allowed untrusted data to be included in the DOM), there are two ways to inject code:

;Injecting UP:The most common way is to close the current context and start a new code context. For example, this is what you do when you close an HTML attribute with a "> and start a new <script> tag. This attack closes the original context (going up in the hierarchy) and then starts a new tag that will allow script code to execute. Remember that you may be able to skip many layers up in the hierarchy when trying to break out of your current context. For example, a </script> tag may be able to terminate a script block even if it is injected inside a quoted string inside a method call inside the script. This happens because the HTML parser runs before the JavaScript parser.

;Injecting DOWN:The less common way to perform XSS injection is to introduce a code subcontext without closing the current context. For example, if the attacker is able to change <img src="...UNTRUSTED DATA HERE..." /> into < img src="javascript:alert(document.cookie)" /> they do not have to break out of the HTML attribute context. Instead, they introduce a subcontext that allows scripting within the src attribute (in this case a javascript url). Another example is the expression() functionality in CSS properties. Even though you may not be able to escape a quoted CSS property to inject up, you may be able to introduce something like xss:expression(document.write(document.cookie)) without ever leaving the current context.

There's also the possibility of injecting directly in the current context. For example, if you take untrusted input and put it directly into a JavaScript context. While insane, accepting code from an attacker is more common than you might think in modern applications. Generally it is impossible to secure untrusted code with escaping (or anything else). If you do this, your application is just a conduit for attacker code to get running in your users' browsers.

The rules in this document have been designed to prevent both UP and DOWN varieties of XSS injection. To prevent injecting up, you must escape the characters that would allow you to close the current context and start a new one. To prevent attacks that jump up several levels in the DOM hierarchy, you must also escape all the characters that are significant in all enclosing contexts. To prevent injecting down, you must escape any characters that can be used to introduce a new sub-context within the current context.

== A Positive XSS Prevention Model ==

This article treats an HTML page like a template, with slots where a developer is allowed to put untrusted data. These slots cover the vast majority of the common places where a developer might want to put untrusted data. Putting untrusted data in other places in the HTML is not allowed. This is a "whitelist" model, that denies everything that is not specifically allowed.

Given the way browsers parse HTML, each of the different types of slots has slightly different security rules. When you put untrusted data into these slots, you need to take certain steps to make sure that the data does not break out of that slot into a context that allows code execution. In a way, this approach treats an HTML document like a parameterized database query - the data is kept in specific places and is isolated from code contexts with escaping.

This document sets out the most common types of slots and the rules for putting untrusted data into them safely. Based on the various specifications, known XSS vectors, and a great deal of manual testing with all the popular browsers, we have determined that the rule proposed here are safe.

The slots are defined and a few examples of each are provided. Developers SHOULD NOT put data into any other slots without a very careful analysis to ensure that what they are doing is safe. Browser parsing is extremely tricky and many innocuous looking characters can be significant in the right context.

== Why Can't I Just HTML Entity Encode Untrusted Data? ==

HTML entity encoding is okay for untrusted data that you put in the body of the HTML document, such as inside a <div> tag. It even sort of works for untrusted data that goes into attributes, particularly if you're religious about using quotes around your attributes. But HTML entity encoding doesn't work if you're putting untrusted data inside a <script> tag anywhere, or an event handler attribute like onmouseover, or inside CSS, or in a URL. So even if you use an HTML entity encoding method everywhere, you are still most likely vulnerable to XSS. '''You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into.''' That's what the rules below are all about.

== You Need a Security Encoding Library ==

Writing these encoders is not tremendously difficult, but there are quite a few hidden pitfalls. For example, you might be tempted to use some of the escaping shortcuts like \" in JavaScript. However, these values are dangerous and may be misinterpreted by the nested parsers in the browser. You might also forget to escape the escape character, which attackers can use to neutralize your attempts to be safe. OWASP recommends using a security-focused encoding library to make sure these rules are properly implemented.

The OWASP [[ESAPI]] project has created an escaping library in a variety of languages including Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. The ESAPI library can be used for escaping as described here and also for decoding (aka canonicalization), which is critical for input validation. Microsoft provides an encoding library named [http://www.codeplex.com/AntiXSS AntiXSS].

= XSS Prevention Rules =

The following rules are intended to prevent all XSS in your application. While these rules do not allow absolute freedom in putting untrusted data into an HTML document, they should cover the vast majority of common use cases. You do not have to allow '''all''' the rules in your organization. Many organizations may find that '''allowing only Rule #1 and Rule #2 are sufficient for their needs'''. Please add a note to the discussion page if there is an additional context that is often required and can be secured with escaping.

Do NOT simply escape the list of example characters provided in the various rules. It is NOT sufficient to escape only that list. Blacklist approaches are quite fragile. The whitelist rules here have been carefully designed to provide protection even against future vulnerabilities introduced by browser changes.

== RULE #0 - Never Insert Untrusted Data Except in Allowed Locations ==

The first rule is to '''deny all''' - don't put untrusted data into your HTML document unless it is within one of the slots defined in Rule #1 through Rule #5. The reason for Rule #0 is that there are so many strange contexts within HTML that the list of escaping rules gets very complicated. We can't think of any good reason to put untrusted data in these contexts.

<script>'''...NEVER PUT UNTRUSTED DATA HERE...'''</script> directly in a script

 inside an HTML comment

<div '''...NEVER PUT UNTRUSTED DATA HERE...'''=test /> in an attribute name

<'''NEVER PUT UNTRUSTED DATA HERE...''' href="/test" /> in a tag name

Most importantly, never accept actual JavaScript code from an untrusted source and then run it. For example, a parameter named "callback" that contains a JavaScript code snippet. No amount of escaping can fix that.

== RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content ==

Rule #1 is for when you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc. Most web frameworks have a method for HTML escaping for the characters detailed below. However, this is '''absolutely not sufficient for other HTML contexts.''' You need to implement the other rules detailed here as well.

<body>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</body>

<div>'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''</div>

any other normal HTML elements

Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML entity.

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27; ' is not recommended
/ --> &#x2F; forward slash is included as it helps end an HTML entity

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/HTMLEntityCodec.java ESAPI reference implementation] of HTML entity escaping and unescaping.

String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

== RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes ==

Rule #2 is for putting untrusted data into typical attribute values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover. It is extremely important that event handler attributes should follow Rule #3 for HTML JavaScript Data Values.

<div attr='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''>content</div> inside UNquoted attribute

<div attr=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''>content</div> inside single quoted attribute

<div attr="'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''">content</div> inside double quoted attribute

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/HTMLEntityCodec.java ESAPI reference implementation] of HTML entity escaping and unescaping.

String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

== RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values ==

Rule #3 concerns the JavaScript event handlers that are specified on various HTML elements. The only safe place to put untrusted data into these event handlers as a quoted "data value." Including untrusted data inside any other code block is quite dangerous, as it is very easy to switch into an execution context, so use with caution.

<script>alert(''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''')</script> inside a quoted string

<script>x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''</script> one side of a quoted expression

<div onmouseover="x=''''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...''''"</div> inside quoted event handler

Please note there are some JavaScript functions that can never safely use untrusted data as input - <b>EVEN IF JAVASCRIPT ESCAPED</b>!

For example:
<script>
window.setInterval(''''...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...'''');
</script>

Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent switching out of the data value into the script context or into another attribute. Do not use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. If an event handler is quoted, breaking out requires the corresponding quote. The reason this rule is so broad is that developers frequently leave event handler attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, a </script> closing tag will close a script block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/JavaScriptCodec.java ESAPI reference implementation] of JavaScript escaping and unescaping.

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

== RULE #4 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values ==

Rule #4 is for when you want to put untrusted data into a stylesheet or a style tag. CSS is surprisingly powerful, and can be used for numerous attacks. Therefore, it's important that you only use untrusted data in a property '''value''' and not into other places in style data. You should stay away from putting untrusted data into complex properties like url, behavior, and custom (-moz-binding). You should also not put untrusted data into IE’s expression property value which allows JavaScript.

<style>selector { property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''; } </style> property value<br/>
<style>selector { property : "'''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''"; } </style> property value<br/>
<span style="property : '''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'''">text</style> property value

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format. Do not use any escaping shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs first. Prevent switching out of the property value and into another property or attribute. Also prevent switching into an expression or other property value that allows scripting. If attribute is quoted, breaking out requires the corresponding quote. All attributes should be quoted but your encoding should be strong enough to prevent XSS when untrusted data is placed in unquoted contexts. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, the </style> tag will close the style block even though it is inside a quoted string because the HTML parser runs before the JavaScript parser. Please note that we recommend aggressive CSS encoding to prevent XSS attacks for both quoted and unquoted attributes.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/CSSCodec.java ESAPI reference implementation] of CSS escaping and unescaping.

String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );

== RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values ==

Rule #5 is for when you want to put untrusted data into HTTP GET parameter value.

<a href="http://www.somesite.com?test='''...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."'''>link</a >

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH escaping format. Including untrusted data in data: URLs should not be allowed as there is no good way to disable attacks with escaping to prevent switching out of the URL. All attributes should be quoted. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Note that entity encoding is useless in this context.

See the [http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/codecs/PercentCodec.java ESAPI reference implementation] of URL escaping and unescaping.

String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) );

WARNING: Do not encode complete or relative URL's with URL encoding! If untrusted input is meant to be placed into href, src or other URL-based attributes, it should be validated to make sure it does not point to an unexpected protocol, especially Javascript links. URL's should then be encoded based on the context of display like any other piece of data. For example, user driven URL's in HREF links should be attribute encoded. For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL, "URL", 255, false);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

== RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way ==

import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function

== RULE #7 - Prevent DOM-based XSS ==

For details on what DOM-based XSS is, and defenses against this type of XSS flaw, please see the OWASP article on [[DOM_Based_XSS | DOM-based XSS]].

= Encoding Information =
[http://code.google.com/p/owasp-development-guide/wiki/WebAppSecDesignGuide_D6 OWASP Development Guide]

= Additional XSS Defense (HTTPOnly cookie flag)=

Preventing all XSS flaws in an application is hard, as you can see. To help mitigate the impact of an XSS flaw on your site, OWASP also recommends you set the HTTPOnly flag on your session cookie and any custom cookies you have that are not accessed by any Javascript you wrote. This cookie flag is typically on by default in .NET apps, but in other languages you have to set it manually.

For more details on the HTTPOnly cookie flag, including what it does, and how to use it, see the OWASP article on [[HTTPOnly]].

=Related Articles=

'''XSS Attack Cheat Sheet'''

The following article describes how to exploit different kinds of XSS Vulnerabilities that this article was created to help you avoid:

* RSnake: "XSS Cheat Sheet" - http://ha.ckers.org/xss.html

'''Description of XSS Vulnerabilities'''

* OWASP article on [[XSS]] Vulnerabilities

'''How to Review Code for Cross-site scripting Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on [[Reviewing Code for Cross-site scripting]] Vulnerabilities

'''How to Test for Cross-site scripting Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on [[Testing for Cross site scripting]] Vulnerabilities

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com

Jim Manico - jim[at]manico.net

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Testing for Stack Overflow

2010-10-21T19:01:53Z

Ari Elias-Bachrach: spelling only

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
This section discusses an overflow test that focuses on how to manipulate the program stack.

== Description of the Issue ==
[[Stack overflow|Stack overflows]] occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Development Guide 2.0 states that:

'' Almost every platform, with the following notable exceptions:''
*'' J2EE – as long as native methods or system calls are not invoked''
*'' .NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)''
*'' PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called ''
''can suffer from stack overflow issues. ''

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would be to attach a debugger to the target application or process, generate malformed input for the application, subject the application to malformed input, and inspect responses in a debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case, various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or Extended Instruction Pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user-supplied values and control program execution. A stack overflow can also allow overwriting of stack-based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occurred on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow if inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. If the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases, a function like memccpy() is usually employed which copies data into a destination buffer from source until a specified character is not encountered. Consider the function:

<pre>
void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer until a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits, like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers'''<br>
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools'''<br>
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/

[[Category:FIXME|link not working

* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

]]

Using the Java Secure Socket Extensions

2010-10-21T19:00:32Z

Ari Elias-Bachrach: spelling only

==Status==
Requires review

''The code included in this article has not been reviewed and should not be used without proper analysis. If you have reviewed the included code (or portions of it), please post your findings back to this page or to: stephen [at] corsaire.com.''

==Overview==

===What is SSL ?===
SSL - Secure Socket Layer is an Application layer cryptographic protocol developed by Netscape for securing communication over the Internet.
The security services provided by SSL are
# Confidentiality through Encryption of data using Symmetric Key Encryption Algorithms
# Non - Repudiation of Origin / Origin Integrity through Digital Signatures using Asymmetric key Encryption Algorithms or Public Key Cryptographic Algorithms
# Data Integrity through Hashing using Message Digest or Hashing Algorithms

===What is JSSE ?===
JSSE is the acronym of Jave Secure Socket Extensions. As the name implies it is a set of Java API's which provides SSL / TLS functionality.
JSSE follows a Provider Architecture wherein the functionality specified in the Service Provider Interface can be implemented by any Service Provider. JSSE comes bundled with a default service provider named SunJSSE. JSSE was an optional package on jdk ##x and ##x. Since jdk ##x, JSSE comes pre-configured with the standard jdk package

===The JSSE Implementation of SSL===
JSSE provides an implementation for creating SSLSocket (used by clients) and SSLServerSocket (used by server).
====Algorithm for creating SSL Client socket====
# Determine the SSL Server Name and port in which the SSL server is listening
# Register the JSSE provider
# Create an instance of SSLSocketFactory
# Create an instance of SSLSocket
# Create an OutputStream object to write to the SSL Server
# Create an InputStream object to receive messages back from the SSL Server

====Algorithm for creating SSL Server socket====
# Register the JSSE provider
# Set System property for keystore by specifying the keystore which contains the server certificate
# Set System property for the password of the keystore which contains the server certificate
# Create an instance of SSLServerSocketFactory
# Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
# Initialize an object of SSLSocket
# Create InputStream object to read data sent by clients
# Create an OutputStream object to write data back to clients.

===SSL Handshake Protocol===
The SSL handshake protocol happens between the client and the server and comprises of 4 rounds that enable peers to agree on keys, ciphers and MAC algorithms. The handshake is explained below with the parameters captured in the debug mode during the execution of SSLClient and SSLServer java files.

====Round 1 : Create the SSL connection between the Client and the Server====
<pre>
C -> S {ver || randomcookie1 || sessionid || Cipher Suites || Compression Methods }
*** ClientHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 250, 20, 142, 231, 143, 78, 72, 52, 254, 46, 199, 39, 146, 23, 238, 5, 108, 171, 75, 192, 78, 173, 26, 151, 89, 86, 58, 197 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
S -> C {ver || randomcookie2 || session_id || cipher || compression }
*** ServerHello, TLSv1
RandomCookie: GMT: 1165141617 bytes = { 33, 91, 78, 189, 156, 183, 142, 253, 119, 155, 22, 193, 46, 0, 50, 153, 168, 170, 19, 220, 68, 97, 98, 3, 36, 228, 103, 117 }
Session ID: {69, 115, 166, 113, 102, 3, 65, 68, 227, 239, 225, 34, 115, 49, 73, 69, 174, 111, 222, 219, 119, 162, 5, 11, 77, 149, 181, 24, 38, 98, 5, 204}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
</pre>

====Round 2 : Server authenticates itself====
<pre>
S -> C {server_cert}
***
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 01 45 73 A6 71 21 5B 4E BD 9C B7 ...F..Es.q![N...
0010: 8E FD 77 9B 16 C1 2E 00 32 99 A8 AA 13 DC 44 61 ..w.....#....Da
0020: 62 03 24 E4 67 75 20 45 73 A6 71 66 03 41 44 E3 b.$.gu Es.qf.AD.
0030: EF E1 22 73 31 49 45 AE 6F DE DB 77 A2 05 0B 4D .."s1IE.o..w...M
0040: 95 B5 18 26 62 05 CC 00 04 00 ...&b.....

S -> C {public key modulus || exponent || {hash (randomcookie1 || randomcookie2 || public key modulus || exponent )} signed by Server}
*** Certificate chain
chain [0] = [
[
Version: V1
Subject: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Signature Algorithm: MD5withRSA, OID = ######4

Key: Sun RSA public key, 1024 bits
modulus: 125799608853960565468693082080524019040787802862173204033354805928537584240351554241990082493719007271501637788649255493925650447292814949263542483518710211756489915623917992726468465059340034326131973495929283930754477403752766287367308326998219377123365800989254595407827915805528431637337980240073881550879
public exponent: 65537
Validity: [From: Sun Nov 26 06:33:42 EST 2006,
To: Wed Apr 12 07:33:42 EDT 2034]
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
SerialNumber: [ 45697b96]

]
Algorithm: [MD5withRSA]
Signature:
0000: 1A 35 AD 99 24 0A 8C 09 58 0C FC B4 B3 F8 3F DC .#.$...X.....?.
0010: 44 BF 56 A2 3A 5D E5 DF 0D CF D2 59 51 F2 6E 1C D.V.:].....YQ.n.
0020: 2A C0 03 9B 7C 3F 8B 53 C8 E9 16 A7 BC 28 23 C1 *....?.S.....(#.
0030: 67 F3 E4 05 D9 55 13 65 2E E3 80 BA A3 0A 9C F6 g....U.e........
0040: A1 50 46 90 D7 E0 8F 50 6C E4 00 5D 3F F8 D0 62 .PF....Pl..]?..b
0050: D2 A9 47 DF 65 3B 02 E8 1C 04 8A 3C 7B 19 B3 EB ..G.e;.....<....
0060: B6 50 23 6E C6 8A 49 95 6E 38 70 D2 2B 40 31 A5 .P#n..I.n8p.+@#
0070: FE 3F 44 EF 3A E4 12 69 46 D1 4F A0 83 40 F7 F3 .?D.:..iF.O..@..
]
***
S -> C { cert_type || good_cert_authorities}
S -> C {end_round_2}
</pre>
====Round 3 : Client validates the Server certificate====
<pre>
C -> S {client_cert}
C -> S {pre master secret}
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
Random Secret: { 3, 1, 161, 37, 5, 17, 154, 202, 73, 33, 75, 50, 61, 242, 44, 252, 232, 80, 161, 185, 2, 61, 154, 54, 177, 192, 141, 235, 95, 174, 219, 216, 251, 150, 189, 99, 188, 180, 15, 253, 28, 168, 85, 124, 17, 124, 218, 101 }
C -> S {hash(master secret || padding value || hash(messages || master secret || padding value))}
where messages refers to concatenation messages exchanged from 1 through #
</pre>
====Round 4 : Acknowledgment between Client and the Server====
<pre>
The client updates the session and connection information to reflect the cipher it uses and then sends a “finished” message
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
[read] MD5 and SHA1 hashes: len = 134
0000: 10 00 00 82 00 80 10 D4 F8 1C 1D 96 62 B2 59 DD ............b.Y.
0010: D6 F8 F1 0F A5 5E 75 0F 4F 3D 5B 56 2C 6A 24 FD .....^u.O=[V,j$.
0020: 4A 90 D4 3A F3 3F 7E 22 D2 00 18 3B 7D 3F CD 02 J..:.?."...;.?..
0030: 0C E1 11 7C 12 59 D8 A3 85 8D CB 23 B7 90 1C 59 .....Y.....#...Y
0040: 94 65 5F 7E 8E 46 6D A9 7D FC 54 5D 81 DC 69 82 .e_..Fm...T]..i.
0050: 1A EE 1A A5 F1 52 66 A6 43 34 EE E0 F7 12 36 CF .....Rf.C#...#
0060: 7A 38 48 5A C9 8E 11 CB AE 7A 36 2D FD 0B CD 1A z8HZ.....z6-....
0070: 0B F1 45 1E C6 71 D9 57 39 80 75 BF D6 68 43 15 ..E..q.W#u..hC.
0080: FE 4D 67 DC 2F BD .Mg./.
[Raw read]: length = 5
0000: 14 03 01 00 01 .....
[Raw read]: length = 1
0000: 01 .
main, READ: TLSv1 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 01 00 20 ....
[Raw read]: length = 32
0000: C7 D8 CC 69 F7 F7 7F 00 29 F6 23 C8 DD 11 50 33 ...i....).#...P3
0010: 89 BB 91 21 BD 05 24 8C 5B 77 33 9D 78 0A B4 3C ...!..$.[w#x..<
main, READ: TLSv1 Handshake, length = 32
Padded plaintext after DECRYPTION: len = 32
0000: 14 00 00 0C 01 B0 24 0D BC AD E7 E9 DC CB E4 17 ......$.........
0010: F9 FF 44 03 B2 00 37 12 9C A2 16 62 2E 9E 3C 33 ..D...#...b..<3
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }

Server responds back with a “change cipher spec” message and updates its session and connection information accordingly and sends a finish message.
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 A1 25 05 11 9A CA 49 21 4B 32 3D F2 2C FC ...%....I!K2=.,.
0010: E8 50 A1 B9 02 3D 9A 36 B1 C0 8D EB 5F AE DB D8 .P...=.#..._...
0020: FB 96 BD 63 BC B4 0F FD 1C A8 55 7C 11 7C DA 65 ...c......U....e
CONNECTION KEYGEN:
Client Nonce:
0000: 45 73 A6 71 FA 14 8E E7 8F 4E 48 34 FE 2E C7 27 Es.q.....NH#..'
0010: 92 17 EE 05 6C AB 4B C0 4E AD 1A 97 59 56 3A C5 ....l.K.N...YV:.
Server Nonce:
0000: 45 73 A6 71 21 5B 4E BD 9C B7 8E FD 77 9B 16 C1 Es.q![N.....w...
0010: 2E 00 32 99 A8 AA 13 DC 44 61 62 03 24 E4 67 75 ..#....Dab.$.gu
Master Secret:
0000: B5 AF 35 36 65 B8 2E A9 F0 5C C1 A7 BD 85 98 92 ..56e....\......
0010: 64 61 B6 B9 7D 86 AB C7 72 CA 67 9A E1 C1 C4 3F da......r.g....?
0020: C5 8B 67 1A 49 C9 6E B2 FC AB 65 96 EA 7E 67 8C ..g.I.n...e...g.
Client MAC write Secret:
0000: A4 C0 36 E3 9A D3 8B 67 AA 51 D6 78 59 BF 0A 5E ..#...g.Q.xY..^
Server MAC write Secret:
0000: F7 D0 65 1D 4C 0E 81 0F 1F 76 86 D7 91 68 37 50 ..e.L....v...h7P
Client write key:
0000: A6 C5 F0 7D FE 1C 0E 58 85 00 A5 02 AE 08 B5 0E .......X........
Server write key:
0000: 20 D3 07 A2 02 02 34 67 2C C3 5A 50 7C 0F 87 CB .....4g,.ZP....
... no IV for cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01 ......
*** Finished
verify_data: { 1, 176, 36, 13, 188, 173, 231, 233, 220, 203, 228, 23 }
</pre>
Once the handshake is complete, secure communication can commence.

==The Need for Keytool==
The server needs to generate a certificate and a private key associated with its certificate. This certificate would be sent to the clients who wishes to communicate with the server. These functionalities of Key generation, Key management , certificate management are taken care by a tool provided by Sun known as keytool. Keytool uses keystores to store the public / private keys as well as certificates.
keystores are datastores implemented as files. Private keys are protected with passwords.

===Algorithms supported by Keytool===
Keytool supports any algorithm implemented by the registered cryptographic service providers. Default key pair generation algorithm is DSA with a keysize of 1024 bits. The signature algorithm is derived from the algorithm of the private keys. DSA gets coupled with SHA1 by default and so "SHA1withDSA" would be used. RSA gets coupled with MD5 and so "MD5withRSA" would be used.

===Some of the frequently used functions of keytool are:===
==== Generating keys using keytools====
Key pairs can be generated using keytool with the following command and options
<pre>
$bash # keytool -genkey -alias testkey -keystore testkeystore.ks
Enter keystore password: testpwd
What is your first and last name?
[Unknown]: Tom
What is the name of your organizational unit?
[Unknown]: security
What is the name of your organization?
[Unknown]: ABC Inc
What is the name of your City or Locality?
[Unknown]: Fort Meade
What is the name of your State or Province?
[Unknown]: MA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US correct?
[no]: y

Enter key password for <testkey>
(RETURN if same as keystore password):
</pre>
* The option ''-genkey'' is used to generate the keys.
* ''-alias'' specifies the name of the key. This can be verified by the command keytool -list -keystore testkeystore.ks
* ''-keystore'' is the name of the keystore to where the key needs to be added. If no keystore name is specified, the generated keys will be added to the default keystore. The default keystore gets autogenerated when the first key is created and is located in the users home directory with an ".keystore" extension.<br>

The following defaults would be applied during the genkey process:
* keyalg - defaults to DSA
* keysize - defaults to 1024 bits
* validity - defaults to 90 days

====Importing certificates into keystore from .cer files====
A certificate represented usually by a .cer file is imported into the keystore so that it gets added to the list of trusted certificates.
<pre>
$bash # keytool -import -keystore testkeystore.ks -file ssltest.cer
Enter keystore password: testpwd
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5
Trust this certificate? [no]: yes
Certificate was added to keystore
</pre>
The certificate ssltest.cer is successfully imported into the keystore. The serial number generated is unique to this certificate and is useful during certificate revocations. When a certificate is revoked, the serial number gets added to the CRL (Certificate revocation list).
'''Warning:'''
'''Before importing a certificate, validate if the certificate really belongs to the entity it claims to represent.'''
====Use the keytool -printcert -file ssltest.cer to view the contents of the certificate====
<pre>
$bash # keytool -printcert -file ssltest.cer
Owner: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Issuer: CN=Jane P, OU=Network Admins, O=NewCo, L=Denver, ST=CO, C=US
Serial number: 45697b96
Valid from: Sun Nov 26 06:33:42 EST 2006 until: Wed Apr 12 07:33:42 EDT 2034
Certificate fingerprints:
MD5: BD:AA:A5:77:AC:92:17:0E:D3:6E:E2:8F:2B:12:A5:6C
SHA1: 2F:BF:88:E1:2F:26:B9:C3:64:5E:C5:7F:F4:BF:43:7F:37:3D:BE:C5

# Verify from the Issuer of the certificate if the Certificate fingerprint matches.
</pre>

==== Exporting certificates from keystore to files====
To export a certificate from a keystore to a file, the following command could be used
<pre>
$bash # keytool -export -alias testkey -keystore testkeystore.ks -file testkey.cer
Enter keystore password: testpwd
Certificate stored in file <testkey.cer>
Now you can verify the contents of the exported certificate using the command.
$bash # keytool -printcert -file testkey.cer
Owner: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Issuer: CN=Tom, OU=security, O=ABC Inc, L=Fort Meade, ST=MA, C=US
Serial number: 45736152
Valid from: Sun Dec 03 18:44:18 EST 2006 until: Sat Mar 03 18:44:18 EST 2007
Certificate fingerprints:
MD5: 8F:D3:EA:E7:B0:CF:9C:03:16:2F:3F:C9:6C:BC:5A:D4
SHA1: 03:2B:C6:BD:D9:82:31:08:F1:88:3C:35:AD:8D:F9:C3:90:5E:53:6F
</pre>
==Examples==
===SSLClient.java===
<pre>
package org.owasp.crypto;

import java.io.*;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;
import java.security.Security;

/**
* @author Joe Prasanna Kumar
* This program simulates a client socket program which communicates with the SSL Server
*
* Algorithm:
* 1. Determine the SSL Server Name and port in which the SSL server is listening
* 2. Register the JSSE provider
* 3. Create an instance of SSLSocketFactory
* 4. Create an instance of SSLSocket
* 5. Create an OutputStream object to write to the SSL Server
* 6. Create an InputStream object to receive messages back from the SSL Server
*
*/

public class SSLClient {

/**
* @param args
*/
public static void main(String[] args) throws Exception{
String strServerName = "localhost"; // SSL Server Name
int intSSLport = 4443; // Port where the SSL Server is listening
PrintWriter out = null;
BufferedReader in = null;

{
// Registering the JSSE provider
Security.addProvider(new Provider());
}

try {
// Creating Client Sockets
SSLSocketFactory sslsocketfactory = (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket)sslsocketfactory.createSocket(strServerName,intSSLport);

// Initializing the streams for Communication with the Server
out = new PrintWriter(sslSocket.getOutputStream(), true);
in = new BufferedReader(new InputStreamReader(sslSocket.getInputStream()));

BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in));
String userInput = "Hello Testing ";
out.println(userInput);

while ((userInput = stdIn.readLine()) != null) {
out.println(userInput);
System.out.println("echo: " + in.readLine());
}

out.println(userInput);

// Closing the Streams and the Socket
out.close();
in.close();
stdIn.close();
sslSocket.close();
}

catch(Exception exp)
{
System.out.println(" Exception occurred .... " +exp);
exp.printStackTrace();
}

}

}
</pre>

===SSLServer.java===
<pre>
package org.owasp.crypto;

import java.io.*;
import java.security.Security;
import java.security.PrivilegedActionException;

import javax.net.ssl.*;
import com.sun.net.ssl.*;
import com.sun.net.ssl.internal.ssl.Provider;

/**
* @author Joe Prasanna Kumar
* This program simulates an SSL Server listening on a specific port for client requests
*
* Algorithm:
* 1. Regsiter the JSSE provider
* 2. Set System property for keystore by specifying the keystore which contains the server certificate
* 3. Set System property for the password of the keystore which contains the server certificate
* 4. Create an instance of SSLServerSocketFactory
* 5. Create an instance of SSLServerSocket by specifying the port to which the SSL Server socket needs to bind with
* 6. Initialize an object of SSLSocket
* 7. Create InputStream object to read data sent by clients
* 8. Create an OutputStream object to write data back to clients.
*
*/

public class SSLServer {

/**
* @param args
*/

public static void main(String[] args) throws Exception{

int intSSLport = 4443; // Port where the SSL Server needs to listen for new requests from the client

{
// Registering the JSSE provider
Security.addProvider(new Provider());

//Specifying the Keystore details
System.setProperty("javax.net.ssl.keyStore","server.ks");
System.setProperty("javax.net.ssl.keyStorePassword","JsEkey@4");

// Enable debugging to view the handshake and communication which happens between the SSLClient and the SSLServer
// System.setProperty("javax.net.debug","all");
}

try {
// Initialize the Server Socket
SSLServerSocketFactory sslServerSocketfactory = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
SSLServerSocket sslServerSocket = (SSLServerSocket)sslServerSocketfactory.createServerSocket(intSSLport);
SSLSocket sslSocket = (SSLSocket)sslServerSocket.accept();

// Create Input / Output Streams for communication with the client
while(true)
{
PrintWriter out = new PrintWriter(sslSocket.getOutputStream(), true);
BufferedReader in = new BufferedReader(
new InputStreamReader(
sslSocket.getInputStream()));
String inputLine, outputLine;

while ((inputLine = in.readLine()) != null) {
out.println(inputLine);
System.out.println(inputLine);
}

// Close the streams and the socket
out.close();
in.close();
sslSocket.close();
sslServerSocket.close();

}
}

catch(Exception exp)
{
PrivilegedActionException priexp = new PrivilegedActionException(exp);
System.out.println(" Priv exp --- " + priexp.getMessage());

System.out.println(" Exception occurred .... " +exp);
exp.printStackTrace();
}

}

}

</pre>

==References==
* Computer Security – Arts and Science - Matt Bishop
* Core Security Patterns – Christopher Steele, Ray Lai and Ramesh Nagappan
* http://java.sun.com/j2se/##2/docs/tooldocs/windows/keytool.html
* http://blogs.borland.com/krish/archive/2005/07/28/#aspx

[[Category:OWASP Java Project]]

The Owasp Orizon Framework

2010-10-21T18:58:19Z

Ari Elias-Bachrach: spelling only

{{LinkBar
| useprev=PrevLink | prev=Code Auditor Workbench Tool | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=The Owasp Code Review Top 9 | lblnext=
}}
__TOC__

== Introduction ==
A lot of open source projects exist in the wild, performing static code review analysis. This is good, it means that source code testing for security issues is becoming a constraint.

Such tools bring a lot of valuable points:
* community support
* source code freely available to anyone
* costs

On the other side, these tools don't share the most valuable point among them: the security knowledge. All these tools have their own security library, containing a lot of checks, without sharing such knowledge.

In 2006, the Owasp Orizon project was born to provide a common underlying layer to all opensource projects concerning static analysis.

Orizon project includes:
* a set of APIs that developers can use to build their own security tool performing static analysis.
* a security library with checks to apply to source code.
* a tool, Milk, which is able to static analyze a source code using Orizon Framework.

== The Owasp Orizon Architecture ==
In the following picture, the Owasp Orizon version 1.0 architecture is shown. As you may see, the framework is organized in engines that perform tasks over the source code and a block of tools that are deployed out of the box in order to use the APIs in a real world static analysis.

[[Image:Owasp_Orizon_Architecture_v1.0.png|400px|The Owasp Orizon v1.0 architecture]]

With all such elements, a developer can be scared to use the framework; that's why a special entity called SkyLine was created. Before going further into SkyLine analysis, it's very important to understand all the elements Orizon is made of.

=== Your personal butler: the SkyLine class ===
Named '''core''' in the architectural picture, the SkyLine object is one of the most valuable services in Orizon version 1.0.

The idea behind SkyLine is simple: as the Orizon architecture becomes wider, regular developers may be scared about understanding a lot of APIs in order to build their security tool, so we can help them providing "per service" support.

Using SkyLine object, developers can request services from the Orizon framework waiting for their accomplishment.

The main SkyLine input is:

'''public boolean launch(String service)'''

Passing the requested service as string parameter, the calling program will receive a boolean true return value if the service can be accomplished or a false value otherwise.

The service name is compared to the ones understood by the framework:

'''private int goodService(String service) {
''' int ret = -1;
''' if (service.equalsIgnoreCase("init"))
''' ret = Cons.OC_SERVICE_INIT_FRAMEWORK;
''' if (service.equalsIgnoreCase("translate"))
''' ret = Cons.OC_SERVICE_INIT_TRANSLATE;
''' if (service.equalsIgnoreCase("static_analysis"))
''' ret = Cons.OC_SERVICE_STATIC_ANALYSIS;
''' if (service.equalsIgnoreCase("score"))
''' ret = Cons.OC_SERVICE_SCORE;
''' return ret;
'''}

The secondary feature introduced in this first major framework release is the support for command line option given to the user.

If the calling program passes command line option to Orizon framework using SkyLine, the framework will be tuned accordingly to the given values.

This example will explain better:

'''public static void main(String[] args) {
''' String fileName = "";
''' OldRecipe r;
''' DefaultLibrary dl;
'''
''' SkyLine skyLine = new SkyLine(args);

That's all folks! Internally, the SkyLine constructor, when it creates a code review session, uses the values it was able to understand from command line.

The command line format must follow this convention

''' -o orizon_key=value
or the long format
''' --orizon orizon_key=value

And these are the keys that the framework cares about:
* "input-name"
* "input-kind"
* "working-dir"
* "lang"
* "recurse"
* "output-format"
* "scan-type";

The org.owasp.orizon.Cons class contains a detailed section about these keys with some comments and with their default value.

The only side effect is that calling program can use -o flag for its purpose.

SkyLine is contained in the org.owasp.orizon package.

=== Give me something to remind: the Session class ===
Another big feature introduced in Owasp Orizon version 1.0 is the code review session concept. One of the missing features in earlier versions was the capability to track the state of the code review process.

A Session class instance contains all the properties specified using SkyLine and it is their owner giving access to properties upon request. It contains a SessionInfo array containing information about each file being reviewed.

Ideally, a user tool will never call Session directly, but it must use SkyLine as interface. Of course anyone is free to override this suggestion.

Looking at the launch() method code, inside the SkyLine class, you can look how session instance is prompted to execute services.

'''public boolean launch(String service) {
''' int code, stats;
''' boolean ret = false;
'''
''' if ( (code = goodService(service)) == -1)
''' return log.error("unknown service: " + service);
''' switch (code) {
''' // init service
''' case Cons.OC_SERVICE_INIT_FRAMEWORK:
''' ret = session.init();
''' break;
''' // translation service
''' case Cons.OC_SERVICE_INIT_TRANSLATE:
''' stats = session.collectStats();
''' if (stats > 0) {
''' log.warning(stats + " files failed in collecting statistics.");
''' ret = false;
''' } else
''' ret = true;
''' break;
''' // static analysis service
''' case Cons.OC_SERVICE_STATIC_ANALYSIS:
''' ret = session.staticReview();
''' break;
''' // score service
''' case Cons.OC_SERVICE_SCORE:
''' break;
''' default:
''' return log.error("unknown service: " + service);
''' }
''' return ret;
'''}

Internally, the Session instance will ask each SessionInfo object to execute services. Let us consider the Session class method that executes the static analysis service.

'''/**
''' * Starts a static analysis over the files being reviewed
''' *
''' * @return <i>true</i> if static analysis can be performed or <i>false</i>
''' * if one or more files fail being analyzed.
''' */
'''public boolean staticReview() {
''' boolean ret = true;
''' if (!active)
''' return log.error("can't perform a static analysis over an inactive session.");
''' for (int i = 0; i < sessions.length; i++) {
''' if (! sessions[i].staticReview())
''' ret = false;
''' }
''' return ret;
'''}

Where sessions variable is declared as:
'''private SessionInfo[] sessions;

As you may see, the Session object delegates service accomplishment to SessionInfo once collecting the final results.

In fact, SessionInfo objects are the ones talking with Orizon internals performing the real work.

The following method is stolen from org.owasp.orizon.SessionInfo class.

'''/**
''' * Perform a static analysis over the given file
''' *
''' * A full static analysis is a mix from:
''' *
''' * * local analysis (control flow)
''' * * global analysis (call graph)
''' * * taint propagation
''' * * statistics
''' *
''' *
''' * @return <i>true</i> if the file being reviewed doesn't violate any
''' * security check, <i>false</i> otherwise.
''' */
''' public boolean staticReview() {
''' boolean ret = false;
''' s = new Source(getStatFileName());
''' ret = s.analyzeStats();
''' ...
''' return ret;
''' }

=== The Translation Factory ===
One of the Owasp Orizon goals is to be independent from the source language being analyzed. This means that Owasp Orizon will support:
* Java
* C, C++
* C#
* Perl
* ...
Such support is granted using an intermediate file format to describe the source code and used to apply the security checks. Such format is XML language.

A source code, before static analysis is started, is translated into XML. Starting from version 1.0, each source code is translated in 4 XML files:

* an XML file containing statistical information
* an XML file containing variables tracking information
* an XML file containing program control flow (local analysis)
* an XML file containing call graph (global analysis)

At the time this document is written (Owasp Orizon v1.0pre1, September 2008), only the Java programming language is supported, however other programming language will follow soon.

Translation phase is requested from org.owasp.orizon.SessionInfo.inspect() method. Depending on the source file language, the appropriate Translator is called and the scan() method is called.

''' /**
''' * Inspects the source code, building AST trees
''' * @return
''' */
''' public boolean inspect() {
''' boolean ret = false;
''' switch (language) {
''' case Cons.O_JAVA:
''' t = new JavaTranslator();
''' if (!t.scan(getInFileName()))
''' return log.error("can't scan " + getInFileName() + ".");
''' ret = true;
''' break;
''' default:
''' log.error("can't inspect language: " + Cons.name(language));
''' break;
''' }
''' return ret;
''' }

Scan method is an abstract method defined in org.owasp.orizon.translator.DefaultTranslator class and declared as the following:

''' public abstract boolean scan(String in);

Every class implementing DefaultTranslator must implement how to scan the source file and build ASTs in this method.

Aside from scan() method, there are four abstract method needful to create XML input files.

''' public abstract boolean statService(String in, String out);
''' public abstract boolean callGraphService(String in, String out);
''' public abstract boolean dataFlowService(String in, String out);
''' public abstract boolean controlFlowService(String in, String out);

All these methods are called in the translator() method, the one implemented directly from DefaultTranslator class.

''' public final boolean translate(String in, String out, int service) {
''' if (!isGoodService(service))
''' return false;
''' if (!scanned)
''' if (!scan(in))
''' return log.error(in+ ": scan has been failed");
''' switch (service) {
''' case Cons.OC_TRANSLATOR_STAT:
''' return statService(in, out);
''' case Cons.OC_TRANSLATOR_CF:
''' return controlFlowService(in, out);
''' case Cons.OC_TRANSLATOR_CG:
''' return callGraphService(in, out);
''' case Cons.OC_TRANSLATOR_DF:
''' return dataFlowService(in, out);
''' default:
''' return log.error("unknown service code");
''' }
''' }

So, when a language specific translator is prompted for translate() method, this recalls the language specific service methods.

Every translator contains as private field, a language specific scanner containing ASTs to be used in input file generation.

Consider org.owasp.orizon.translator.java.JavaTranslator class, it is declared as follows:

''' public class JavaTranslator extends DefaultTranslator {
''' static SourcePositions positions;
''' private JavaScanner j;
''' ...

JavaScanner is a class from org.owasp.orizon.translator.java package and it uses Sun JDK 6 Compiler API to scan a Java file creating in memory ASTs. Trees are created in scan() method, implemented for Java source language as follow:

''' public final boolean scan(String in) {
''' boolean ret = false;
''' String[] parms = { in };
''' Trees trees;
'''
''' JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
''' if (compiler == null)
''' return log.error("I can't find a suitable JAVA compiler. Is a JDK installed?");
'''
''' DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<JavaFileObject>();
''' StandardJavaFileManager fileManager = compiler.getStandardFileManager(diagnostics, null, null);
''' Iterable<? extends JavaFileObject> fileObjects = fileManager.getJavaFileObjects(parms);
'''
''' JavacTask task = (com.sun.source.util.JavacTask) compiler.getTask(null,fileManager, diagnostics, null, null, fileObjects);
'''
''' try {
''' trees = Trees.instance(task);
''' positions = trees.getSourcePositions();
''' Iterable<? extends CompilationUnitTree> asts = task.parse();
''' for (CompilationUnitTree ast : asts) {
''' j = new JavaScanner(positions, ast);
''' j.scan(ast, null);
''' }
''' scanned = true;
''' return true;
''' } catch (IOException e) {
''' return log.fatal("an exception occurred while translate " + in + ": " +e.getLocalizedMessage());
''' }
''' }

===Statistical Gathering ===
To implement statistic information gathering, DefaultTranslator abstract method statService() must be implemented. In the following example, the method is the JavaTranslator's. Statistics information is stored in the JavaScanner object itself and retrieved by getStats() method.

''' public final boolean statService(String in, String out) {
''' boolean ret = false;
'''
''' if (!scanned)
''' return log.error(in + ": call scan() before asking translation...");
''' log.debug(". Entering statService(): collecting stats for: " + in);
''' try {
''' createXmlFile(out);
''' xmlInit();
''' xml("<source name=\"" + in+"\" >");
''' xml(j.getStats());
''' xml("</source>");
''' xmlEnd();
'''
''' } catch (FileNotFoundException e) {
''' } catch (UnsupportedEncodingException e) {
''' } catch (IOException e) {
''' ret = log.error("an exception occurred: " + e.getMessage());
''' }
''' ret = true;
''' log.debug("stats written into: " + out);
''' log.debug(". Leaving statService()");
''' return ret;
''' }

== Reference ==

To anyone interested in Owasp Orizon framework, you can use the following links:
* main page @ Owasp: [[::Category:OWASP_Orizon_Project|OWASP Orizon Project]]
* main site @ SourceForge: [http://orizon.sourceforge.net http://orizon.sourceforge.net]
* blog: [http://orizon.sourceforget.net/blog http://orizon.sourceforge.net/blog]
* author page @ Owasp: [http://www.owasp.org/index.php/User:Thesp0nge http://www.owasp.org/index.php/User:Thesp0nge]

You can drop also a line to Orizon author: [mailto:thesp0nge@owasp.org thesp0nge@owasp.org]
'''foo'''

{{LinkBar
| useprev=PrevLink | prev=Code Auditor Workbench Tool | lblprev=
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=The Owasp Code Review Top 9 | lblnext=
}}

[[Category:OWASP Code Review Project]]

Codereview-Input Validation

2010-10-21T17:23:35Z

Ari Elias-Bachrach: readability improvements

{{LinkBar
| useprev=PrevLink | prev=Codereview-Session-Management | lblprev=Session Management
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Codereview-Error-Handling | lblnext=Error Handling
}}
__TOC__

==Introduction==
Input validation is one of the most effective technical controls for application security. It can mitigate numerous vulnerabilities including cross-site scripting, various forms of injection, and some buffer overflows. Input validation is more than checking form field values. The chapter on transactional analysis talks about this.

===Data Validation===
All external input to the system should undergo input validation. The validation rules are defined by the business requirements for the application. If possible, an exact match validator should be implemented. Exact match only permits data that conforms to an expected value. A "Known good" approach (white-list), which is a little weaker, but more flexible, is common. Known good only permits characters/ASCII ranges defined within a white-list. Such a range is defined by the business requirements of the input field. The other approaches to data validation are "known bad," which is a black list of "bad characters". This approach is not future proof and would need maintenance. "Encode bad" would be very weak, as it would simply encode characters considered "bad" to a format which should not affect the functionality of the application.

===Business Validation===
Business validation is concerned with business logic. An understanding of the business logic is required prior to reviewing the code which performs such logic. Business validation could be used to limit the value range or a transaction inputted by a user or reject input which does not make too much business sense. Reviewing code for business validation can also include rounding errors or floating point issues which may give rise to issues such as integer overflows which can dramatically damage the bottom line.

===Canonicalization===
Canonicalization is the process by which various equivalent forms of a name can be resolved to a single standard name, or the "canonical" name.

The most popular encodings are UTF-8, UTF-16, and so on (which are described in detail in RFC 2279). A single character, such as a period/full-stop (.), may be represented in many different ways: ASCII 2E, Unicode C0 AE, and many others.

With the myriad ways of encoding user input, a web application's filters can be easily circumvented if they're not carefully built.

===Bad Example===
public static void main(String[] args) {
File x = new File("/cmd/" + args[1]);
String absPath = x.getAbsolutePath();
}

===Good Example===
public static void main(String[] args) throws IOException {
File x = new File("/cmd/" + args[1]);
String canonicalPath = x.getCanonicalPath();
}

===References===
'''See Reviewing code for Data Validation (in this guide)'''
[[Reviewing_Code_for_Data_Validation|Reviewing code for Data Validation]]

'''See the OWASP ESAPI Project'''

The [[ESAPI|OWASP ESAPI]] project provides a reference implementation of a security API which can assist in providing security controls to an application.

{{LinkBar
| useprev=PrevLink | prev=Codereview-Session-Management | lblprev=Session Management
| usemain=MainLink | main=OWASP Code Review Guide Table of Contents | lblmain=Table of Contents
| usenext=NextLink | next=Codereview-Error-Handling | lblnext=Error Handling
}}

[[Category:OWASP Code Review Project]]

User:Ari Elias-Bachrach

2010-10-21T16:07:12Z

Ari Elias-Bachrach:

Ari is a CISSP and CEH. He has a BS in computer science from Washington University in St. Louis, and a MS in computer science with a focus on information security from The George Washington University. Previously he worked for the federal government, followed by a stint in the private sector as a consultant performing external penetration testing and web application reviews. Now he works as an in-house information security engineer focusing on web applications.