OWASP - User contributions [en]

Injection Theory

2016-03-28T02:18:33Z

Jeff Williams:

[[Injection Flaws|Injection]] is an attacker's attempt to send data to an application in a way that will change the meaning of commands being sent to an interpreter. For example, the most common example is SQL injection, where an attacker sends "101 OR 1=1" instead of just "101". When included in a SQL query, this data changes the meaning to return ALL records instead of just one. There are lots of interpreters in the typical web environment, such as SQL, LDAP, Operating System, XPath, XQuery, Expression Language, and many more. Anything with a "command interface" that combines data into a command is susceptible. Even XSS is really just a form of HTML injection.

Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server. Taken together, injection attacks are a huge percentage of the serious application security risk. Many organizations have poorly thought through security controls in place to prevent injection attacks. Vague recommendations for input validation and output encoding are not going to prevent these flaws. Instead, we recommend a strong set of controls integrated into your application frameworks. The goal is to make injections impossible for developers.

=Why Injection Happens to Good Developers=

Injection can be complex. The subtleties of data flow, parsers, contexts, capabilities, and escaping are overwhelming even for security specialists. In the following sections we will outline these topics to make it clear how injection can happen in a variety of different technologies.

== Untrusted Data ==

First we need to consider the vehicle for injection attacks -- 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, untrusted data is input that can be manipulated to contain a web attack payload. 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.

As untrusted data flows through an application, it is frequently split into parts, combined with safe data, transformed, validated, and encoded in a variety of ways. A single piece of data could go through dozens of these steps before it gets to an interpreter. This makes identifying injection problems very difficult. Tools have a difficult time tracing the entire data flow and understanding exactly what data can run the gauntlet and what cannot.

== Injection Context ==

When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the '''injection context'''. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.

Consider a few of the types of commands and documents that might allow for injection...
* SQL queries
* LDAP queries
* Operating system command interpreters
* Any program invocation
* XML documents
* HTML documents
* JSON structures
* HTTP headers
* File paths
* URLs
* A variety of expresson languages
* etc...

In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.

== Parsers ==

Every interpreter has a parser. Injection attacks target those parsers -- attempting to trick them into interpreting data as commands. Understanding how a particular interpreter's parser works is the key to successful injection attacks -- and, ultimately, the path to creating defenses against injection.

If you are a student of application security, you should learn as much as you can about how real parsers work. Learn about grammars, and how to read BNF. Beware, though, that the grammar may not match the implementation. Real world parsers have many corner cases and flaws that may not match the spec. A scientific approach to testing the *real* behavior of a parser is the best course forward.

TBD. Describe different types of parsers, tokens (particularly control characters), BNF.

== Injection into References ==

A "reference" could be a database key, a URL, a filename, or some other kind of lookup index. While injecting into these references doesn't typically allow for command execution, it's an interesting because the parsers for these references aren't typically too complicated. However, URLs and filenames can become quite complex. See the "jar:" scheme for examples of non-intuitive syntax begging for injection.

TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)

== Injection into Commands ==

TBD. Recursive descent or LALR parsers.

== Injecting in Hierarchical Documents ==

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.

== Injection with Multiple Nested Parsers ==

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...).

TBD

=DEFENSES=

== Validation ==

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.

== Using Safe Interfaces ==

TBD - parameterized interfaces with strong typing

== 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.

== Author ==

[[User:Jeff Williams]] : jeff.williams[at]contrastsecurity.com

Injection Theory

2016-03-28T02:07:42Z

Jeff Williams:

[[Injection Flaws|Injection]] is an attacker's attempt to send data to an application in a way that will change the meaning of commands being sent to an interpreter. For example, the most common example is SQL injection, where an attacker sends "101 OR 1=1" instead of just "101". When included in a SQL query, this data changes the meaning to return ALL records instead of just one. There are lots of interpreters in the typical web environment, such as SQL, LDAP, Operating System, XPath, XQuery, Expression Language, and many more. Anything with a "command interface" that combines data into a command is susceptible. Even XSS is really just a form of HTML injection.

Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server. Taken together, injection attacks are a huge percentage of the serious application security risk. Many organizations have poorly thought through security controls in place to prevent injection attacks. Vague recommendations for input validation and output encoding are not going to prevent these flaws. Instead, we recommend a strong set of controls integrated into your application frameworks. The goal is to make injections impossible for developers.

=Why Injection Happens to Good Developers=

Injection can be complex. The subtleties of data flow, parsers, contexts, capabilities, and escaping are overwhelming even for security specialists. In the following sections we will outline these topics to make it clear how injection can happen in a variety of different technologies.

== Untrusted Data ==

First we need to consider the vehicle for injection attacks -- 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, untrusted data is input that can be manipulated to contain a web attack payload. 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.

As untrusted data flows through an application, it is frequently split into parts, combined with safe data, transformed, validated, and encoded in a variety of ways. A single piece of data could go through dozens of these steps before it gets to an interpreter. This makes identifying injection problems very difficult. Tools have a difficult time tracing the entire data flow and understanding exactly what data can run the gauntlet and what cannot.

== Injection Context ==

When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the '''injection context'''. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.

Consider a few of the types of commands and documents that might allow for injection...
* SQL queries
* LDAP queries
* Operating system command interpreters
* Any program invocation
* XML documents
* HTML documents
* JSON structures
* HTTP headers
* File paths
* URLs
* A variety of expresson languages
* etc...

In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.

== Parsers ==

TBD. Describe different types of parsers, tokens (particularly control characters), BNF.

== Injection into References ==

TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)

== Injection into Commands ==

TBD. Recursive descent or LALR parsers.

== Injecting in Hierarchical Documents ==

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.

== Injection with Multiple Nested Parsers ==

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...).

TBD

=DEFENSES=

== Validation ==

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.

== Using Safe Interfaces ==

TBD - parameterized interfaces with strong typing

== 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.

== Author ==

[[User:Jeff Williams]] : jeff.williams[at]contrastsecurity.com

XSS (Cross Site Scripting) Prevention Cheat Sheet

2016-03-28T02:06:23Z

Jeff Williams: This section is not for minor contributions and edits

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-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;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

== 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.

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== JSON entity encoding ====

The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary]. Note, this will not allow you to use XSS protection provided by CSP 1.0.

==== HTML entity encoding ====

This technique has the advantage that html entity escaping is widely supported and helps separate data from server side code without crossing any context boundaries. Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
// unescape the content of the span
var jsonText = dataElement.textContent || dataElement.innerText
var initData = JSON.parse(html_unescape(jsonText));

An alternative to escaping and unescaping JSON directly in JavaScript, is to normalize JSON server-side by converting '<' to '\u003c' before delivering it to the browser.

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''HtmlSanitizer''' - https://github.com/mganss/HtmlSanitizer

An open-source .Net library. The HTML is cleaned with a white list approach. All allowed tags and attributes can be configured. The library is unit tested with the [https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet OWASP XSS Filter Evasion Cheat Sheet]

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Ruby on Rails SanitizeHelper''' - http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html

The SanitizeHelper module provides a set of methods for scrubbing text of undesired HTML elements.

<%= sanitize @comment.body, tags: %w(strong em a), attributes: %w(href) %>

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule #1: Use 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]].

== Bonus Rule #2: Implement Content Security Policy ==

There is another good complex solution to mitigate the impact of an XSS flaw called Content Security Policy. It's a browser side mechanism which
allows you to create source whitelists for client side resources of your web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header instructs the browser to only execute or render resources from those sources. For example this CSP

Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld

will instruct web browser to load all resources only from the page's origin and JavaScript source code files additionaly from static.domain.tld. For more details on Content Security Policy, including what it does, and how to use it, see the OWASP article on [[Content_Security_Policy]]

== Bonus Rule #3: Use an Auto-Escaping Template System ==

Many web application frameworks provide automatic contextual escaping functionality such as [https://docs.angularjs.org/api/ng/service/$sce AngularJS strict contextual escaping] and [https://golang.org/pkg/html/template/ Go Templates]. Use these technologies when you can.

== Bonus Rule #4: Use the X-XSS-Protection Response Header ==

This HTTP response header enables the Cross-site scripting (XSS) filter built into some modern web browsers. This header is usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user.

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Canonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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:

* OWASP: [[XSS Filter Evasion Cheat Sheet]] - Based on - RSnake's: "XSS Cheat Sheet"

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''Description of XSS Vulnerabilities'''

* OWASP article on [[XSS]] Vulnerabilities

'''Discussion on the Types of XSS Vulnerabilities'''

* [[Types of Cross-Site Scripting]]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]contrastsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Neil Mattatall - neil[at]owasp.org

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]
[[Category:Popular]]

User:Jeff Williams

2015-10-04T20:56:09Z

Jeff Williams:

I'm Jeff Williams, I'm the CTO and cofounder of [http://contrastsecurity.com Contrast Security]. Contrast is not a scanner or static analysis tool. Instead, Contrast uses software instrumentation to *both* find vulnerabilities and block attacks. The instrumentation approach provides access to not only the code and HTTP traffic, but also full data flow, control flow, configuration, libraries and frameworks, architecture, and much more. This wealth of information yields incredible accuracy. And that's not all... because Contrast runs in parallel and provides results in real time, you can provide security at [http://www.contrastsecurity.com/jeff-williams-appsec-at-devops-speed-and-portfolio-scale devops speed and portfolio scale].

in the early 2000's, I helped found OWASP, created the OWASP Foundation 501c3, and served as the volunteer Chair of the OWASP Foundation from 2003 to 2012. I’ve dedicated my life to trying to make the world’s software more secure, and so I create lots of free and open tools, libraries, guidance, and standards to try to change the status quo. Thank you all for your dedication to application security and your participation in OWASP. Please send any questions or comments to me via email at [mailto:jeff.williams@contrastsecurity.com jeff.williams@contrastsecurity.com]. Or you can twitter @planetlevel.

last revised {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

I'm particularly proud of this free tool that uses instrumentation to find vulnerabilities. Far easier to use and more accurate than static (SAST) or dynamic analysis (DAST) scanners.
* FREE tool - Contrast for Eclipse - http://marketplace.eclipse.org/content/contrast-eclipse

Also please read the "Continuous Security Handbook" which reinterprets application security for high-speed DevOps environments.
* FREE CAS Handbook - http://www1.contrastsecurity.com/continuous-app-security

Some of my other work (in roughly reverse chronological order)
* Enterprise Java Rootkits - https://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf
* XSS-Proofing Your JavaEE, JSP, and JSP Applications - http://www.oracle.com/technetwork/server-storage/ts-4374-159351.pdf
I'm an official [https://www.oracle.com/javaone/rock-stars/index.html#jwilliams Java Rock Star]!
* XSS Prevention Cheatsheet – http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
* Java EE ClickJack Filter - http://www.owasp.org/index.php/ClickjackFilter_for_Java_EE
* Enterprise Security API – http://www.owasp.org/index.php/ESAPI
* Application Security Verification Standard - http://www.owasp.org/index.php/ASVS
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java PDF Attack Filter - http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE
* Application Security Risk Rating Model - http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
* CSRF Tester Tool - http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java Stinger Validation Library - http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
* Application Security Contract Annex - http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
* OWASP Chapters Program - http://www.owasp.org/index.php/Category:OWASP_Chapter
* OWASP Foundation - http://www.owasp.org/index.php/OWASP_Foundation
* OWASP Top Ten – http://www.owasp.org/index.php/Topten
* WebGoat Application Security Learning Environment - http://www.owasp.org/index.php/Webgoat
* Systems Security Engineering CMM - http://sse-cmm.org/index.html

To see my wiki contributions, [[:Special:Contributions/Jeff Williams|click here]].

==Background==

My background, from an [http://myappsecurity.blogspot.com/2007/03/reflection-on-jeff-williams.html interview]

I set out to be a user interface guy, but I got into security accidentally. I was working at TRW in 1992 on the user interface for a big Navy system that just happened to be highly secure – targeting B2 in the Orange Book. I took on an R&D project to port the user interface to the new compartmented mode workstation (what became Trusted Solaris) and I found that I really liked the challenge of securing such a complex system.

Then Java 1.0 came along and I got NIST and NRL funding to do security research. At the time, we thought the Java sandbox was a good idea, but that there were attacks that might bypass it. So I wrote a special classloader that modified the bytecode to wrap security relevant method calls with a reference monitor. After that I spent several years developing a Java-based multilevel secure network guard on Trusted Solaris. That guard handled HTTP, FTP, TDS, and a number of other protocols – sort of a very early application firewall. But unlike the modern WAFs, we took a whitelist approach where you would define exactly the data formats and rules for allowing messages.

In the mid-90’s, I chaired the group that authored the SSE-CMM, which is now ISO 21827. As it turns out, the processes involved in systems security engineering are quite similar to those necessary for secure software development. I’m very glad to see that the idea of assurance arguments from my work is starting to be used in the application security world.

Then in 1998, while I was the technical director of the Global Security Practice at Exodus Communications, a Fortune 10 company approached us and said “We’d like to host our applications with you, but we have this rule – every line of code has to be reviewed before it goes on the Internet.” So I started an application security practice and started providing application assessments, developer training, and help with security requirements and architecture. We built a successful practice securing some of the biggest and most complex web applications in the world.

In April 2002, together with Dave Wichers, Noelle Hardy, and some other great folks, I started [http://aspectsecurity.com Aspect Security] to focus exclusively on application security. I just feel so fortunate to work with such an amazing group of consultants and customers. I’m having the most fun of my professional career.

I first heard of OWASP in 2001 from Chuck Pfleeger (the author of Security in Computing). The idea of a free and open community for application security was an interesting idea. At the time, getting companies to focus on application security was difficult. In meetings with several government agencies, they acknowledged that it was an issue, but that they were managing to the SANS Top 20. I came home and literally in the shower said to myself, “I wish we had an application security top ten…” So a small team of us at Aspect took the lead in drafting the first OWASP Top Ten.

Later, Aspect donated WebGoat, a hands-on training environment for application security issues that we had developed for our courses. A huge number of organizations, including Google, use WebGoat today to teach their developers about application security. We started to see that participation in OWASP allowed Aspect to demonstrate our skills in a very constructive way, and many of our customers have contacted us after seeing our participation in OWASP.

I was honored to take over the leadership of OWASP in 2003. At that time, we had a number of great contributors, but OWASP itself was just a domain name and a few small projects. So I got us set up as a 501c3 nonprofit organization and put a management structure in place. I want the OWASP Foundation to provide a free, open, supportive community infrastructure for application security projects. We’re making the barriers to entry for contribution so low that security experts will be motivated to make the effort and share their expertise.

One of the key challenges has been to ensure that OWASP is not influenced by commercial interests. When I set up the AppSec conference and local chapter rules, I made sure that vendors are cannot use OWASP to market their products. We’re also starting to ferret out abuse of the OWASP brand by companies that claim their products “address the OWASP Top Ten” or enable “OWASP Compliance.” The local chapters have been growing very quickly and starting to contribute back to the mothership. Our conferences have also been a great experience.

I think the switch to the MediaWiki platform in 2006 was a major step for OWASP. Prior to that, contributing content was a difficult and painful process. Now, anyone can create an account and contribute easily. We have a team set up to review all the contributions and the number of abuses in our first year has been astoundingly low (less than 10 incidents). We’re to the point now where we get dozens of articles and contributions every day. I don’t see how a non-open approach to building an application security body of knowledge can possibly keep up with our productivity.

We’re still a long way from the point where a company can go to OWASP for everything they need in order to build, acquire, and operate secure applications… but we’ve got an incredible process and we’re working very hard to get there.

I have big family and absolutely love my kids. We live in the woods and spend a lot of time outside with our two Labrador retrievers. I’m very much into sports – I rowed on the crew team at UVA and still play basketball three times a week (if you meet me you'll know why). For a while I was into extreme rollerblading and then I got into mountain bike trials – I broke a lot of equipment, but never had any serious injuries :)"

==Articles / Presentations==

Opening the Black Box: A Source Code Security Analysis Case Study
http://www.aspectsecurity.com/documents/Aspect_Opening_Black_Box.doc

Application Security Initiatives - The Best Defense Is a Good Offense
http://www.aspectsecurity.com/documents/Application_Security_Initiatives.htm

Let's Sue the Idiots -- Security, Software, Contracts, and Lawyers
http://www.aspectsecurity.com/article/sscl.htm

How to Build an HTTP Request Validation Engine for Your J2EE Application
http://www.aspectsecurity.com/article/bld_HTTP_req_val_engine.htm

Access Control (aka Authorization) in Your J2EE Application
http://www.aspectsecurity.com/article/access_control.htm

Trustworthy Java - Are your apps bulletproof?
http://www.aspectsecurity.com/article/trust_java.htm

The Ten Most Critical Web Application Security Vulnerabilities
http://www.aspectsecurity.com/owasp.htm

Security Code Review - the Best Way to Eliminate Vulnerabilities in Software" -
http://www.aspectsecurity.com/documents/AspectCodeReviewWhitePaper.pdf

Can a 'Social Protocol' Help Protect Privacy?
http://www.aspectsecurity.com/documents/p3p.pdf

Jini and Mobile Agent Security - Proceedings of the Workshop on Agent Technologies (AT ‘98)
http://www.aspectsecurity.com/documents/jini.pdf

A Practical Approach to Improving and Communicating Assurance - Proceedings of the 10th Canadian Information Technology Security Symposium (CITSS)
http://www.aspectsecurity.com/documents/Arguing.pdf

A Practical Approach to Measuring Assurance - Proceedings of the 1998 Security Applications Conference (ACSAC)
http://www.aspectsecurity.com/documents/Measuring.pdf

System Security Engineering Capability Maturity Model (SSE-CMM) version 2.0 - Released at the 21st Annual National Information System Security Conference (NISSC)
http://www.aspectsecurity.com/documents/SSECMMv2Final.pdf

Just Sick about Security - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Sick.pdf

An Enterprise Assurance Framework - Proceedings of the 5th Workshop on Enabling Technologies
http://www.aspectsecurity.com/documents/WetIce.pdf

Pretty Good Assurance - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Pretty.pdf

Need for a Framework for Reasoning about Assurance - Proceedings of the International Workshop on IT Assurance and Trustworthiness (WITAT)
http://www.aspectsecurity.com/documents/Need.pdf

Assurance is an N-Space (Where N is Hopefully Small) - Proceedings of the International Invitational Workshop on Developmental Assurance
http://www.aspectsecurity.com/documents/Nspace.pdf

A Capability Maturity Model For Security Engineering - Proceedings of the 6th Annual Canadian Computer Security Symposium
http://www.aspectsecurity.com/documents/CITSS94.doc

Unsafe at Any (CPU) Speed: Why We Keep Making the Same Mistakes - NSA High Confidence Software and Systems Conference

Web Applications: The “Last Mile” of Internet Security

A Constructionist Approach to Law and Society - Law and Society Seminar, Georgetown University Law Center

Interpreting Anticircumvention (DMCA) - Advanced International Copyright Law, Georgetown University Law Center

P3I – Protection Profile Process Improvement - Proceedings of the 22nd National Information System Security Conference (NISSC)

Windows NT Security - 17th Annual National Computer Security Conference (NCSC)

Windows NT Client Security and Windows NTAS Security - The Local Area Network Security Conference (LANSEC)

Reusing Existing C3I Systems in a Secure Environment - Proceedings of the Application of COTS and Reusable Components Conference

A Framework for Reasoning about Assurance - Published by the National Computer Security Center of the NSA
Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS)

Interconnecting MLS Command Centers - White paper for the Multilevel Security Initiative at Hanscomb AFB

==Education==

* JD cum laude – Georgetown Law - Cyberlaw and Intellectual Property
* MA – George Mason - Human Factors Engineering
* BA – University of Virginia - Cognitive Psychology and Computer Science (Specialization in AI)

User:Jeff Williams

2015-10-04T20:48:45Z

Jeff Williams:

I'm Jeff Williams, I'm the CTO of both [http://contrastsecurity.com Contrast Security]. I helped found OWASP, created the OWASP Foundation 501c3, and served as the volunteer Chair of the OWASP Foundation from 2003 to 2012. I’ve dedicated my life to trying to make the world’s software more secure, and so I create lots of free and open tools, libraries, guidance, and standards to try to change the status quo. Thank you all for your dedication to application security and your participation in OWASP. Please send any questions or comments to me via email at [mailto:jeff.williams@contrastsecurity.com jeff.williams@contrastsecurity.com]. Or you can twitter @planetlevel.

last revised {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

I'm particularly proud of this free tool that uses instrumentation to find vulnerabilities. Far easier to use and more accurate than static (SAST) or dynamic analysis (DAST) scanners.
* FREE tool - Contrast for Eclipse - http://marketplace.eclipse.org/content/contrast-eclipse

Also please read the "Continuous Security Handbook" which reinterprets application security for high-speed DevOps environments.
* FREE CAS Handbook - http://www1.contrastsecurity.com/continuous-app-security

Some of my other work (in roughly reverse chronological order)
* Enterprise Java Rootkits - https://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf
* XSS-Proofing Your JavaEE, JSP, and JSP Applications - http://www.oracle.com/technetwork/server-storage/ts-4374-159351.pdf
I'm an official [https://www.oracle.com/javaone/rock-stars/index.html#jwilliams Java Rock Star]!
* XSS Prevention Cheatsheet – http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
* Java EE ClickJack Filter - http://www.owasp.org/index.php/ClickjackFilter_for_Java_EE
* Enterprise Security API – http://www.owasp.org/index.php/ESAPI
* Application Security Verification Standard - http://www.owasp.org/index.php/ASVS
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java PDF Attack Filter - http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE
* Application Security Risk Rating Model - http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
* CSRF Tester Tool - http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java Stinger Validation Library - http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
* Application Security Contract Annex - http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
* OWASP Chapters Program - http://www.owasp.org/index.php/Category:OWASP_Chapter
* OWASP Foundation - http://www.owasp.org/index.php/OWASP_Foundation
* OWASP Top Ten – http://www.owasp.org/index.php/Topten
* WebGoat Application Security Learning Environment - http://www.owasp.org/index.php/Webgoat
* Systems Security Engineering CMM - http://sse-cmm.org/index.html

To see my wiki contributions, [[:Special:Contributions/Jeff Williams|click here]].

==Background==

My background, from an [http://myappsecurity.blogspot.com/2007/03/reflection-on-jeff-williams.html interview]

I set out to be a user interface guy, but I got into security accidentally. I was working at TRW in 1992 on the user interface for a big Navy system that just happened to be highly secure – targeting B2 in the Orange Book. I took on an R&D project to port the user interface to the new compartmented mode workstation (what became Trusted Solaris) and I found that I really liked the challenge of securing such a complex system.

Then Java 1.0 came along and I got NIST and NRL funding to do security research. At the time, we thought the Java sandbox was a good idea, but that there were attacks that might bypass it. So I wrote a special classloader that modified the bytecode to wrap security relevant method calls with a reference monitor. After that I spent several years developing a Java-based multilevel secure network guard on Trusted Solaris. That guard handled HTTP, FTP, TDS, and a number of other protocols – sort of a very early application firewall. But unlike the modern WAFs, we took a whitelist approach where you would define exactly the data formats and rules for allowing messages.

In the mid-90’s, I chaired the group that authored the SSE-CMM, which is now ISO 21827. As it turns out, the processes involved in systems security engineering are quite similar to those necessary for secure software development. I’m very glad to see that the idea of assurance arguments from my work is starting to be used in the application security world.

Then in 1998, while I was the technical director of the Global Security Practice at Exodus Communications, a Fortune 10 company approached us and said “We’d like to host our applications with you, but we have this rule – every line of code has to be reviewed before it goes on the Internet.” So I started an application security practice and started providing application assessments, developer training, and help with security requirements and architecture. We built a successful practice securing some of the biggest and most complex web applications in the world.

In April 2002, together with Dave Wichers, Noelle Hardy, and some other great folks, I started [http://aspectsecurity.com Aspect Security] to focus exclusively on application security. I just feel so fortunate to work with such an amazing group of consultants and customers. I’m having the most fun of my professional career.

I first heard of OWASP in 2001 from Chuck Pfleeger (the author of Security in Computing). The idea of a free and open community for application security was an interesting idea. At the time, getting companies to focus on application security was difficult. In meetings with several government agencies, they acknowledged that it was an issue, but that they were managing to the SANS Top 20. I came home and literally in the shower said to myself, “I wish we had an application security top ten…” So a small team of us at Aspect took the lead in drafting the first OWASP Top Ten.

Later, Aspect donated WebGoat, a hands-on training environment for application security issues that we had developed for our courses. A huge number of organizations, including Google, use WebGoat today to teach their developers about application security. We started to see that participation in OWASP allowed Aspect to demonstrate our skills in a very constructive way, and many of our customers have contacted us after seeing our participation in OWASP.

I was honored to take over the leadership of OWASP in 2003. At that time, we had a number of great contributors, but OWASP itself was just a domain name and a few small projects. So I got us set up as a 501c3 nonprofit organization and put a management structure in place. I want the OWASP Foundation to provide a free, open, supportive community infrastructure for application security projects. We’re making the barriers to entry for contribution so low that security experts will be motivated to make the effort and share their expertise.

One of the key challenges has been to ensure that OWASP is not influenced by commercial interests. When I set up the AppSec conference and local chapter rules, I made sure that vendors are cannot use OWASP to market their products. We’re also starting to ferret out abuse of the OWASP brand by companies that claim their products “address the OWASP Top Ten” or enable “OWASP Compliance.” The local chapters have been growing very quickly and starting to contribute back to the mothership. Our conferences have also been a great experience.

I think the switch to the MediaWiki platform in 2006 was a major step for OWASP. Prior to that, contributing content was a difficult and painful process. Now, anyone can create an account and contribute easily. We have a team set up to review all the contributions and the number of abuses in our first year has been astoundingly low (less than 10 incidents). We’re to the point now where we get dozens of articles and contributions every day. I don’t see how a non-open approach to building an application security body of knowledge can possibly keep up with our productivity.

We’re still a long way from the point where a company can go to OWASP for everything they need in order to build, acquire, and operate secure applications… but we’ve got an incredible process and we’re working very hard to get there.

I have big family and absolutely love my kids. We live in the woods and spend a lot of time outside with our two Labrador retrievers. I’m very much into sports – I rowed on the crew team at UVA and still play basketball three times a week (if you meet me you'll know why). For a while I was into extreme rollerblading and then I got into mountain bike trials – I broke a lot of equipment, but never had any serious injuries :)"

==Articles / Presentations==

Opening the Black Box: A Source Code Security Analysis Case Study
http://www.aspectsecurity.com/documents/Aspect_Opening_Black_Box.doc

Application Security Initiatives - The Best Defense Is a Good Offense
http://www.aspectsecurity.com/documents/Application_Security_Initiatives.htm

Let's Sue the Idiots -- Security, Software, Contracts, and Lawyers
http://www.aspectsecurity.com/article/sscl.htm

How to Build an HTTP Request Validation Engine for Your J2EE Application
http://www.aspectsecurity.com/article/bld_HTTP_req_val_engine.htm

Access Control (aka Authorization) in Your J2EE Application
http://www.aspectsecurity.com/article/access_control.htm

Trustworthy Java - Are your apps bulletproof?
http://www.aspectsecurity.com/article/trust_java.htm

The Ten Most Critical Web Application Security Vulnerabilities
http://www.aspectsecurity.com/owasp.htm

Security Code Review - the Best Way to Eliminate Vulnerabilities in Software" -
http://www.aspectsecurity.com/documents/AspectCodeReviewWhitePaper.pdf

Can a 'Social Protocol' Help Protect Privacy?
http://www.aspectsecurity.com/documents/p3p.pdf

Jini and Mobile Agent Security - Proceedings of the Workshop on Agent Technologies (AT ‘98)
http://www.aspectsecurity.com/documents/jini.pdf

A Practical Approach to Improving and Communicating Assurance - Proceedings of the 10th Canadian Information Technology Security Symposium (CITSS)
http://www.aspectsecurity.com/documents/Arguing.pdf

A Practical Approach to Measuring Assurance - Proceedings of the 1998 Security Applications Conference (ACSAC)
http://www.aspectsecurity.com/documents/Measuring.pdf

System Security Engineering Capability Maturity Model (SSE-CMM) version 2.0 - Released at the 21st Annual National Information System Security Conference (NISSC)
http://www.aspectsecurity.com/documents/SSECMMv2Final.pdf

Just Sick about Security - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Sick.pdf

An Enterprise Assurance Framework - Proceedings of the 5th Workshop on Enabling Technologies
http://www.aspectsecurity.com/documents/WetIce.pdf

Pretty Good Assurance - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Pretty.pdf

Need for a Framework for Reasoning about Assurance - Proceedings of the International Workshop on IT Assurance and Trustworthiness (WITAT)
http://www.aspectsecurity.com/documents/Need.pdf

Assurance is an N-Space (Where N is Hopefully Small) - Proceedings of the International Invitational Workshop on Developmental Assurance
http://www.aspectsecurity.com/documents/Nspace.pdf

A Capability Maturity Model For Security Engineering - Proceedings of the 6th Annual Canadian Computer Security Symposium
http://www.aspectsecurity.com/documents/CITSS94.doc

Unsafe at Any (CPU) Speed: Why We Keep Making the Same Mistakes - NSA High Confidence Software and Systems Conference

Web Applications: The “Last Mile” of Internet Security

A Constructionist Approach to Law and Society - Law and Society Seminar, Georgetown University Law Center

Interpreting Anticircumvention (DMCA) - Advanced International Copyright Law, Georgetown University Law Center

P3I – Protection Profile Process Improvement - Proceedings of the 22nd National Information System Security Conference (NISSC)

Windows NT Security - 17th Annual National Computer Security Conference (NCSC)

Windows NT Client Security and Windows NTAS Security - The Local Area Network Security Conference (LANSEC)

Reusing Existing C3I Systems in a Secure Environment - Proceedings of the Application of COTS and Reusable Components Conference

A Framework for Reasoning about Assurance - Published by the National Computer Security Center of the NSA
Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS)

Interconnecting MLS Command Centers - White paper for the Multilevel Security Initiative at Hanscomb AFB

==Education==

* JD cum laude – Georgetown Law - Cyberlaw and Intellectual Property
* MA – George Mason - Human Factors Engineering
* BA – University of Virginia - Cognitive Psychology and Computer Science (Specialization in AI)

User:Jeff Williams

2015-01-19T18:35:41Z

Jeff Williams:

I'm Jeff Williams, I'm the CTO of both [http://contrastsecurity.com Contrast Security] and [http://aspectsecurity.com Aspect Security]. I helped found OWASP, created the OWASP Foundation 501c3, and served as the volunteer Chair of the OWASP Foundation from 2003 to 2012. I’ve dedicated my life to trying to make the world’s software more secure, and so I create lots of free and open tools, libraries, guidance, and standards to try to change the status quo. Thank you all for your dedication to application security and your participation in OWASP. Please send any questions or comments to me via email at [mailto:jeff.williams@contrastsecurity.com jeff.williams@contrastsecurity.com]. Or you can twitter @planetlevel.

last revised {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

I'm particularly proud of this free tool that uses instrumentation to find vulnerabilities. Far easier to use and more accurate than static (SAST) or dynamic analysis (DAST) scanners.
* FREE tool - Contrast for Eclipse - http://marketplace.eclipse.org/content/contrast-eclipse

Also please read the "Continuous Security Handbook" which reinterprets application security for high-speed DevOps environments.
* FREE CAS Handbook - http://www1.contrastsecurity.com/continuous-app-security

Some of my other work (in roughly reverse chronological order)
* Enterprise Java Rootkits - https://www.blackhat.com/presentations/bh-usa-09/WILLIAMS/BHUSA09-Williams-EnterpriseJavaRootkits-PAPER.pdf
* XSS-Proofing Your JavaEE, JSP, and JSP Applications - http://www.oracle.com/technetwork/server-storage/ts-4374-159351.pdf
I'm an official [https://www.oracle.com/javaone/rock-stars/index.html#jwilliams Java Rock Star]!
* XSS Prevention Cheatsheet – http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
* Java EE ClickJack Filter - http://www.owasp.org/index.php/ClickjackFilter_for_Java_EE
* Enterprise Security API – http://www.owasp.org/index.php/ESAPI
* Application Security Verification Standard - http://www.owasp.org/index.php/ASVS
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java PDF Attack Filter - http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE
* Application Security Risk Rating Model - http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
* CSRF Tester Tool - http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java Stinger Validation Library - http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
* Application Security Contract Annex - http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
* OWASP Chapters Program - http://www.owasp.org/index.php/Category:OWASP_Chapter
* OWASP Foundation - http://www.owasp.org/index.php/OWASP_Foundation
* OWASP Top Ten – http://www.owasp.org/index.php/Topten
* WebGoat Application Security Learning Environment - http://www.owasp.org/index.php/Webgoat
* Systems Security Engineering CMM - http://sse-cmm.org/index.html

To see my wiki contributions, [[:Special:Contributions/Jeff Williams|click here]].

==Background==

My background, from an [http://myappsecurity.blogspot.com/2007/03/reflection-on-jeff-williams.html interview]

I set out to be a user interface guy, but I got into security accidentally. I was working at TRW in 1992 on the user interface for a big Navy system that just happened to be highly secure – targeting B2 in the Orange Book. I took on an R&D project to port the user interface to the new compartmented mode workstation (what became Trusted Solaris) and I found that I really liked the challenge of securing such a complex system.

Then Java 1.0 came along and I got NIST and NRL funding to do security research. At the time, we thought the Java sandbox was a good idea, but that there were attacks that might bypass it. So I wrote a special classloader that modified the bytecode to wrap security relevant method calls with a reference monitor. After that I spent several years developing a Java-based multilevel secure network guard on Trusted Solaris. That guard handled HTTP, FTP, TDS, and a number of other protocols – sort of a very early application firewall. But unlike the modern WAFs, we took a whitelist approach where you would define exactly the data formats and rules for allowing messages.

In the mid-90’s, I chaired the group that authored the SSE-CMM, which is now ISO 21827. As it turns out, the processes involved in systems security engineering are quite similar to those necessary for secure software development. I’m very glad to see that the idea of assurance arguments from my work is starting to be used in the application security world.

Then in 1998, while I was the technical director of the Global Security Practice at Exodus Communications, a Fortune 10 company approached us and said “We’d like to host our applications with you, but we have this rule – every line of code has to be reviewed before it goes on the Internet.” So I started an application security practice and started providing application assessments, developer training, and help with security requirements and architecture. We built a successful practice securing some of the biggest and most complex web applications in the world.

In April 2002, together with Dave Wichers, Noelle Hardy, and some other great folks, I started Aspect Security to focus exclusively on application security. I just feel so fortunate to get to work with such an amazing group of consultants and customers. I’m having the most fun of my professional career.

I first heard of OWASP in 2001 from Chuck Pfleeger (the author of Security in Computing). The idea of a free and open community for application security was an interesting idea. At the time, getting companies to focus on application security was difficult. In meetings with several government agencies, they acknowledged that it was an issue, but that they were managing to the SANS Top 20. I came home and literally in the shower said to myself, “I wish we had an application security top ten…” So a small team of us at Aspect took the lead in drafting the first OWASP Top Ten.

Later, Aspect donated WebGoat, a hands-on training environment for application security issues that we had developed for our courses. A huge number of organizations, including Google, use WebGoat today to teach their developers about application security. We started to see that participation in OWASP allowed Aspect to demonstrate our skills in a very constructive way, and many of our customers have contacted us after seeing our participation in OWASP.

I was honored to take over the leadership of OWASP in 2003. At that time, we had a number of great contributors, but OWASP itself was just a domain name and a few small projects. So I got us set up as a 501c3 nonprofit organization and put a management structure in place. I want the OWASP Foundation to provide a free, open, supportive community infrastructure for application security projects. We’re making the barriers to entry for contribution so low that security experts will be motivated to make the effort and share their expertise.

One of the key challenges has been to ensure that OWASP is not influenced by commercial interests. When I set up the AppSec conference and local chapter rules, I made sure that vendors are cannot use OWASP to market their products. We’re also starting to ferret out abuse of the OWASP brand by companies that claim their products “address the OWASP Top Ten” or enable “OWASP Compliance.” The local chapters have been growing very quickly and starting to contribute back to the mothership. Our conferences have also been a great experience.

I think the switch to the MediaWiki platform in 2006 was a major step for OWASP. Prior to that, contributing content was a difficult and painful process. Now, anyone can create an account and contribute easily. We have a team set up to review all the contributions and the number of abuses in our first year has been astoundingly low (less than 10 incidents). We’re to the point now where we get dozens of articles and contributions every day. I don’t see how a non-open approach to building an application security body of knowledge can possibly keep up with our productivity.

We’re still a long way from the point where a company can go to OWASP for everything they need in order to build, acquire, and operate secure applications… but we’ve got an incredible process and we’re working very hard to get there.

I have big family and absolutely love my kids. We live in the woods and spend a lot of time outside with our two Labrador retrievers. I’m very much into sports – I rowed on the crew team at UVA and still play basketball three times a week (if you meet me you'll know why). For a while I was into extreme rollerblading and then I got into mountain bike trials – I broke a lot of equipment, but never had any serious injuries :)"

==Articles / Presentations==

Opening the Black Box: A Source Code Security Analysis Case Study
http://www.aspectsecurity.com/documents/Aspect_Opening_Black_Box.doc

Application Security Initiatives - The Best Defense Is a Good Offense
http://www.aspectsecurity.com/documents/Application_Security_Initiatives.htm

Let's Sue the Idiots -- Security, Software, Contracts, and Lawyers
http://www.aspectsecurity.com/article/sscl.htm

How to Build an HTTP Request Validation Engine for Your J2EE Application
http://www.aspectsecurity.com/article/bld_HTTP_req_val_engine.htm

Access Control (aka Authorization) in Your J2EE Application
http://www.aspectsecurity.com/article/access_control.htm

Trustworthy Java - Are your apps bulletproof?
http://www.aspectsecurity.com/article/trust_java.htm

The Ten Most Critical Web Application Security Vulnerabilities
http://www.aspectsecurity.com/owasp.htm

Security Code Review - the Best Way to Eliminate Vulnerabilities in Software" -
http://www.aspectsecurity.com/documents/AspectCodeReviewWhitePaper.pdf

Can a 'Social Protocol' Help Protect Privacy?
http://www.aspectsecurity.com/documents/p3p.pdf

Jini and Mobile Agent Security - Proceedings of the Workshop on Agent Technologies (AT ‘98)
http://www.aspectsecurity.com/documents/jini.pdf

A Practical Approach to Improving and Communicating Assurance - Proceedings of the 10th Canadian Information Technology Security Symposium (CITSS)
http://www.aspectsecurity.com/documents/Arguing.pdf

A Practical Approach to Measuring Assurance - Proceedings of the 1998 Security Applications Conference (ACSAC)
http://www.aspectsecurity.com/documents/Measuring.pdf

System Security Engineering Capability Maturity Model (SSE-CMM) version 2.0 - Released at the 21st Annual National Information System Security Conference (NISSC)
http://www.aspectsecurity.com/documents/SSECMMv2Final.pdf

Just Sick about Security - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Sick.pdf

An Enterprise Assurance Framework - Proceedings of the 5th Workshop on Enabling Technologies
http://www.aspectsecurity.com/documents/WetIce.pdf

Pretty Good Assurance - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Pretty.pdf

Need for a Framework for Reasoning about Assurance - Proceedings of the International Workshop on IT Assurance and Trustworthiness (WITAT)
http://www.aspectsecurity.com/documents/Need.pdf

Assurance is an N-Space (Where N is Hopefully Small) - Proceedings of the International Invitational Workshop on Developmental Assurance
http://www.aspectsecurity.com/documents/Nspace.pdf

A Capability Maturity Model For Security Engineering - Proceedings of the 6th Annual Canadian Computer Security Symposium
http://www.aspectsecurity.com/documents/CITSS94.doc

Unsafe at Any (CPU) Speed: Why We Keep Making the Same Mistakes - NSA High Confidence Software and Systems Conference

Web Applications: The “Last Mile” of Internet Security

A Constructionist Approach to Law and Society - Law and Society Seminar, Georgetown University Law Center

Interpreting Anticircumvention (DMCA) - Advanced International Copyright Law, Georgetown University Law Center

P3I – Protection Profile Process Improvement - Proceedings of the 22nd National Information System Security Conference (NISSC)

Windows NT Security - 17th Annual National Computer Security Conference (NCSC)

Windows NT Client Security and Windows NTAS Security - The Local Area Network Security Conference (LANSEC)

Reusing Existing C3I Systems in a Secure Environment - Proceedings of the Application of COTS and Reusable Components Conference

A Framework for Reasoning about Assurance - Published by the National Computer Security Center of the NSA
Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS)

Interconnecting MLS Command Centers - White paper for the Multilevel Security Initiative at Hanscomb AFB

==Education==

* JD cum laude – Georgetown Law - Cyberlaw and Intellectual Property
* MA – George Mason - Human Factors Engineering
* BA – University of Virginia - Cognitive Psychology and Computer Science (Specialization in AI)

How to write insecure code

2014-11-12T20:46:03Z

Jeff Williams:

__NOTOC__

=HOW TO WRITE INSECURE CODE=

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.org/root/phun/unmaintain.html one page version more readable]. Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Code wants to be free!'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherently secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

==Policy==

; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your automated tools dictate your security requirements. Tailoring is for suckers.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

; '''Don't worry about using the latest version of components'''
: Just because a library has known vulnerabilities doesn't mean it's not safe to use. If there's no proof that *my* application is vulnerable then you're just wasting my time.

==Culture==

; "I got a security approval"
: So what if it was several years ago, it's basically the same code anyway.

; "Security has to *prove* it before I do anything"
: So what if you exploited my application, you cheated by using hacking

; "Hello, this is an internal application, so security doesn't matter"
: We have firewalls and stuff

[[Category:How To]]

How to write insecure code

2014-11-12T20:40:25Z

Jeff Williams:

==Add to this Article==

Help us out and add your favorite ways to discourage secure coding below.

==Introduction==

In the interest of ensuring that there will be a future for hackers, criminals, and others who want to destroy the digital future, this paper captures tips from the masters on how to create insecure code. With a little creative use of these tips, you can also ensure your own financial future. Be careful, you don't want to make your code look hopelessly insecure, or your insecurity may be uncovered and fixed.

The idea for this article comes from Roedy Green's [http://mindprod.com/jgloss/unmain.html How to write unmaintainable code]. You may find the [http://thc.org/root/phun/unmaintain.html one page version more readable]. Actually, making your code unmaintainable is a great first step towards making it insecure and there are some great ideas in this article, particularly the section on camouflage. Also many thanks to Steven Christey from MITRE who contributed a bunch of particularly insecure items.

''Special note for the slow to pick up on irony set. This essay is a '''joke'''! Developers and architects are often bored with lectures about how to write '''secure''' code. Perhaps this is another way to get the point across.''



==General Principles==

; '''Avoid the tools'''
: To ensure an application is forever insecure, you have to think about how security vulnerabilities are identified and remediated. Many software teams believe that automated tools can solve their security problems. So if you want to ensure vulnerabilities, simply make them difficult for automated tools to find. This is a lot easier than it sounds. All you have to do is make sure your vulnerabilities don't match anything in the tool's database of signatures. Your code can be as complex as you want, so it's pretty easy to avoid getting found. In fact, most inadvertent vulnerabilities can't be found by tools anyway.

; '''Always use default deny'''
: Apply the principle of "Default Deny" when building your application. Deny that your code can ever be broken, deny vulnerabilities until there's a proven exploit, deny to your customers that there was ever anything wrong, and above all - deny responsibility for flaws. Blame the dirty cache buffers.

; '''Be a shark'''
: Always be on the move. Leave security problems to operations staff.

==Complexity==

; '''Distribute security mechanisms'''
: Security checks should be designed so that they are as distributed as possible throughout the codebase. Try not to follow a consistent pattern and don't make it easy to find all the places where the mechanism is used. This will virtually ensure that security is implemented inconsistently.

; '''Spread the wealth'''
: Another great way to avoid being found is to make sure your security holes aren't located in one place in your code. It's very difficult for analysts to keep all of your code in their head, so by spreading out the holes you prevent anyone from finding or understanding them.

; '''Use dynamic code'''
: The single best way to make it difficult for a security analyst (or security tool for that matter) to follow through an application and uncover a flaw is to use dynamic code. It can be almost impossible to trace the flow through code that is loaded at runtime. Features like reflection and classloading are beautiful features for hiding vulnerabilities. Enable as many "plugin" points as possible.

==Secure Languages==

; '''Type safety'''
: Means anything you enter at the keyboard is secure.

; '''Secure languages'''
: Pick only programming languages that are completely safe and don't require any security knowledge or special programming to secure.

; '''Mix languages'''
: Different languages have different security rules, so the more languages you include the more difficult it will be to learn them all. It's hard enough for development teams to even understand the security ramifications of one language, much less three or four. You can use the transitions between languages to hide vulnerabilities too.

==Trust Relationships==

; '''Rely on security checks done elsewhere'''
: It's redundant to do security checks twice, so if someone else says that they've done a check, there's no point in doing it again. When possible, it's probably best to just assume that others are doing security right, and not waste time doing it yourself. Web services and other service interfaces are generally pretty secure, so don't bother checking what you send or what they return.

; '''Trust insiders'''
: Malicious input only comes from the Internet, and you can trust that all the data in your databases is perfectly validated, encoded, and sanitized for your purposes.

; '''Share the love'''
: Drop your source code into repositories that are accessible by all within the company. This also prevents having to email those hard-coded shared secrets around.

; '''Ignore decoupling requirements'''
: Security is hard enough. Don't listen when anyone says that point-to-point trust relationships undermine efforts to build decoupled systems. They're only trying to sound smart and well read.

==Logging==

; '''Use your logs for debugging'''
: Nobody will be able to trace attacks on your code if you fill up the logs with debugging nonsense. Extra points for making your log messages undecipherable by anyone except you. Even more points if the log messages look as though they might be security relevant.

; '''Don't use a logging framework'''
: The best approach to logging is just to write to stdout, or maybe to a file. Logging frameworks make the logs too easy to search and manage to be sure that nobody will ever review them.

==Encryption==

; '''Build your own encryption scheme'''
: The standard encryption mechanisms are way too complicated to use. It's much easier to make up an encryption algorithm that scrambles up secret stuff. You don't need to bother with a key or anything, just mix it all up and nobody will figure it out.

; '''Hard-code your keys'''
: Hard-coding is the best way to retain control. This way those pesky operations folks won't be able to monkey with (they say "rotate") the keys, and they'll be locked into the source code where only smart people can understand them. This will also make it easier to move from environment to environment as the hard-coded key will be the same everywhere. This in turn means your code is secure everywhere.

; '''Smart coders don't read manuals'''
: Just keep adding bytes until the algorithm stops throwing exceptions. Or just save yourself time and cut-and-paste from a popular coding site. This looks like a good start: byte[] keyBytes = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17 };

; '''Pack up your sensitive payload'''
: If you need to pass things that are sensitive, like passwords or PII, just pack it up in an encrypted blob. Then just email the key to the developer who is coding the other side of the transaction, and punch out early. This will also get you past Data Loss Prevention (DLP) tools which is a huge bonus.

; '''Encryption is hard'''
: A great way to improve the security posture of your site is to use client-side JavaScript to encrypt passwords and other sensitive data that are submitted. This can be used with or without HTTPS (TLS/SSL). If you use it without HTTPS, you can save some money by skipping the annual purchase of a signed third party certificate.

; '''HTTPS makes your application bullet proof'''
: If you use HTTPS encryption between your web application endpoint and the client, there is absolutely no way for anyone to steal any of the data that is transmitted.

==Authentication==

; '''Build your own authentication scheme'''
: Authentication is simple, so just use your common sense and implement. Don't worry about esoteric stuff you hear about like session prediction, hashing credentials, brute force attacks, and so on. Only NSA eggheads could possibly ever figure that stuff out. And if users want to choose weak passwords, that's their own fault.

; '''Sessions are inherantly secure'''
: Sessions timeout after 20 minutes, so don't worry about them. You can put the SESSIONID in the URL, log files, or wherever else you feel like. What could an attacker do with a SESSIONID anyway? It's just a bunch of random letters and numbers.

; '''Single Sign-On is easy'''
: If you need to submit a username and password (or other secret knocks) from one site to another, pack it up in an encrypted blob as above. This way if anyone finds the blob, they'll have a heck of a time decrypting it, which is what they'll need to do to be able to encrypt it again and create the blob themselves.
: A one-way hash cannot be decrypted. Therefore, this is a way to take the latter approach and make it unbreakable.

==Authorization==

; '''Forget about it'''
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think there's a difference between authentication and authorization.

; '''Just let your authorization scheme evolve'''
: It's really hard to figure out all the access control rules for your application, so use a '''just in time''' development methodology. This way you can just code up new rules when you figure them out. If you end up with hundreds or thousands of lines of authorization code scattered throughout your application, you're on the right track.

; '''Privilege makes code just work'''
: Using the highest privilege levels makes your product easier to install and run.

; '''Optimize the developer... always'''
: Each developer, independent of one another, must decide where authorization decision and enforcement is made.

; '''Trust the client'''
: RIA clients and fat clients that use remote services can make decisions about what the end-user can or can't see.

; '''Volunteer to authorize access to other systems'''
: When a service you are calling, for example, has inappropriate access controls just be nice and live with it. After all it will be your fault when a direct object reference permits any user of your system to see any data on their service. Should that happen, it will be a chance for you to show your dedication when you're up at 3 AM on a Saturday morning sorting out a breach.

==Policy==
; '''Forget about it'''
: Policy can't be known until the user requests arrive. Put authorization logic where you see fit. Sometimes you need to roll it into the UI. Sometimes it's in the data layer. Sometimes it's both.
: See [[How_to_write_insecure_code#Authentication|Authentication]]. Only ivory tower knuckleheads think that security requirements can be known at design time and expressed in a runtime-readable/declarative format.

; '''The tool knows how to do it'''
: Let your authentication technology dictate your authorization requirements.

==Input Validation==

; '''Validation is for suckers'''
: Your application is already protected by a firewall, so you don't have to worry about attacks in user input. The security ''experts'' who keep nagging you are just looking to keep themselves in a job and know nothing about programming.

; '''Let developers validate their way'''
: Don't bother with a standard way of doing validation, you're just cramping developer style. To create truly insecure code, you should try to validate as many different ways as possible, and in as many different places as possible.

; '''Trust the client'''
: If the client doesn't, by design, produce wacky encoding, for example, then wacky encoding isn't a threat.

==Documentation==

; '''If you can build it and it appears to work then why describe it?'''
: The most successful applications do not waste time with requirements, security or otherwise. Optimize the development by keeping the developers from having to read.

; '''Security is just another option'''
: Assume that your sysadmins will RTFM and change the default settings you specified in a footnote on page 124.

; '''Don't document how security works'''
: There is no point in writing down all the details of a security design. If someone wants to figure out if it works, they should check the code. After all, the code may change and then the documentation would be useless.

; '''Freedom to innovate'''
: Standards are really just guidelines for you to add your own custom extensions.

; '''Print is dead'''
: You already know everything about security, what else is there to learn? Books are for lamers, mailing lists and blogs are for media whores and FUD-tossing blowhards.

==Coding==

; '''Most APIs are safe'''
: Don't waste time poring through documentation for API functions. It's generally pretty safe to assume that APIs do proper validation, exception handling, logging, and thread safety.

; '''Don't use security patterns'''
: Make sure there's no standard way of implementing validation, logging, error handling, etc... on your project. It's best when developers are left free to express themselves and channel their inner muse in their code. Avoid establishing any security coding guidelines, that'll just inhibit creativity.

; '''Make sure the build process has lots of steps'''
: You want to maximize the number of steps in the build process that have to occur in the right order to make a successful build. It's best if only one person knows how to actually set up all the config files and build the distribution. If you do have steps written down, you should have lots of notes distributed across a bunch of files and howto's in lots of locations.

==Testing==

; '''Test with a browser'''
: All you need to test a web application is a browser. That way, you ensure that your code will work perfectly for all of your legitimate users. And what do you care if it doesn't work for hackers, attackers, and criminals? Using a fancy security testing tool like [[WebScarab]] is a waste of your valuable time.

; '''Don't use static analysis tools'''
: These tools aren't perfect, so just forget about them. Static analysis tools are likely to create annoying warning messages that will slow down your development time. Also they're a pain to learn, setup, and use.

; '''Build test code into every module'''
: You should build test code throughout the application. That way you'll have it there in production in case anything goes wrong and you need to run it.

; '''Security warnings are all false alarms'''
: Everyone knows that security warnings are all false alarms, so you can safely just ignore them. Why should you waste your valuable time chasing down possible problems when it's not your money on the line. If a tool doesn't produce perfect results, then just forget it.

==Libraries==

; '''Use lots of precompiled libraries'''
: Libraries are great because you don't have to worry about whether the code has any security issues. You can trust your business to just about any old library that you download off the Internet and include in your application. Don't worry about checking the source code, it's probably not available and it's too much trouble to recompile. And it would take way too long to check all that source code anyway.

; '''Don't worry about using the latest version of components'''
: Just because a library has known vulnerabilities doesn't mean it's not safe to use. If there's no proof that *my* application is vulnerable then you're just wasting my time.

==Culture==

; "I got a security approval"
: So what if it was several years ago, it's basically the same code anyway.

; "Security has to *prove* it before I do anything"
: So what if you exploited my application, you cheated by using hacking

; "Hello, this is an internal application, so security doesn't matter"
: We have firewalls and stuff

[[Category:How To]]

2014 BASC Presentations

2014-10-17T17:25:21Z

Jeff Williams:

{{2014_BASC:Header_Template | Presentations}}

__FORCETOC__
We would like to thank our speakers for donating their time and effort to help make this conference successful.

{{2014_BASC:Presentaton_Info_Template|AppSec: How It Fits into Digital Security|Jared DeMott| | | }}
Securing code is important. But history has shown us that
we can never be certain that our code is 100% perfect. This
becomes particularly true in rapidly evolving environments.
As an industry we need to take a broader look. What security
features are provided by the hardware, OS, language, compiler,
and even application type? Join us bright and early as Dr.
DeMott kicks off the 2014 Boston Application Security Conference
with a Keynote you won’t forget.

{{2014_BASC:Presentaton_Info_Template|Code Assisted PenTest for Mobile Applications|Dinesh Shetty| | | }}

The presentation focuses on problems of following bad Mobile development practice. During this
session, you will learn how to perform a Code Assisted PenTest on Mobile applications and uncover
some well-known and some other not so well known security issues. It is far easy to gain a practical
knowledge of security vulnerabilities than it is to read about them. Watch as Dinesh walks you through
custom created demo applications and source code review tools, to catch security flaws noted in the
various hand-held devices. Expect to see a lot of demos, tools, hacking and a lot of fun.

{{2014_BASC:Presentaton_Info_Template|Finding and Exploiting Access Control Vulnerabilities in Graphical User Interfaces|Collin Mulliner| | | }}

Graphical user interfaces (GUIs) contain a number of common visual
elements or widgets such as labels, text fields, buttons, and lists.
GUIs typically provide the ability to set attributes on these widgets to
control their visibility, enabled status, and whether they are writable.
While these attributes are extremely useful to provide visual cues to
users to guide them through an application's GUI, they can also be
misused for purposes they were not intended. In particular, in the
context of GUI-based applications that include multiple privilege levels
within the application, GUI element attributes are often misused as a
mechanism for enforcing access control policies.

In this session, we introduce GEMs, or instances of GUI element misuse,
as a novel class of access control vulnerabilities in GUI-based
applications. We present a classification of different GEMs that can
arise through misuse of widget attributes, and describe a general
algorithm for identifying and confirming the presence of GEMs in
vulnerable applications. We then present GEM Miner, an implementation of
our GEM analysis for the Windows platform. We evaluate GEM Miner using
real-world GUI-based applications that target the small business and
enterprise markets, and demonstrate the efficacy of our analysis by
finding numerous previously unknown access control vulnerabilities in
these applications.

{{2014_BASC:Presentaton_Info_Template|How a Hacker Views Your Web Site|Patrick Laverty| | | }}

As defenders, we have to be right 100% of the time where an attacker only needs to be right once. The attack surface of a modern web site is incredibly large and we need to be aware of all of it. Additionally, individual attacks may not always be effective but sometimes using them together can gain the desired effect. In this talk, we’ll take a look at the whole attack surface for a typical web site and the various ways that an attacker will use to compromise a site.

{{2014_BASC:Presentaton_Info_Template|The Intersection of Application Architecture and Security Architecture|Walt Williams| | | }}

This presentation will look at the relationship between security architecture and application architecture, specifically on the impact on application security from recent proposed changes to the Clark-Wilson integrity model. I'll explore those changes in depth, discuss the implications for application design. I'll also discuss the implications of these changes to distributed application architectures such as service oriented architectures and other distributed models.

This presentation will be based upon my recent book: Security for Service Oriented Architectures, CRC press, and 10 years of experience working with application security architecture in various corporations.

{{2014_BASC:Presentaton_Info_Template|Lean Security for Small or Medium Sized Business|Anson Gomes and Jeremy Spencer| | | }}

For a small or medium sized business (SMB) the fallout from a security or privacy incident can be at best a PR nightmare. At their worst it can cause irrecoverable damage and end your business by impacting sales or ad revenue. Your user base may take a hit. You may need to draft a blog post or email your customers describing the incident and asking them to change passwords. A key culprit is budget constraints – as a SMB you are allocating resources to innovating, creating, and improving your product. Security, while important, isn't always the primary objective.

Our talk will introduce a simple framework for SMBs to focus their security efforts. We will then discuss a common scenario applicable to most SMBs that employs our framework; and leverages it to introduce cheap and effective security mechanisms that provide prevention, limitation, detection, and response capabilities. The key take away will be the thought process and sample techniques that can enable a SMB to take their rag-tag security outfit and turn it into a business enabler.

{{2014_BASC:Presentaton_Info_Template|Mobile First AppSec: Evolving AppSec for Mobile Applications|Sagar Dongre| | | }}

Development teams are embracing Mobile First Development. They are building native iOS and Android
mobile apps, some are using PhoneGap, and others are using Appcelerator. Evolving AppSec from web
applications to include mobile is where Mobile First AppSec comes in. Mobile First AppSec describes
what application security teams must consider for successfully testing mobile applications. The heart of
Mobile First AppSec is driving the security testing based on the mobile application’s architecture.
This talk discusses the popular mobile application architectures and how the architecture drives risk. The
talk then relates the different application architectures and development frameworks to differences in
their threat model and the consequences on security tests and testing techniques.

{{2014_BASC:Presentaton_Info_Template|Open Source Vulnerability Response|EMC Product Security Response Center| | | }}

Like all software vendors, EMC faces challenges when it comes to managing the response to security vulnerabilities reported on open source embedded components. We will share our experiences by taking OpenSSL Heartbleed and the Bash Bug ‘ShellShock’ as examples and walk through the various challenges we encountered while dealing with it and the processes we built to overcome some of those problems.

{{2014_BASC:Presentaton_Info_Template|Securing The Android Apps On Your Wrist and Face|Jack Mannino and Geller Bedoya| | | }}

Android Wear and Google Glass introduce new ways of interacting with our apps and receiving timely, contextual information from the world around us. Smartphones and tablets are becoming the central point for sending and receiving data from wearables and sensors. Building apps for a wearable world introduces new risks as well as shifts the responsibilities for implementing security controls to other layers.

Many of the same issues we’re familiar with from past Android experiences are still relevant, while some issues are less impactful or not (currently) possible within existing wearables. At the same time, extending the app’s trust boundaries introduces new points of exposure for developers to be aware of in order to proactively defend against attacks. We want to highlight these areas, which developers may not be aware of when adding a wearable component to an existing app.

In this presentation, we will explore how Android Wear and Glass work underneath the hood. We will examine their methods of communication, data replication, and persistence options. We will examine how they fit into the Android development ecosystem and the new risks to privacy and security that need to be considered. Our goal isn’t to deter developers from building wearable apps, but to enable them to make strong security decisions throughout development.

{{2014_BASC:Presentaton_Info_Template|Securing Native Big Data Deployments|Steve Markey| | | }}

This session will provide thought leadership and use cases on securing Big Data technologies
through stateless tokenization. We will cover: an overview of what native Big Data consists of,
Big Data architectures, stateless tokenization use, and finally how to implement and secure Big
Data architectures through stateless tokenization deployments.

Specific focal points include:
* What Big Data is and how it is used
* An overview of Big Data architectures in the enterprise
* What stateless tokenization is and how it is used
* Secure Big Data deployments through stateless tokenization

{{2014_BASC:Presentaton_Info_Template|Using the OCTAVE Allegro Framework to Model Application Risks and Countermeasures|George Ehrhorn| | | }}

Effective Risk Assessment is an incredible tool available to the Information Security professional. A defensible risk assessment ensures that you’ll analyze the most risky aspects of your most risky applications. It lets you develop countermeasures that have the biggest impact. In a real world scenario a properly conducted risk assessment can help you work in the most efficient way. This talk is about how MathWorks uses the OCTAVE Allegro Framework to model application risks and develop countermeasures.

{{2014_BASC:Presentaton_Info_Template|Why is CSP Failing? Trends and Challenges in CSP Adoption|Michael Weissbacher| | | }}

Content Security Policy (CSP) has been proposed as a principled and
robust browser security mechanism against content injection attacks such
as XSS. When configured correctly, CSP renders malicious code injection
and data exfiltration exceedingly difficult for attackers. However,
despite the promise of these security benefits and being implemented in
almost all major browsers, CSP adoption is minuscule-our measurements
show that CSP is deployed in enforcement mode on only 1% of the Alexa
Top 100.

In this paper, we present the results of a long-term study to determine
challenges in CSP deployments that can prevent wide adoption. We
performed weekly crawls of the Alexa Top 1M to measure adoption of web
security headers, and find that CSP both significantly lags other
security headers, and that the policies in use are often ineffective at
actually preventing content injection. In addition, we evaluate the
feasibility of deploying CSP from the perspective of a
security-conscious website operator. We used an incremental deployment
approach through CSP's report-only mode on four websites, collecting
over 10M reports. Furthermore, we used semi-automated policy generation
through web application crawling on a set of popular websites. We found
both that automated methods do not suffice and that significant barriers
exist to producing accurate results.

Finally, based on our observations, we suggest several improvements to
CSP that could help to ease its adoption by the web community.

{{2014_BASC:Presentaton_Info_Template|Why Your AppSec Experts Are Killing You|Jeff Williams| | | }}

Software development has been transformed by practices like Continuous Integration and Continuous Delivery, while application security has remained trapped in expert-based waterfall mode. In this talk, Jeff will show you how you can evolve into a “Continuous Application Security” organization that generates assurance automatically across an entire application security portfolio. Jeff will show you how to bootstrap the “sensor-model-dashboard” feedback loop that makes real time, continuous application security possible. He will demonstrate the approach with a new *free* tool called [http://marketplace.eclipse.org/node/1876552 "Contrast for Eclipse"] that brings the power of instrumentation-based application security testing directly into the popular IDE. Check out [https://www.youtube.com/watch?v=4B-HgsT_J_M “Application Security at DevOps Speed and Portfolio Scale”] for some background.

{{2014_BASC:Footer_Template | Presentations}}

XSS (Cross Site Scripting) Prevention Cheat Sheet

2014-02-03T22:04:50Z

Jeff Williams:

= 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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

== 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.

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the context and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this without encoding the data with one of the techniques listed below.'''
</script>

==== JSON entity encoding ====

The rules for JSON encoding can be found in the [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Output_Encoding_Rules_Summary Output Encoding Rules Summary]. Note, this will not allow you to use XSS protection provided by CSP 1.0.

==== HTML entity encoding ====

This technique has the advantage that html entity escaping is widely supported and helps separate data from server side code without crossing any context boundaries. Consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= html_escape(data.to_json) %>
</script>

// external js file
var dataElement = document.getElementById('init_data');
var jsonText = dataElement.textContent || dataElement.innerText // unescapes the content of the span
var initData = JSON.parse(jsonText);

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule #1: Use 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]].

== Bonus Rule #2: Implement Content Security Policy ==

There is another good complex solution to mitigate the impact of an XSS flaw called Content Security Policy. It's a browser side mechanism which
allows you to create source whitelists for client side resources of your web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header instructs the browser to only execute or render resources from those sources. For example this CSP

Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld

will instruct web browser to load all resources only from the page's origin and JavaScript source code files additionaly from static.domain.tld. For more details on Content Security Policy, including what it does, and how to use it, see the OWASP article on [[Content_Security_Policy]]

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Canonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]. URL encoding should only be used to encode parameter values, not the entire URL or path fragments of a URL.
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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:

* OWASP: [[XSS Filter Evasion Cheat Sheet]] - Based on - RSnake's: "XSS Cheat Sheet"

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''Description of XSS Vulnerabilities'''

* OWASP article on [[XSS]] Vulnerabilities

'''Discussion on the Types of XSS Vulnerabilities'''

* [[Types of Cross-Site Scripting]]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Neil Mattatall - neil[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

List of useful HTTP headers

2014-01-28T15:18:14Z

Jeff Williams: /* Real life examples */

This page lists useful security-related HTTP headers. In most architectures these headers can be set in web server configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.

{| border="1"
|-
! Field name
! Description
! Example
|-
|[http://tools.ietf.org/html/rfc6797 Strict-Transport-Security]
|HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings.
|<code>Strict-Transport-Security: max-age=16070400; includeSubDomains</code>
|-
| [http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 X-Frame-Options], [http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 Frame-Options]
| Provides [[Clickjacking]] protection. Values: ''deny'' - no rendering within a frame, ''sameorigin'' - no rendering if origin mismatch, ''allow-from: DOMAIN'' - allow rendering if framed by frame loaded from ''DOMAIN''
| <code> X-Frame-Options: deny</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx X-XSS-Protection]
| This header enables the [[Cross-site scripting]] (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
| <code>X-XSS-Protection: 1; mode=block</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx X-Content-Type-Options]
| The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to [http://code.google.com/chrome/extensions/hosting.html Google Chrome], when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
| <code> X-Content-Type-Options: nosniff </code>
|-
|[http://www.w3.org/TR/CSP/ X-Content-Security-Policy, X-WebKit-CSP]
|[[Content Security Policy]] requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [[Cross-site scripting]] and other cross-site injections.
|<code>X-WebKit-CSP: default-src 'self'</code>
|}

==Check Your Headers==

Visit Check Your Headers to view and evaluate any website's security headers. http://cyh.herokuapp.com/cyh

==Real life examples==
Below examples present selected HTTP headers as set by popular websites to demonstrate that they are indeed being used in production services:

===Facebook===
As of January 2013 [https://www.facebook.com/ Facebook] main page was setting these security related HTTP headers.

'''Strict-Transport-Security:''' max-age=60
'''X-Content-Type-Options:''' nosniff
'''X-Frame-Options:''' DENY
'''X-WebKit-CSP:''' <small>default-src *; script-src https://*.facebook.com
http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net
*.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:*
'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;
style-src * 'unsafe-inline'; connect-src https://*.facebook.com http://*.facebook.com
https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:*
https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net;</small>
'''X-XSS-Protection:''' 1; mode=block

Especially interesting is Facebook's use of [http://www.w3.org/TR/CSP/ Content Security Policy] (using Google Chrome syntax), whose implementation can be [http://www.html5rocks.com/en/tutorials/security/content-security-policy/ challenging] for large sites with heavy usage of JavaScript.

===Google+===
As of January 2013 [https://plus.google.com/ Google+] main page was setting these security related HTTP headers:

'''x-content-type-options:''' nosniff
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

===Twitter===
As of May 2013 [https://twitter.com/ Twitter] main page was setting these security related HTTP headers:

'''strict-transport-security:''' max-age=631138519
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

List of useful HTTP headers

2014-01-28T15:17:29Z

Jeff Williams:

This page lists useful security-related HTTP headers. In most architectures these headers can be set in web server configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.

{| border="1"
|-
! Field name
! Description
! Example
|-
|[http://tools.ietf.org/html/rfc6797 Strict-Transport-Security]
|HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings.
|<code>Strict-Transport-Security: max-age=16070400; includeSubDomains</code>
|-
| [http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 X-Frame-Options], [http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 Frame-Options]
| Provides [[Clickjacking]] protection. Values: ''deny'' - no rendering within a frame, ''sameorigin'' - no rendering if origin mismatch, ''allow-from: DOMAIN'' - allow rendering if framed by frame loaded from ''DOMAIN''
| <code> X-Frame-Options: deny</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx X-XSS-Protection]
| This header enables the [[Cross-site scripting]] (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
| <code>X-XSS-Protection: 1; mode=block</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx X-Content-Type-Options]
| The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to [http://code.google.com/chrome/extensions/hosting.html Google Chrome], when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
| <code> X-Content-Type-Options: nosniff </code>
|-
|[http://www.w3.org/TR/CSP/ X-Content-Security-Policy, X-WebKit-CSP]
|[[Content Security Policy]] requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [[Cross-site scripting]] and other cross-site injections.
|<code>X-WebKit-CSP: default-src 'self'</code>
|}

==Real life examples==
Below examples present selected HTTP headers as set by popular websites to demonstrate that they are indeed being used in production services:

Visit Check Your Headers to view and evaluate any website's security headers. http://cyh.herokuapp.com/cyh

===Facebook===
As of January 2013 [https://www.facebook.com/ Facebook] main page was setting these security related HTTP headers.

'''Strict-Transport-Security:''' max-age=60
'''X-Content-Type-Options:''' nosniff
'''X-Frame-Options:''' DENY
'''X-WebKit-CSP:''' <small>default-src *; script-src https://*.facebook.com
http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net
*.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:*
'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;
style-src * 'unsafe-inline'; connect-src https://*.facebook.com http://*.facebook.com
https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:*
https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net;</small>
'''X-XSS-Protection:''' 1; mode=block

Especially interesting is Facebook's use of [http://www.w3.org/TR/CSP/ Content Security Policy] (using Google Chrome syntax), whose implementation can be [http://www.html5rocks.com/en/tutorials/security/content-security-policy/ challenging] for large sites with heavy usage of JavaScript.

===Google+===
As of January 2013 [https://plus.google.com/ Google+] main page was setting these security related HTTP headers:

'''x-content-type-options:''' nosniff
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

===Twitter===
As of May 2013 [https://twitter.com/ Twitter] main page was setting these security related HTTP headers:

'''strict-transport-security:''' max-age=631138519
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

List of useful HTTP headers

2014-01-28T15:16:51Z

Jeff Williams: /* Real life examples */

This page lists useful security-related HTTP headers. In most architectures these headers can be set in web server configuration ([http://httpd.apache.org/docs/2.0/mod/mod_headers.html Apache], [http://technet.microsoft.com/pl-pl/library/cc753133(v=ws.10).aspx IIS]), without changing actual application's code. This offers significantly faster and cheaper method for at least partial mitigation of existing issues, and an additional layer of defense for new applications.

{| border="1"
|-
! Field name
! Description
! Example
|-
|[http://tools.ietf.org/html/rfc6797 Strict-Transport-Security]
|HTTP Strict-Transport-Security (HSTS) enforces secure (HTTP over SSL/TLS) connections to the server. This reduces impact of bugs in web applications leaking session data through cookies and external links and defends against Man-in-the-middle attacks. HSTS also disables the ability for user's to ignore SSL negotiation warnings.
|<code>Strict-Transport-Security: max-age=16070400; includeSubDomains</code>
|-
| [http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 X-Frame-Options], [http://tools.ietf.org/html/draft-ietf-websec-frame-options-00 Frame-Options]
| Provides [[Clickjacking]] protection. Values: ''deny'' - no rendering within a frame, ''sameorigin'' - no rendering if origin mismatch, ''allow-from: DOMAIN'' - allow rendering if framed by frame loaded from ''DOMAIN''
| <code> X-Frame-Options: deny</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx X-XSS-Protection]
| This header enables the [[Cross-site scripting]] (XSS) filter built into most recent web browsers. It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user. This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
| <code>X-XSS-Protection: 1; mode=block</code>
|-
| [http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx X-Content-Type-Options]
| The only defined value, "nosniff", prevents Internet Explorer and Google Chrome from MIME-sniffing a response away from the declared content-type. This also applies to [http://code.google.com/chrome/extensions/hosting.html Google Chrome], when downloading extensions. This reduces exposure to drive-by download attacks and sites serving user uploaded content that, by clever naming, could be treated by MSIE as executable or dynamic HTML files.
| <code> X-Content-Type-Options: nosniff </code>
|-
|[http://www.w3.org/TR/CSP/ X-Content-Security-Policy, X-WebKit-CSP]
|[[Content Security Policy]] requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including [[Cross-site scripting]] and other cross-site injections.
|<code>X-WebKit-CSP: default-src 'self'</code>
|}

==Real life examples==
Below examples present selected HTTP headers as set by popular websites to demonstrate that they are indeed being used in production services:

Visit Check Your Headers to view and evalaute any website's security headers. http://cyh.herokuapp.com/cyh

===Facebook===
As of January 2013 [https://www.facebook.com/ Facebook] main page was setting these security related HTTP headers.

'''Strict-Transport-Security:''' max-age=60
'''X-Content-Type-Options:''' nosniff
'''X-Frame-Options:''' DENY
'''X-WebKit-CSP:''' <small>default-src *; script-src https://*.facebook.com
http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net
*.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:*
'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;
style-src * 'unsafe-inline'; connect-src https://*.facebook.com http://*.facebook.com
https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:*
https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net;</small>
'''X-XSS-Protection:''' 1; mode=block

Especially interesting is Facebook's use of [http://www.w3.org/TR/CSP/ Content Security Policy] (using Google Chrome syntax), whose implementation can be [http://www.html5rocks.com/en/tutorials/security/content-security-policy/ challenging] for large sites with heavy usage of JavaScript.

===Google+===
As of January 2013 [https://plus.google.com/ Google+] main page was setting these security related HTTP headers:

'''x-content-type-options:''' nosniff
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

===Twitter===
As of May 2013 [https://twitter.com/ Twitter] main page was setting these security related HTTP headers:

'''strict-transport-security:''' max-age=631138519
'''x-frame-options:''' SAMEORIGIN
'''x-xss-protection:''' 1; mode=block

Category:Tools Categories

2013-10-28T19:59:18Z

Jeff Williams:

{{Template:Stub}}
[[Category:OWASP Tools Project]]

== Tool Categories ==

The web application security tools can be divided mainly in two categories. One that protect applications against vulnerabilities and the others that detect vulnerabilities within web applications. Therefore we will be categorizing tools under these headings. The categories of tools currently being addressed by this project are:

=== Web Application Vulnerability Detection Tools ===
*Threat Modeling Tools
*Source Code Analysis (SAST) Tools
*Vulnerability Scanning (DAST) Tools
*Interactive Application Security Testing (IAST) Tools
*Penetration Testing Tools

=== Web Application Protection Tools ===

*Web Application Firewalls (WAFs)

The goal is to provide the following information (at a minimum) in each tool category:

*Description of this tool category
*General strengths and weaknesses of tools in this category
*Important selection criteria for comparing tools within the category (e.g. ease of use, performance, cost, likelihood of false positives)

== References ==
*[[Appendix_A:_Testing_Tools|OWASP Guide Testing Tools Listing]]
*[[:Category:OWASP Tool|Tools from OWASP]]
*[[:Category:Non-OWASP Open Tool|Open Source Tools]]
*Samurai Web Testing Framework Tools: http://www.cgisecurity.com/2008/09/samurai-web-tes.html
*Tools from OWASP Live CD Project: http://mtesauro.com/livecd/index.php?title=Potential_Tool_List
*OWASP Phoenix Tools Project: http://www.owasp.org/index.php/Phoenix/Tools
*Open Source Testing Tools: https://lists.owasp.org/pipermail/owasp-cincinnati/2009-February/000151.html
*NIST SAMATE Project: http://samate.nist.gov/index.php/Main_Page.html
*[[Source Code Analysis Tools]]
*[[Web Application Firewalls]]

Category:Source Code Analysis Tools

2013-10-28T19:57:17Z

Jeff Williams:

{{Template:Stub}}
[[Category:OWASP Tools Project]]

== Description ==

Here we will provide a listing of security source code analysis tools currently available in the market. The plan is to extend this listing to provide information about each tool's strengths and weaknesses to enable you to make an informed decision about the selection of a particular tool to meet your requirements.

<br> '''Disclaimer:''' The tools listing in the table below has been presented in an alphabetical order. OWASP does not endorse any of the Vendors or Source Code Analysis Tools by listing them in the table below. We have made every effort to put this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.

<br>

== Evaluation Criteria ==
TBC

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security (Aspect) || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Most platforms supported }}
|
{{OWASP Tool Info || tool_name = [http://www.fortify.com/security-resources/rats.jsp RATS] || tool_owner = || tool_licence = || tool_platforms = }}
|
|}

== References ==
*[[Source Code Analysis Tools]]
*NIST list of Source Code Security Analyzers: http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html
*Semate Publications on Static Source Code Analyzers: http://samate.nist.gov/index.php/SAMATE_Publications.html
*http://swreflections.blogspot.com/2009/06/value-of-static-analysis-tools.html
*AppSecEU08 Presentation: http://www.owasp.org/index.php/AppSecEU08_Scanstud_-_Evaluating_static_analysis_tools
*NSA comparison of source code analysis tools: http://krvw.com/pipermail/sc-l/2009/002094.html

Category:Vulnerability Scanning Tools

2013-10-28T19:50:44Z

Jeff Williams:

{{Template:Stub}}

== Description ==

Web Application Vulnerability Scanners are the automated tools that scan web applications to look for known security vulnerabilities such as cross-site scripting, SQL injection, command execution, directory traversal and insecure server configuration. A large number of both commercial and open source tools are available and and all these tools have their own strengths and weaknesses.

Here we will provide a listing of vulnerability scanning tools currently available in the market. The plan is to extend this listing to provide information about each tool's strengths and weaknesses to enable you to make an informed decision about the selection of a particular tool to meet your requirements.

<br> '''Disclaimer:''' The tools listing in the table below has been presented in an alphabetical order. OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to put this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.

<br>

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www-01.ibm.com/software/rational/offerings/websecurity/ AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/suite/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}
|
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security (Aspect) || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Most platforms supported }}
|
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}
|
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}
|
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.cenzic.com/ Hailstorm] || tool_owner = Cenzic || tool_licence = Commercial || tool_platforms = Windows }}
|
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}
|
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp NeXpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}
|
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}
|
{{OWASP Tool Info || tool_name = [http://www.ntobjectives.com/ntospider NTOSpider] || tool_owner = NT OBJECTives || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.milescan.com/hk/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.kavado.com/ ScanDo] || tool_owner = KaVaDo Inc || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://www.isecpartners.com/SecurityQAToolbar.html SecurityQA Toolbar] || tool_owner = iSec Partners || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [https://www.secpoint.com/penetrator.html SecPoint Penetrator] || tool_owner = SecPoint || tool_licence = Commercial || tool_platforms = Windows, Unix/Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.subgraph.com/products.html Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.ncircle.com/index.php?s=products_webapp360 WebApp360] || tool_owner = nCircle || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-200^9570_4000_100__ WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.openvas.org OpenVAS] || tool_owner = OpenVAS || tool_licence = Open Source || tool_platforms = Windows / Linux }}
|
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/jsp/solutions/soa_solution.jsp?itemId=86 WebKing] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}
|
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}
|
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.websecurify.com Websecurify] || tool_owner = GNUCITIZEN / Websecurify || tool_licence = Commercial / Free || tool_platforms = Windows, Mac OS, Linux and others}}
|
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|}

== References ==

*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria
*https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/black-box/261-BSI.html#dsy261-BSI_Evaluation-Criteria
*http://www.uml.org.cn/Test/12/Automated%20Testing%20Tool%20Evaluation%20Matrix.pdf
*http://securityinnovation.com/security-report/October/vulnScanners15.htm
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/
*http://www.softwareqatest.com/qatweb1.html
*http://www.proactiverisk.com/tools-page

[[Category:OWASP_Tools_Project]]

Category:Vulnerability Scanning Tools

2013-10-28T19:46:33Z

Jeff Williams:

{{Template:Stub}}

== Description ==

Web Application Vulnerability Scanners are the automated tools that scan web applications to look for known security vulnerabilities such as cross-site scripting, SQL injection, command execution, directory traversal and insecure server configuration. A large number of both commercial and open source tools are available and and all these tools have their own strengths and weaknesses.

Here we will provide a listing of vulnerability scanning tools currently available in the market. The plan is to extend this listing to provide information about each tool's strengths and weaknesses to enable you to make an informed decision about the selection of a particular tool to meet your requirements.

<br> '''Disclaimer:''' The tools listing in the table below has been presented in an alphabatical order. OWASP does not endorse any of the Vendors or Scanning Tools by listing them in the table below. We have made every effort to put this information as accurately as possible. If you are the vendor of a tool below and think that this information is incomplete or incorrect, please send an e-mail to our mailing list and we will make every effort to correct this information.

<br>

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [http://www.acunetix.com/ Acunetix WVS] || tool_owner = Acunetix || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www-01.ibm.com/software/rational/offerings/websecurity/ AppScan] || tool_owner = IBM || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.portswigger.net/suite/ Burp Suite] || tool_owner = PortSwiger || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Most platforms supported }}
|
{{OWASP Tool Info || tool_name = [https://contrastsecurity.com Contrast] || tool_owner = Contrast Security (Aspect) || tool_licence = Commercial / Free (Limited Capability) || tool_platforms = Most platforms supported }}
|
{{OWASP Tool Info || tool_name = [http://www.gamasec.com/Gamascan.aspx GamaScan] || tool_owner = GamaSec || tool_licence = Commercial || tool_platforms = Windows }}
|
{{OWASP Tool Info || tool_name = [http://rgaucher.info/beta/grabber/ Grabber] || tool_owner = Romain Gaucher || tool_licence = Open Source || tool_platforms = Python 2.4, BeautifulSoup and PyXML}}
|
{{OWASP Tool Info || tool_name = [http://sourceforge.net/p/grendel/code/ci/c59780bfd41bdf34cc13b27bc3ce694fd3cb7456/tree/ Grendel-Scan] || tool_owner = David Byrne || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.cenzic.com/ Hailstorm] || tool_owner = Cenzic || tool_licence = Commercial || tool_platforms = Windows }}
|
{{OWASP Tool Info || tool_name = [http://www.ikare-monitoring.com/ IKare] || tool_owner = ITrust || tool_licence = Commercial || tool_platforms = N/A }}
|
{{OWASP Tool Info || tool_name = [http://www.nstalker.com/ N-Stealth] || tool_owner = N-Stalker || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.mavitunasecurity.com/ Netsparker] || tool_owner = MavitunaSecurity || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.rapid7.com/products/nexpose-community-edition.jsp NeXpose] || tool_owner = Rapid7 || tool_licence = Commercial / Free (Limited Capability)|| tool_platforms = Windows/Linux}}
|
{{OWASP Tool Info || tool_name = [http://www.cirt.net/nikto2 Nikto] || tool_owner = CIRT || tool_licence = Open Source|| tool_platforms = Unix/Linux}}
|
{{OWASP Tool Info || tool_name = [http://www.ntobjectives.com/ntospider NTOSpider] || tool_owner = NT OBJECTives || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.milescan.com/hk/ ParosPro] || tool_owner = MileSCAN || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.qualys.com/products/qg_suite/was/ QualysGuard] || tool_owner = Qualys || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.beyondtrust.com/Products/RetinaNetworkSecurityScanner/ Retina] || tool_owner = BeyondTrust || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.kavado.com/ ScanDo] || tool_owner = KaVaDo Inc || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://www.isecpartners.com/SecurityQAToolbar.html SecurityQA Toolbar] || tool_owner = iSec Partners || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.orvant.com Securus] || tool_owner = Orvant, Inc || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [https://www.secpoint.com/penetrator.html SecPoint Penetrator] || tool_owner = SecPoint || tool_licence = Commercial || tool_platforms = Windows, Unix/Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.whitehatsec.com/home/services/services.html Sentinel] || tool_owner = WhiteHat Security || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.subgraph.com/products.html Vega] || tool_owner = Subgraph || tool_licence = Open Source || tool_platforms = Windows, Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://wapiti.sourceforge.net/ Wapiti] || tool_owner = Informática Gesfor || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|
{{OWASP Tool Info || tool_name = [http://www.ncircle.com/index.php?s=products_webapp360 WebApp360] || tool_owner = nCircle || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-201-200^9570_4000_100__ WebInspect] || tool_owner = HP || tool_licence = Commercial || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [http://www.openvas.org OpenVAS] || tool_owner = OpenVAS || tool_licence = Open Source || tool_platforms = Windows / Linux }}
|
{{OWASP Tool Info || tool_name = [http://www.parasoft.com/jsp/solutions/soa_solution.jsp?itemId=86 WebKing] || tool_owner = Parasoft || tool_licence = Commercial || tool_platforms = Windows / Linux / Solaris}}
|
{{OWASP Tool Info || tool_name = [https://www.trustwave.com/external-vulnerability-scanning.php Trustkeeper Scanner] || tool_owner = Trustwave SpiderLabs || tool_licence = Commercial || tool_platforms = SaaS}}
|
{{OWASP Tool Info || tool_name = [http://www.german-websecurity.com/en/products/webscanservice/product-details/overview/ WebScanService] || tool_owner = German Web Security || tool_licence = Commercial || tool_platforms = N/A}}
|
{{OWASP Tool Info || tool_name = [http://www.websecurify.com Websecurify] || tool_owner = GNUCITIZEN / Websecurify || tool_licence = Commercial / Free || tool_platforms = Windows, Mac OS, Linux and others}}
|
{{OWASP Tool Info || tool_name = [http://www.sensepost.com/research/wikto/ Wikto] || tool_owner = Sensepost || tool_licence = Open Source || tool_platforms = Windows}}
|
{{OWASP Tool Info || tool_name = [https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Zed Attack Proxy] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Windows, Unix/Linux and Macintosh}}
|}

== References ==

*http://projects.webappsec.org/Web-Application-Security-Scanner-Evaluation-Criteria
*https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/black-box/261-BSI.html#dsy261-BSI_Evaluation-Criteria
*http://www.uml.org.cn/Test/12/Automated%20Testing%20Tool%20Evaluation%20Matrix.pdf
*http://securityinnovation.com/security-report/October/vulnScanners15.htm
*http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html
*http://www.tssci-security.com/archives/2007/11/24/2007-security-testing-tools-in-review/
*http://www.softwareqatest.com/qatweb1.html
*http://www.proactiverisk.com/tools-page

[[Category:OWASP_Tools_Project]]

Business Logic Security Cheat Sheet

2013-10-24T18:35:33Z

Jeff Williams:

= Introduction =

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

= What is Business Logic Vulnerability? =

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization.

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. A useful rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, then it's probably just a typical application vulnerability in one of the other categories.

For example, an electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with one or more of the business rules.

= 1. Identify Business Rules and Derive Test/Abuse Cases =

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that
#) the control is in place to implement the business rule,
#) the control is implemented correctly and cannot be bypassed or tampered with, and
#) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process.
For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped.
Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, the actual testing may involve the use of some functional and security testing tools.

= 2. Consider Time Related Business Rules =

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

= 3. Consider Money Related Business Rules =

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

= 4. Consider Process Related Business Rules =

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow.
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

= 5. Consider Human Resource Business Rules =

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

= 6. Consider Contractual Relationship Business Rules =

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

= 7. TBD - Let's think of some other REAL Business Rules =

= Related Articles =

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf
* Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
* CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

= Authors and Primary Editors =

Ashish Rao rao.ashish20[at]gmail.com<br/>
David Fern dfern[at]verizon.net

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Business Logic Security Cheat Sheet

2013-10-24T18:35:09Z

Jeff Williams:

= Introduction =

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

= What is Business Logic Vulnerability? =

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization.

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. A useful rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, then it's probably just a typical application vulnerability in one of the other categories.

For example, an electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with one or more of the business rules.

= 1. Identify Business Rules and Derive Test/Abuse Cases =

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that
#) the control is in place to perform the transactions,
#) the control is implemented correctly and cannot be bypassed or tampered with, and
#) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process.
For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped.
Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, the actual testing may involve the use of some functional and security testing tools.

= 2. Consider Time Related Business Rules =

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

= 3. Consider Money Related Business Rules =

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

= 4. Consider Process Related Business Rules =

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow.
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

= 5. Consider Human Resource Business Rules =

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

= 6. Consider Contractual Relationship Business Rules =

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

= 7. TBD - Let's think of some other REAL Business Rules =

= Related Articles =

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf
* Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
* CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

= Authors and Primary Editors =

Ashish Rao rao.ashish20[at]gmail.com<br/>
David Fern dfern[at]verizon.net

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Business Logic Security Cheat Sheet

2013-10-24T18:34:42Z

Jeff Williams:

= Introduction =

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

= What is Business Logic Vulnerability? =

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization.

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. A useful rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, then it's probably just a typical application vulnerability in one of the other categories.

For example, an electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with one or more of the business rules.

= 1. Identify Business Rules and Derive Test/Abuse Cases =

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that
1) the control is in place to perform the transactions,
2) the control is implemented correctly and cannot be bypassed or tampered with, and
3) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process.
For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped.
Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, the actual testing may involve the use of some functional and security testing tools.

= 2. Consider Time Related Business Rules =

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

= 3. Consider Money Related Business Rules =

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

= 4. Consider Process Related Business Rules =

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow.
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

= 5. Consider Human Resource Business Rules =

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

= 6. Consider Contractual Relationship Business Rules =

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

= 7. TBD - Let's think of some other REAL Business Rules =

= Related Articles =

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf
* Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
* CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

= Authors and Primary Editors =

Ashish Rao rao.ashish20[at]gmail.com<br/>
David Fern dfern[at]verizon.net

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Business Logic Security Cheat Sheet

2013-10-24T18:29:54Z

Jeff Williams:

= Introduction =

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

= What is Business Logic Vulnerability? =

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules, workflow or privilege manipulation.

An electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

While there is no definitive list of possible business logic issues this section provides some guidance and common groups and generic areas to consider. The process for testing for business logic vulnerabilities requires following a process similar to those used in functional testing including:
# Requirements and Design Review – Understand the application – scope, features, business rules and roles and privilege levels.
# Test Planning – Gather data, roles and scenarios, understand workflows and approval levels.
# Test Case Design – Write the test cases i.e. abuse cases
# Test Environment Setup – Build the test bed
# Test Execution – Execute the tests
# Test Reporting – Save and report results

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with one or more of the business rules.

= 1. Identify Business Rules and Derive Test/Abuse Cases =

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that
1) the control is in place to perform the transactions,
2) the control is implemented correctly and cannot be bypassed or tampered with, and
3) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process.
For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped.
Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, the actual testing may involve the use of some functional and security testing tools.

= 2. Consider Time Related Business Rules =

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

= 3. Consider Money Related Business Rules =

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

= 4. Consider Process Related Business Rules =

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow.
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

= 5. Consider Human Resource Business Rules =

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

= 6. Consider Contractual Relationship Business Rules =

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

= 7. TBD - Let's think of some other REAL Business Rules =

= Related Articles =

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf
* Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
* CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

= Authors and Primary Editors =

Ashish Rao rao.ashish20[at]gmail.com<br/>
David Fern dfern[at]verizon.net

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Business Logic Security Cheat Sheet

2013-10-24T18:24:14Z

Jeff Williams:

= Introduction =

This cheat sheet provides some guidance for identifying some of the various types of business logic vulnerabilities and some guidance for preventing and testing for them.

= What is Business Logic Vulnerability? =

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules, workflow or privilege manipulation.

An electronic bulletin board system was designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on the list is found the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity list since on edit the posting is never compared again.

While there is no definitive list of possible business logic issues this section provides some guidance and common groups and generic areas to consider. The process for testing for business logic vulnerabilities requires following a process similar to those used in functional testing including:
# Requirements and Design Review – Understand the application – scope, features, business rules and roles and privilege levels.
# Test Planning – Gather data, roles and scenarios, understand workflows and approval levels.
# Test Case Design – Write the test cases i.e. abuse cases
# Test Environment Setup – Build the test bed
# Test Execution – Execute the tests
# Test Reporting – Save and report results

Testing for business rules vulnerabilities involves developing business logic abuse cases with the goal of successfully completing the business process while not complying with any of the business rules.
In simple words an abuse case would be – reverse of the business rule. Creating an exhaustive list of abuse cases for all the features of the application and testing for them would enumerate all the business logic errors present in the application.

= 1. Identify Business Rules and Derive Test/Abuse Cases =

The first step is to identify the business rules that you care about and turn them into experiments designed to verify whether the application properly enforces the business rule. For example, if the rule is that purchases over $1000 are discounted by 10%, then positive and negative tests should be designed to ensure that
1) the control is in place to perform the transactions,
2) the control is implemented correctly and cannot be bypassed or tampered with, and
3) the control is used properly in all the necessary places

Business rules vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent any business rules, constraints or restrictions put in place to properly complete the business process.
For example, on a stock trading application is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel out if the price dropped.
Business Logic testing uses many of the same testing tools and techniques used by functional testers. While a majority of Business Logic testing remains an art relying on the manual skills of the tester, their knowledge of the complete business process, and its rules, some testing can be automated using functional and security testing tools.

= 2. Consider Time Related Business Rules ===

TBD: Can the application be used to change orders after they are committed, make transactions appear in the wrong sequence, etc...

The application must be time-aware and not allow attackers to hold transactions open preventing them completing until and unless it is advantageous to do so.

= 3. Consider Money Related Business Rules ===

TBD: These should cover financial limits and other undesirable transactions. Can the application be used to create inappropriate financial transactions? Does it allow the use of NaN or Infinity? Are inaccuracies introduced because of the data structures used to model money?

= 4. Consider Process Related Business Rules ===

TBD: This is for steps in a process, approvals, communications, etc... Can the application be used to bypass or otherwise abuse the steps in a process?

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application in a way that will allow them to circumvent the designed workflow or continue once the workflow has been broken. For example, an ecommerce site that give loyalty points for each dollar spent should not apply points to the customer’s account until the transaction is tendered. Applying points to the account before tendering may allow the customer to cancel the transaction and incorrectly receive points.

The application must have checks in place ensuring that the users complete each step in the process in the correct order and prevent attackers from circumventing any steps/processes in the workflow.
Test for workflow vulnerabilities involves attempts to execute the steps in the process in an inappropriate order.

= 5. Consider Human Resource Business Rules

TBD: This is for rules surrounding HR. Could the application be used to violate any HR procedures or standards

= 6. Consider Contractual Relationship Business Rules

TBD: Can the application be used in a manner that is inconsistent with any contractual relationships -- such as a contract with a service provider

= 7. TBD - Let's think of some other REAL Business Rules

= Related Articles =

WARNING: Most of the examples discussed in these articles are not actually business logic flaws

* Seven Business Logic Flaws That Put Your Website At Risk – Jeremiah Grossman Founder and CTO, WhiteHat Security –
https://www.whitehatsec.com/assets/WP_bizlogic092407.pdf
* Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf
* CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

= Authors and Primary Editors =

Ashish Rao rao.ashish20[at]gmail.com<br/>
David Fern dfern[at]verizon.net

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Business logic vulnerability

2013-10-24T14:16:18Z

Jeff Williams: Undo revision 61074 by Ya Ali (talk)

{{Template:Vulnerability}}

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Description==
Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization. For example:

* Purchase orders are not processed before midnight
* Written authorization is not on file before web access is granted
* Transactions in excess of $2000 are not reviewed by a person

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Here are some examples of problems that are not business logic vulnerabilities:

* Performing a denial of service by locking an auction user's account
* Posting unvalidated input publically
* Cracking MD5 hashes
* Brute forcing a password recovery scheme

Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. Business logic problems are different from authentication problems and every other category. There are many signficant business logic vulnerabilities, but they are far less common than the type of items in the OWASP Top Ten for example.

A nice rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, you can't see business logic flaws.

==Risk Factors==

The likelihood of business logic problems really depends on the circumstances. You'll need to evaluate the threat agents who could possibly exploit the problem and whether it would be detected. Again, this will take a strong understanding of the business. The vulnerabilities themselves are often quite easy to discover and exploit without any special tools or techniques, as they are a supported part of the application.

Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.

==Related [[Attacks]]==

Fraud

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

==Related [[Technical Impacts]]==

==References==

__NOTOC__

[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Business logic vulnerability

2013-10-24T14:16:08Z

Jeff Williams: Undo revision 61075 by Ya Ali (talk)

{{Template:Vulnerability}}

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

[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]

==Brief Summary of Business Logic Vulnerability==

The most recent research represented about the concept Business Logic vulnerability by Jr.Scientist Faisal Nabi in the 24th Annual Computer Security Application Conference (ACSAC, 08)California, Dec 8-12 ,2008.

(ACSAC,08)work in progress session:

Designing a Secure Framework Method for Business Application Logic Integrity in e-Commerce Systems,Faisal Nabi, Distributed System Research Group, Department of Computer Science, Victoria University of Wellington, Wellington, New Zealand. http://www.acsac.org/2008/program/wip/

Business-level- Process Integration is based on business components integration, which takes part to process a certain job/task event, which comes into being because of business logic inside a component. When we talk about business process integration, which means integrating business component’s business processing logic,this integration completely rely upon that Business component’s Interface. A component interface is self descriptor which provides specification, which defines that which component offers, what service (such as,Account service provided by Account Component interface, this is called Component interface specification,which reflects component’s business process functionality, which indicates a component offer a particular service)Integration of components is limited through only the interface. Therefore, business process integration, which depends on component’s interface specification in business component, it refers to business function / processing logic, specification of that business component (Components are reusable units for composition. This statement captures the very fundamental concept of component-based development, that an application is made up and composed of a number of individual parts,and that these parts are specifically designed for integration in a number of different applications. It also captures the “idea that one component may be part of another component” , or part of a sub-system or system, both of which represent components in their own right), and integration of all this process, then develop overall business processing logic for a business component-based software to develop an application in the middle-tier, which connected with information system in the back-end systems of organization.

Since, this business process integration is made on the base of business functional concern; it can not be dealt with technological point of view, because problem is not based on technical or technological specific principle of Integration, which is based on related to some particular component model, but as it is stated above, issue identifies that business processing designed solution based on business components and their business processing integration. This is a point , where the focus is set to the logical structure of the “business solution”, this is the stage where logical problems occurs due to lack of paying attention to the design-based testing environment for Logical structure of the business solution , are known as Business Logic Vulnerabilities (Faisal Nabi, 2008).

Most security problems are weaknesses in an application that result from a broken or missing security control (authentication, access control, input validation, etc...). By contrast, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization. For example:

* Purchase orders are not processed before midnight
* Written authorization is not on file before web access is granted
* Transactions in excess of $2000 are not reviewed by a person

Many articles that describe business logic problems simply take an existing and well understood web application security problem and discuss the business consequence of the vulnerability. True business logic problems are actually different from the typical security vulnerability. Here are some examples of problems that are not business logic vulnerabilities:

* Performing a denial of service by locking an auction user's account
* Posting unvalidated input publically
* Cracking MD5 hashes
* Brute forcing a password recovery scheme

Too often, the business logic category is used for vulnerabilities that can't be scanned for automatically. This makes it very difficult to apply any kind of categorization scheme. Business logic problems are different from authentication problems and every other category. There are many signficant business logic vulnerabilities, but they are far less common than the type of items in the OWASP Top Ten for example.

A nice rule-of-thumb to use is that if you need to truly understand the business to understand the vulnerability, you might have a business-logic problem on your hands. If you don't understand the business, you can't see business logic flaws.

==Risk Factors==

The likelihood of business logic problems really depends on the circumstances. You'll need to evaluate the threat agents who could possibly exploit the problem and whether it would be detected. Again, this will take a strong understanding of the business. The vulnerabilities themselves are often quite easy to discover and exploit without any special tools or techniques, as they are a supported part of the application.

Business logic flaws are often the most critical in terms of consequences, as they are deeply tied into the company's process.

==Related [[Attacks]]==

Fraud

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

==Related [[Technical Impacts]]==

==References==

__NOTOC__

[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Asldkjaslfdasdfasf

2013-08-27T20:58:49Z

Jeff Williams: Created page with "Using this test page."

Using this test page.

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-07-11T19:38:31Z

Jeff Williams:

= 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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

== 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.

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the contect and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= data.to_json %> <-- data is HTML escaped, or at least json entity escaped -->
</script>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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</span> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer''' - https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

'''Other libraries that provide HTML Sanitization include:'''<br/>

PHP Html Purifier - http://htmlpurifier.org/<br/>
JavaScript/Node.JS Bleach - https://github.com/ecto/bleach<br/>
Python Bleach - https://pypi.python.org/pypi/bleach

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

OWASP Testing Guide v4 Table of Contents

2013-07-10T18:42:54Z

Jeff Williams:

__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 15th February 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Testing for Web Application Fingerprint (OWASP-IG-010)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002 ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)"

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)"

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)"

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)"

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test integrity checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates) [New!]

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for HTML5 (OWASP CS-002)|4.15.2 Testing for HTML5 (OTG-CLIENT-002)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.3 Testing for Cross Site Flashing (OTG-CLIENT-003)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.4 Testing for Clickjacking (OTG-CLIENT-004)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

Testing for Stack Traces (OTG-ERR-002)

2013-07-10T18:40:32Z

Jeff Williams: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attac..."

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Stack traces are not vulnerabilities by themselves, but they often reveal information that is interesting to an attacker. Attackers attempt to generate these stack traces by tampering with the input to the web application with malformed HTTP requests and other input data.

== Description of the Issue ==

== Black Box testing and example ==

There are a variety of techniques that will cause exception messages to be sent in an HTTP response. Note that in most cases this will be an HTML page, but exceptions can be sent as part of SOAP or REST responses too.

Some tools, such as [[OWASP ZAP]] and Burp proxy will automatically detect these exceptions in the response stream as you are doing other penetration and testing work.

== Gray Box testing and example ==

Search the code for the calls that cause an exception to be rendered to a String or output stream. For example, in Java this might be code in a JSP that looks like:

<pre><% e.printStackTrace( new PrintWriter( out ) ) %></pre>

In some cases, the stack trace will be specifically formatted into HTML, so be careful of accesses to stack trace elements.

Search the configuration to verify error handling configuration and the use of default error pages. For example, in Java this configuration can be found in web.xml.

== References ==

* [1] [[http://www.ietf.org/rfc/rfc2616.txt?number=2616 RFC2616]] Hypertext Transfer Protocol -- HTTP/1.1

OWASP Testing Guide v4 Table of Contents

2013-07-10T18:24:55Z

Jeff Williams:

__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 15th February 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Testing for Web Application Fingerprint (OWASP-IG-010)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002 ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)"

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)"

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)"

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Error Codes (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)"

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test integrity checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates) [New!]

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for HTML5 (OWASP CS-002)|4.15.2 Testing for HTML5 (OTG-CLIENT-002)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.3 Testing for Cross Site Flashing (OTG-CLIENT-003)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.4 Testing for Clickjacking (OTG-CLIENT-004)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2013-07-10T18:24:06Z

Jeff Williams:

__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 15th February 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Testing for Web Application Fingerprint (OWASP-IG-004)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Identify application exit/handover points (OWASP-IG-008)|4.2.7 Identify application exit/handover points (OTG-INFO-007) ]] formerly "Identify application exit/handover points (OWASP-IG-008)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Testing for Web Application Fingerprint (OWASP-IG-010)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)"

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002 ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)"

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)"

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Testing for Session puzzling (OWASP-SM-008)|4.7.8 Testing for Session puzzling (OWASP-SM-008)]]

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)"

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-002)]] formerly "Analysis of Stack Traces (OWASP-IG-006)"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)"

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)]] [New!] NOTE MAT: to discuss this section

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)]] [New!]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test integrity checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates) [New!]

[[Test tamper evidence (OTG-BUSLOGIC-004)|4.12.4 Test tamper evidence (OTG-BUSLOGIC-004)]] [New!]

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.12.5 Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)]] [New!]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.12.6 Test size of request limits (OTG-BUSLOGIC-006)]] [New!]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.7 Test number of times a function can be used limits (OTG-BUSLOGIC-002)]] [New!]

[[Test bypass of correct sequence (OTG-BUSLOGIC-008)|4.12.8 Test bypass of correct sequence (OTG-BUSLOGIC-008)]] [New!]

[[Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)|4.12.9 Test self-hosted payment cardholder data processing (OTG-BUSLOGIC-009)]] [New!]

[[Test security incident reporting information (OTG-BUSLOGIC-010)|4.12.10 Test security incident reporting information (OTG-BUSLOGIC-010)]] [New!]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.11 Test defenses against application mis-use (OTG-BUSLOGIC-011)]] [New!]

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for HTML5 (OWASP CS-002)|4.15.2 Testing for HTML5 (OTG-CLIENT-002)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.3 Testing for Cross Site Flashing (OTG-CLIENT-003)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.4 Testing for Clickjacking (OTG-CLIENT-004)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi]

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi]

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi]

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==

[To review--> Amro AlOlaqi]

----

[[Category:OWASP Testing Project]]

Injection Theory

2013-06-21T17:35:12Z

Jeff Williams:

[[Injection Flaws|Injection]] is an attacker's attempt to send data to an application in a way that will change the meaning of commands being sent to an interpreter. For example, the most common example is SQL injection, where an attacker sends "101 OR 1=1" instead of just "101". When included in a SQL query, this data changes the meaning to return ALL records instead of just one. There are lots of interpreters in the typical web environment, such as SQL, LDAP, Operating System, XPath, XQuery, Expression Language, and many more. Anything with a "command interface" that combines data into a command is susceptible. Even XSS is really just a form of HTML injection.

Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server. Taken together, injection attacks are a huge percentage of the serious application security risk. Many organizations have poorly thought through security controls in place to prevent injection attacks. Vague recommendations for input validation and output encoding are not going to prevent these flaws. Instead, we recommend a strong set of controls integrated into your application frameworks. The goal is to make injections impossible for developers.

=Why Injection Happens to Good Developers=

Injection can be complex. The subtleties of data flow, parsers, contexts, capabilities, and escaping are overwhelming even for security specialists. In the following sections we will outline these topics to make it clear how injection can happen in a variety of different technologies.

== Untrusted Data ==

First we need to consider the vehicle for injection attacks -- 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, untrusted data is input that can be manipulated to contain a web attack payload. 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.

As untrusted data flows through an application, it is frequently split into parts, combined with safe data, transformed, validated, and encoded in a variety of ways. A single piece of data could go through dozens of these steps before it gets to an interpreter. This makes identifying injection problems very difficult. Tools have a difficult time tracing the entire data flow and understanding exactly what data can run the gauntlet and what cannot.

== Injection Context ==

When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the '''injection context'''. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.

Consider a few of the types of commands and documents that might allow for injection...
* SQL queries
* LDAP queries
* Operating system command interpreters
* Any program invocation
* XML documents
* HTML documents
* JSON structures
* HTTP headers
* File paths
* URLs
* A variety of expresson languages
* etc...

In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.

== Parsers ==

TBD. Describe different types of parsers, tokens (particularly control characters), BNF.

== Injection into References ==

TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)

== Injection into Commands ==

TBD. Recursive descent or LALR parsers.

== Injecting in Hierarchical Documents ==

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.

== Injection with Multiple Nested Parsers ==

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...).

TBD

=DEFENSES=

== Validation ==

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.

== Using Safe Interfaces ==

TBD - parameterized interfaces with strong typing

== 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.

== Author ==

[[User:Jeff Williams]] : jeff.williams[at]aspectsecurity.com

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-06-17T04:38:20Z

Jeff Williams: /* RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way */

= 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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

== 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.

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the contect and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= data.to_json %> <-- data is HTML escaped, or at least json entity escaped -->
</script>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 - Sanitize HTML Markup with a Library Designed for the Job ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2013-06-17T04:37:03Z

Jeff Williams: /* RULE #6 - Use an HTML Policy engine to validate or clean user-driven HTML in an outbound way */

= 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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a cheatsheet on the attack vectors related to XSS, please refer to the [[XSS Filter Evasion Cheat Sheet]]. More background on browser security and the various browsers can be found in the [http://code.google.com/p/browsersec/ Browser Security Handbook].

Before reading this cheatsheet, it is important to have a fundamental understanding of [[Injection Theory]].

== 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.

Microsoft provides an encoding library named the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] for the .NET platform and ASP.NET Framework has built-in [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic6 ValidateRequest] function that provides '''limited''' sanitization.

The OWASP [[ESAPI]] project has created an escaping library for Java. OWASP also provides the [[OWASP Java Encoder Project]] for high-performance encoding.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; not recommended because its not in the HTML spec (See: [http://www.w3.org/TR/html4/sgml/entities.html section 24.4.1]) &apos; is in the XML and XHTML specs.
/ --> &#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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse ===

In a Web 2.0 world, the need for having data dynamically generated by an application in a javascript context is common. One strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though not impossible, to escape correctly without breaking the format and content of the values.

'''Ensure returned ''Content-Type'' header is application/json and not text/html.
This shall instruct the browser not misunderstand the contect and execute injected script'''

'''Bad HTTP response:'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: text/html; charset=utf-8''' <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
{"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens'''<script>alert(1)</script>'''&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No type was found
that matches the controller named 'pay'."} <-- this script will pop!!

'''Good HTTP response'''

HTTP/1.1 200
Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
'''Content-Type: application/json; charset=utf-8''' <--good
.....
.....

A common '''anti-pattern''' one would see:

<script>
var initData = <%= data.to_json %>; // '''Do NOT do this.'''
</script>

Instead, consider placing the JSON block on the page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads the span can live in an external file, thus making the implementation of CSP enforcement easier.

<script id="init_data" type="application/json">
<%= data.to_json %> <-- data is HTML escaped, or at least json entity escaped -->
</script>

<script>
var jsonText = document.getElementById('init_data').innerHTML; // unescapes the content of the span
var initData = JSON.parse(jsonText);
</script>

The data is added to the page and is HTML entity escaped so it won't pop in the HTML context. The data is then read by innerHTML, which unescapes the value. The unescaped text from the page is then parsed with JSON.parse.

== RULE #4 - CSS Escape And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 ==

If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several available at OWASP that are simple to use:

'''OWASP AntiSamy''' - https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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]].

= XSS Prevention Rules Summary =

The following snippets of HTML demonstrate how to safely render untrusted data in a variety of different contexts.

{| class="wikitable nowraplinks"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| <span><span style="color:red;">UNTRUSTED DATA</span></span>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| Safe HTML Attributes
| <input type="text" name="fname" value="<span style="color:red;">UNTRUSTED DATA</span>">
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li><li>Only place untrusted data into a whitelist of safe attributes (listed below).</li><li>Strictly validate unsafe attributes such as background, id and name.</ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=<span style="color:red;">UNTRUSTED DATA</span>">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL in a SRC or HREF attribute
| <a href="<span style="color:red;">UNTRUSTED URL</span>">clickme</a><br/><iframe src="<span style="color:red;">UNTRUSTED URL</span>" />
| <ul><li>Cannonicalize input</li><li>URL Validation</li><li>Safe URL verification</li><li>Whitelist http and https URL's only ([[Avoid the JavaScript Protocol to Open a new Window]])</li><li>Attribute encoder</li></ul>
|-
| String
| CSS Value
| <div style="width: <span style="color:red;">UNTRUSTED DATA</span>;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>Good design of CSS Features</ul>
|-
| String
| JavaScript Variable
| <script>var currentValue='<span style="color:red;">UNTRUSTED DATA</span>';</script><br/><script>someFunction('<span style="color:red;">UNTRUSTED DATA</span>');</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li><li>Avoid backslash encoding (\" or \' or \\)</li></ul>
|-
| HTML
| HTML Body
| <div><span style="color:red;">UNTRUSTED HTML</span></div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
| <script>document.write(<span style="color:red;">"UNTRUSTED INPUT: " + document.location.hash</span>);<script/>
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

'''''Safe HTML Attributes include:''''' align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width

= Output Encoding Rules Summary =

The purpose of output encoding (as it relates to Cross Site Scripting) is to convert untrusted input into a safe form where the input is displayed as '''data''' to the user without executing as '''code''' in the browser. The following charts details a list of critical output encoding methods needed to stop Cross Site Scripting.

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| Convert & to &amp;<br/>Convert < to &lt;<br/>Convert > to &gt;<br/>Convert " to &quot;<br/>Convert ' to &#x27;<br/>Convert / to &#x2F;
|-
| HTML Attribute Encoding
| Except for alphanumeric characters, escape all characters with the HTML Entity &#xHH; format, including spaces. (HH = Hex Value)
|-
| URL Encoding
| Standard percent encoding, see: [http://www.w3schools.com/tags/ref_urlencode.asp http://www.w3schools.com/tags/ref_urlencode.asp]
|-
| JavaScript Encoding
| Except for alphanumeric characters, escape all characters with the \uXXXX unicode escaping format (X = Integer).
|-
| CSS Hex Encoding
| CSS escaping supports \XX and \XXXXXX. Using a two character escape can cause problems if the next character continues the escape sequence. There are two solutions (a) Add a space after the CSS escape (will be ignored by the CSS parser) (b) use the full amount of CSS escaping possible by zero padding the value.
|}

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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

* [[XSS Experimental Minimal Encoding Rules]]

= Authors and Primary Editors =

Jeff Williams - jeff.williams[at]aspectsecurity.com<br/>
Jim Manico - jim[at]owasp.org<br/>
Eoin Keary - eoin.keary[at]owasp.org

= Other Cheatsheets =
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Category:OWASP Legal Project

2013-06-17T02:55:12Z

Jeff Williams:

= Home =

{| width="100%"
|-
! width="66%" |
! width="33%" |
|- valign="top"
|
The goal of the '''OWASP Legal Project''' is to ensure, at each stage of the life cycle, that appropriate attention has been paid to security. The cornerstone of the Legal Project is its Secure Software Development Contract Annex. The Contract Annex helps software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered. Here are two examples:

* '''Implementation.''' Developer agrees to provide and follow a set of secure coding guidelines and to use a set of common security control programming interfaces (such as the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]). Guidelines will indicate how code should be formatted, structured, and commented. Common security control programming interfaces will define how security controls must be called and how security controls shall function. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for unit test.

* '''Security Analysis and Testing.''' Developer will perform application security analysis and testing (also called "verification") according to the verification requirements of an agreed-upon standard (such as the [http://www.owasp.org/index.php/ASVS OWASP ASVS]). The Developer shall document verification findings according to the reporting requirements of the standard. The Developer shall provide the verification findings to Client.
|
[[Image:Esapi-sponsors.PNG]]

|}

{| width="100%"
|-
! width="33%" |
! width="33%" |
! width="33%" |
|- valign="top"
|
== Let's talk here ==

[[Image:Asvs-bulb.jpg]]'''Legal Communities'''

Further development of Legal Project documents occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please [mailto:jeff.williams@owasp.org contact us].

*[https://lists.owasp.org/mailman/listinfo/owasp-legal owasp-legal mailing list (this is the main list)]

|
== Got translation cycles? ==

[[Image:Asvs-writing.JPG]]'''Legal Project Translations'''

The Legal Project project is always on the lookout for volunteers who are interested in translating Legal Project documents into another language.

*Translation Onboarding Instructions -- Coming soon!

|
== Related resources ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

* [[Top Ten|OWASP Top Ten]]
* [[ASVS|OWASP Application Security Verification Standard]]
* [[:Category:OWASP_Enterprise_Security_API|OWASP ESAPI]]
* [[:Category:OWASP_Newsletter#tab=Press_releases|OWASP Press Releases]]
|}

= Downloads =

{| width="100%"
|-
! width="33%" |
! width="33%" |
|- valign="top"
|
[[Image:Asvs-step1.jpg]]'''1. About Legal Project Documents'''

* One Page Datasheet ([http://www.owasp.org/images/a/aa/Legal_One_Page_Handout.doc Word], [http://www.owasp.org/index.php/Image:Legal_One_Page_Handout.pdf PDF])
* One Page Datasheet in Japanese ([https://www.owasp.org/index.php/File:Legal_One_Page_Handout-ja.pdf PDF])

[[Image:Asvs-step2.jpg]]'''2. Get Legal Project Documents'''

* Contract Annex in English ([http://www.owasp.org/index.php/Image:OWASP_Secure_Software_Contract_Annex.doc Word], [http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex HTML])
* Contract Annex in Spanish ([http://www.owasp.org/index.php/Anexo_para_Contrato_de_Software_Seguro_de_OWASP HTML])
* Contract Annex in Japanese ([https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex/ja HTML])
* Contract Annex in French ([https://www.owasp.org/index.php/File:OWASP_Secure_Software_Contract_Annex-FR.doc Word])
* Verification schedule in English ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])

{{OWASP Book|4037498}}

|}

<br>

= Project Details =
{{:GPC_Project_Details/OWASP_Legal_Project | OWASP Project Identification Tab}}

__NOTOC__ <headertabs /> ''This project licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution ShareAlike 3.0].'' <br>

Category:OWASP Legal Project

2013-06-17T02:45:59Z

Jeff Williams:

= Home =

{| width="100%"
|-
! width="66%" |
! width="33%" |
|- valign="top"
|
The goal of the '''OWASP Legal Project''' is to ensure, at each stage of the life cycle, that appropriate attention has been paid to security. The cornerstone of the Legal Project is its Secure Software Development Contract Annex. The Contract Annex helps software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered. Here are two examples:

* '''Implementation.''' Developer agrees to provide and follow a set of secure coding guidelines and to use a set of common security control programming interfaces (such as the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI]). Guidelines will indicate how code should be formatted, structured, and commented. Common security control programming interfaces will define how security controls must be called and how security controls shall function. All security-relevant code shall be thoroughly commented. Specific guidance on avoiding common security vulnerabilities shall be included. Also, all code shall be reviewed by at least one other Developer against the security requirements and coding guideline before it is considered ready for unit test.

* '''Security Analysis and Testing.''' Developer will perform application security analysis and testing (also called "verification") according to the verification requirements of an agreed-upon standard (such as the [http://www.owasp.org/index.php/ASVS OWASP ASVS]). The Developer shall document verification findings according to the reporting requirements of the standard. The Developer shall provide the verification findings to Client.
|
[[Image:Esapi-sponsors.PNG]]

|}

{| width="100%"
|-
! width="33%" |
! width="33%" |
! width="33%" |
|- valign="top"
|
== Let's talk here ==

[[Image:Asvs-bulb.jpg]]'''Legal Communities'''

Further development of Legal Project documents occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please [mailto:jeff.williams@owasp.org contact us].

*[https://lists.owasp.org/mailman/listinfo/owasp-legal owasp-legal mailing list (this is the main list)]

|
== Got translation cycles? ==

[[Image:Asvs-writing.JPG]]'''Legal Project Translations'''

The Legal Project project is always on the lookout for volunteers who are interested in translating Legal Project documents into another language.

*Translation Onboarding Instructions -- Coming soon!

|
== Related resources ==

[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''

* [[Top Ten|OWASP Top Ten]]
* [[ASVS|OWASP Application Security Verification Standard]]
* [[:Category:OWASP_Enterprise_Security_API|OWASP ESAPI]]
* [[:Category:OWASP_Newsletter#tab=Press_releases|OWASP Press Releases]]
|}

= Downloads =

{| width="100%"
|-
! width="33%" |
! width="33%" |
|- valign="top"
|
[[Image:Asvs-step1.jpg]]'''1. About Legal Project Documents'''

* One Page Datasheet ([http://www.owasp.org/images/a/aa/Legal_One_Page_Handout.doc Word], [http://www.owasp.org/index.php/Image:Legal_One_Page_Handout.pdf PDF])
* One Page Datasheet in Japanese ([https://www.owasp.org/index.php/File:Legal_One_Page_Handout-ja.pdf PDF])

[[Image:Asvs-step2.jpg]]'''2. Get Legal Project Documents'''

* Contract Annex in English ([http://www.owasp.org/index.php/Image:OWASP_Secure_Software_Contract_Annex.doc Word], [http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex HTML])
* Contract Annex in Spanish ([http://www.owasp.org/index.php/Anexo_para_Contrato_de_Software_Seguro_de_OWASP HTML])
* Contract Annex in Japanese ([https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex/ja HTML])
* Contract Annex in French ([https://www.owasp.org/index.php/File:OWASP_Secure_Software_Contract_Annex-FR.doc HTML])
* Verification schedule in English ([http://www.owasp.org/index.php/Image:Sample_ASVS_Fee_Schedule_Template.xls Excel])

{{OWASP Book|4037498}}

|}

<br>

= Project Details =
{{:GPC_Project_Details/OWASP_Legal_Project | OWASP Project Identification Tab}}

__NOTOC__ <headertabs /> ''This project licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution ShareAlike 3.0].'' <br>

File:OWASP Secure Software Contract Annex-FR.doc

2013-06-17T02:44:13Z

Jeff Williams: French translation of OWASP SSCA

French translation of OWASP SSCA

Unvalidated Redirects and Forwards Cheat Sheet

2013-06-04T18:10:41Z

Jeff Williams: /* Dangerous Forward Example */

= Introduction =

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

= Safe URL Redirects =

When we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:

PHP
<?php
/* Redirect browser */
header("Location: http://www.mysite.com/");
?>

ASP.NET
Response.Redirect("~/folder/Login.aspx")

Rails
redirect_to login_path

In the examples above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker.

= Dangerous URL Redirects =

The following examples demonstrate unsafe redirect and forward code.

== Dangerous URL Redirect Example 1 ==

The following PHP code obtains a URL from the query string and then redirects the user to that URL.

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

A similar example of C# .NET Vulnerable Code:

string url = request.QueryString["url"];
Response.Redirect(url);

And in rails:
redirect_to params[:url]

The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:

http://example.com/example.php?url=http://malicious.example.com

The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place

== Dangerous URL Redirect Example 2 ==

ASP.NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3.

The code for the LogOn action in an ASP.NET MVC 2 application is shown below. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.

Listing 1 – ASP.NET MVC 2 LogOn action in AccountController.cs

[HttpPost]
public ActionResult LogOn(LogOnModel model, string returnUrl)
{
if (ModelState.IsValid)
{
if (MembershipService.ValidateUser(model.UserName, model.Password))
{
FormsService.SignIn(model.UserName, model.RememberMe);
if (!String.IsNullOrEmpty(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
else
{
ModelState.AddModelError("", "The user name or password provided is incorrect.");
}
}

// If we got this far, something failed, redisplay form
return View(model);
}

== Dangerous Forward Example ==

FIXME: This example is wrong...it doesn't even call forward().
The example should include (for example) a security-constraint in web.xml that prevents access to a URL.
Then the forward to that URL from within the application will bypass the constraint.

When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.

http://www.example.com/function.jsp?fwd=admin.jsp

The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains("url")) {
String url = request.getParameter("url");
response.sendRedirect(url);
}
}
}

= Preventing Unvalidated Redirects and Forwards =

Safe use of redirects and forwards can be done in a number of ways:

* Simply avoid using redirects and forwards.
* If used, do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
* If user input can’t be avoided, ensure that the supplied <strong>value</strong> is valid, appropriate for the application, and is <strong>authorized</strong> for the user.
* It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
* Sanitize input by creating a list of trusted URL's (lists of hosts or a regex).
* Force all redirects to first go through a page notifying users that they are going off of your site, and have them click a link to confirm.

= References =

# OWASP Article on Open Redirects https://www.owasp.org/index.php/Open_redirect
# CWE Entry 601 on Open Redirects http://cwe.mitre.org/data/definitions/601.html
# WASC Article on URL Redirector Abuse http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
# Google blog article on the dangers of open redirects http://googlewebmastercentral.blogspot.com/2009/01/open-redirect-urls-is-your-site-being.html
# Preventing Open Redirection Attacks (C#) http://www.asp.net/mvc/tutorials/security/preventing-open-redirection-attacks

= Authors and Primary Editors =

Susanna Bezold - susanna.bezold[at]owasp.org<br/>
Johanna Curiel - johanna.curiel[at]owasp.org<br/>
Jim Manico - jim[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Clickjacking Protection for Java EE

2013-01-25T20:04:53Z

Jeff Williams:

==Status==

Released Feb 6, 2009

==How to Stop ClickJacking==

This article shows how to prevent the IE8+ users of your Java EE application from getting clickjacked.

[[Clickjacking]] is an attack that tricks users by showing them an innocuous page but including the real controls from sensitive pages. These controls are disguised through the use of background frames that mask off everything except the control, so that the user can't tell that they are actually clicking on a sensitive function in some other website.

How can web applications protect their users from this attack? The typical defense to clickjacking is to prevent your pages from being framed. The typical approach to this is to include a "framebreaker" script in every page that ensures that the content is not framed. Here's an example of such a script.

<pre>
<script>if (top != self) top.location=location</script>
</pre>

* NOTE: this framebreaker is pretty simple. A better framebreaker will hide the entire page
and only redisplay if page is not being framed. An even better framebreaker than that will
not cause any change in the page-load experience. More to come soon!

However, there's an alternative approach that may be simpler to implement. Microsoft has now included a [http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx defense] in IE8 that allows developers to specify that pages should not be framed. They use a new (nonstandard) X-FRAME-OPTIONS header to mark responses that shouldn't be framed. There are two options with X-FRAME-OPTIONS. The first is DENY, which prevents everyone from framing the content. The other option is SAMEORIGIN, which only allows the current site to frame the content. Currently this works in IE8, Firefox, Safari, Opera and Chrome.

==Approach==

We'd like to add the X-FRAME-OPTIONS header to any pages that shouldn't be framed. So we could go into every servlet and JSP and add one of the two following lines of code:

// to prevent all framing of this content
response.addHeader( "X-FRAME-OPTIONS", "DENY" );

// to allow framing of this content only by this site
response.addHeader( "X-FRAME-OPTIONS", "SAMEORIGIN" );

However, this seems a bit intrusive and a lot of work. In this article, we'll implement a simple JavaEE filter to add the X-FRAME-OPTIONS header to some or all parts of your application.

==Download==

The source code and the compiled class file are in a single zip file.

'''[https://www.owasp.org/images/1/15/ClickjackFilter.zip DOWNLOAD]'''

==Setup==

The first step is to add the filter to our application. All we have to do is put the ClickjackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> ClickjackFilter). You can extract the class file from the zip file.

Then we just have to add the following filter definition and mapping to our web.xml. You should paste this in right above your servlet definitions. You should set up the mapping so it applies to '''any''' page that shouldn't be framed. Using /* will apply it to everything.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>OWASP ClickjackFilter</display-name>
<filter>
<filter-name>ClickjackFilterDeny</filter-name>
<filter-class>org.owasp.filters.ClickjackFilter</filter-class>
<init-param>
<param-name>mode</param-name>
<param-value>DENY</param-value>
</init-param>
</filter>

<filter>
<filter-name>ClickjackFilterSameOrigin</filter-name>
<filter-class>org.owasp.filters.ClickjackFilter</filter-class>
<init-param>
<param-name>mode</param-name>
<param-value>SAMEORIGIN</param-value>
</init-param>
</filter>


<filter-mapping>
<filter-name>ClickjackFilterDeny</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>



</web-app>
</pre>

==Source Code==

<pre>
/**
* Software published by the Open Web Application Security Project (http://www.owasp.org)
* This software is licensed under the new BSD license.
*
* @author Jeff Williams <a href="http://www.aspectsecurity.com">Aspect Security</a>
* @created February 6, 2009
*/

package org.owasp.filters;
import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

public class ClickjackFilter implements Filter
{

private String mode = "DENY";

/**
* Add X-FRAME-OPTIONS response header to tell IE8 (and any other browsers who
* decide to implement) not to display this content in a frame. For details, please
* refer to http://blogs.msdn.com/sdl/archive/2009/02/05/clickjacking-defense-in-ie8.aspx.
*/
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
HttpServletResponse res = (HttpServletResponse)response;
res.addHeader("X-FRAME-OPTIONS", mode );
chain.doFilter(request, response);
}

public void destroy() {
}

public void init(FilterConfig filterConfig) {
String configMode = filterConfig.getInitParameter("mode");
if ( configMode != null ) {
mode = configMode;
}
}

}

</pre>

==Compile==

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath servlet-api.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder in your application. You could also jar it up and put it in the lib directory.

==Testing==

First, you'll need IE8 RC1+. I downloaded a free VHD of IE8 beta from [http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF&displaylang=en Microsoft] and then did a Windows Update to IE8 RC1. You'll need to install the free [http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx VirtualPC] to run this.

There's a very simple test case in the WebContent directory of the zip file. It has one page with the text "unframeable content" and another page that opens the first page in a frame. When you set the filter to DENY in web.xml, the page shows an error message that the content cannot be viewed in a frame. When you set it to SAMEORIGIN, the content is allowed.

You may want to check out the [http://evil.hackademix.net/frameopts/ demo] page that Giorgio Maone put together.

[[Category:How To]]
[[Category:OWASP Java Project]]
[[Category:Countermeasure]]
[[Category: Control]]

Injection Theory

2012-09-17T12:15:57Z

Jeff Williams:

[[Injection Flaws|Injection]] is an attack that attempts to invoke an interpreter or change the meaning of commands sent to an interpreter. Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server.

=Why Injection Happens to Good Developers=

Injection can be complex. The subtleties of data flow, parsers, contexts, capabilities, and escaping are overwhelming even for security specialists. In the following sections we will outline these topics to make it clear how injection can happen in a variety of different technologies.

== Untrusted Data ==

First we need to consider the vehicle for injection attacks -- 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, untrusted data is input that can be manipulated to contain a web attack payload. 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.

TBD: Data Flow

== Injection Context ==

When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the '''injection context'''. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.

Consider a few of the types of commands and documents that might allow for injection...
* SQL queries
* LDAP queries
* Operating system command interpreters
* Any program invocation
* XML documents
* HTML documents
* JSON structures
* HTTP headers
* File paths
* URLs
* A variety of expresson languages
* etc...

In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.

== Parsers ==

TBD. Describe different types of parsers, tokens (particularly control characters), BNF.

== Injection into References ==

TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)

== Injection into Commands ==

TBD. Recursive descent or LALR parsers.

== Injecting in Hierarchical Documents ==

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.

== Injection with Multiple Nested Parsers ==

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...).

TBD

=DEFENSES=

== Validation ==

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.

== Using Safe Interfaces ==

TBD - parameterized interfaces with strong typing

== 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.

== Author ==

[[User:Jeff Williams]] : jeff.williams[at]aspectsecurity.com

Injection Theory

2012-09-16T23:18:54Z

Jeff Williams:

[[Injection Flaws|Injection]] is an attack that attempts to invoke an interpreter or change the meaning of commands sent to an interpreter. Frequently these interpreters run with a lot of access, so a successful attack can easily result in loss of control of a browser, application, or server.

== Untrusted Data ==

First we need to consider the vehicle for injection attacks -- 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, untrusted data is input that can be manipulated to contain a web attack payload. 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.

== Injection Context ==

When untrusted data is used by an application, it is often inserted into a command, document, or other structure. We will call this the '''injection context'''. For example, consider a SQL statement constructed with "SELECT * FROM users WHERE name='" + request.getParameter( "name" ) + "'"; In this example, the name is data from a potentially hostile user, and so could contain an attack. But the attack is constrained by the injection context. In this case, inside single quotes ('). That's why single quotes are so important for SQL injection.

Consider a few of the types of commands and documents that might allow for injection...
* SQL queries
* LDAP queries
* Operating system command interpreters
* Any program invocation
* XML documents
* HTML documents
* JSON structures
* HTTP headers
* File paths
* URLs
* A variety of expresson languages
* etc...

In all of these cases, if the attacker can "break out" of the intended injection context and modify the meaning of the command or document, they might be able to cause significant harm.

== Injection into References ==

TBD. This is for URLs, paths, and other simple forms. Focus on the parser. Could be as simple as Double.parseDouble (mark of the beast)

== Injection into Commands ==

TBD. Recursive descent or LALR parsers.

== Injecting in Hierarchical Documents ==

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.

== Injection with Multiple Parsers ==

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...).

TBD

=DEFENSES=

== Validation ==

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.

== Using Safe Interfaces ==

TBD - parameterized interfaces with strong typing

== 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.

== Author ==

[[User:Jeff Williams]] : jeff.williams[at]aspectsecurity.com

Rugged Software

2012-08-30T13:31:05Z

Jeff Williams: Replaced content with "Moved to http://ruggedsoftware.org"

Moved to http://ruggedsoftware.org

WebGoat Installation

2012-03-24T02:40:53Z

Jeff Williams:

<webgoat/>[[WebGoat User Guide Table of Contents]]
__TOC__

WebGoat is a platform independent environment.
It utilizes Apache Tomcat and the JAVA development environment.
Installers are provided for Microsoft Windows and UN*X environments, together with notes for installation on other platforms.

==Installing Java and Tomcat ==
'''Note''': This may no longer be necessary for v5.

===Installing Java===
# Install and deploy the approprite version from http://java.sun.com/downloads/ (1.4.1 or later)

===Installing Tomcat===
# Install and deploy core Tomcat from http://tomcat.apache.org/download-55.cgi

NOTE: WebGoat includes a very old version of catalina-4.1.9.jar.
To run WebGoat on Tomcat 7, you'll need to expand the war file
and delete this file from WEB-INF/lib

==Installing to Windows ==
# Unzip WebGoat-OWASP_Standard-5.2.zip to your working environment.
# To start Tomcat, browse to the WebGoat directory unzipped above and double click "webgoat.bat"
# Start your browser and browse to: <u>http://localhost/WebGoat/attack</u> This link is case-sensitive. Make sure to use a large ‘W’ and ‘G’.

==Installing to Linux ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing to OS X (Tiger 10.4+) ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on line 10 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing on FreeBSD ==
<ol>
<li>Install Tomcat and Java from the ports collection:<pre>
cd /usr/ports/www/tomcat55
sudo make install
</pre></li>
<li>You will be required to manually [http://www.FreeBSDFoundation.org/cgi-bin/download?download=diablo-caffe-freebsd6-i386-1.5.0_07-b01.tar.bz2 download the Java JDK] to install it. Instructions are given by the ports system about when and how to do this.</li>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Running ==
# Start your browser and browse to: <u>http://localhost/WebGoat/attack</u>. Notice the capital 'W' and 'G'

Warning: The "WebGoat" part of the path (the "context root") should exactly match (case-sensitive) the
war (web archive) that gets deployed. When you launch WebGoat, the console will have a line like:

INFO: Deploying web application archive webgoat.war

This means that your URL will be <u>http://localhost/webgoat/attack</u> -- note the lowercase "webgoat"

# Login in as: user = guest, password = guest

==Building ==
Skip these instructions if you are only interested in running WebGoat.

WebGoat is built using eclipse WTP 1.5.x. Please read the instructions at [http://webgoat.googlecode.com/svn/trunk/webgoat/README.txt Goodle code] to build the WebGoat application.

==Installing WAR file to existing Tomcat server==
Place the .war file in your Tomcat webapps directory (it will self extract). You'll need to resolve several issues that are outlined in the [http://code.google.com/p/webgoat/wiki/FAQ Webgoat FAQ].

Return to the [[WebGoat User Guide Table of Contents]]
[[Category:OWASP WebGoat Project]]

User:Jeff Williams

2012-03-16T05:25:47Z

Jeff Williams:

I'm Jeff Williams, I work as CEO of [http://www.aspectsecurity.com Aspect] [https://www.aspectsecurity.com Security] and I served as the volunteer Chair of the OWASP Foundation from 2003 to 2012. I’ve dedicated my life to trying to make the world’s software more secure, and so I create lots of free and open tools, libraries, guidance, and standards to try to change the status quo. Thank you all for your dedication to application security and your participation in OWASP. Please send any questions or comments to me via email at [mailto:jeff.williams@aspectsecurity.com jeff.williams@aspectsecurity.com]. Or you can twitter @planetlevel.

last revised {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

Some of my work (in roughly reverse chronological order)
* Enterprise Java Rootkits - http://www.aspectsecurity.com/documents/EnterpriseJavaRootkits.zip
* XSS-Proofing Your JavaEE, JSP, and JSP Applications - http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4374&yr=2009&track=javaee
I'm an official [http://java.sun.com/javaone/2009/rockstars.jsp Java Rock Star]!
* XSS Prevention Cheatsheet – http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
* Java EE ClickJack Filter - http://www.owasp.org/index.php/ClickjackFilter_for_Java_EE
* Enterprise Security API – http://www.owasp.org/index.php/ESAPI
* Application Security Verification Standard - http://www.owasp.org/index.php/ASVS
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java PDF Attack Filter - http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE
* Application Security Risk Rating Model - http://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
* CSRF Tester Tool - http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project
* CSRF Guard - http://www.owasp.org/index.php/CSRF_Guard
* How to Write Insecure Code - http://www.owasp.org/index.php/How_to_write_insecure_code
* Java Stinger Validation Library - http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
* Application Security Contract Annex - http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
* OWASP Chapters Program - http://www.owasp.org/index.php/Category:OWASP_Chapter
* OWASP Foundation - http://www.owasp.org/index.php/OWASP_Foundation
* OWASP Top Ten – http://www.owasp.org/index.php/Topten
* WebGoat Application Security Learning Environment - http://www.owasp.org/index.php/Webgoat
* Systems Security Engineering CMM - http://sse-cmm.org/index.html

To see my wiki contributions, [[:Special:Contributions/Jeff Williams|click here]].

==Background==

My background, from an [http://myappsecurity.blogspot.com/2007/03/reflection-on-jeff-williams.html interview]

I set out to be a user interface guy, but I got into security accidentally. I was working at TRW in 1992 on the user interface for a big Navy system that just happened to be highly secure – targeting B2 in the Orange Book. I took on an R&D project to port the user interface to the new compartmented mode workstation (what became Trusted Solaris) and I found that I really liked the challenge of securing such a complex system.

Then Java 1.0 came along and I got NIST and NRL funding to do security research. At the time, we thought the Java sandbox was a good idea, but that there were attacks that might bypass it. So I wrote a special classloader that modified the bytecode to wrap security relevant method calls with a reference monitor. After that I spent several years developing a Java-based multilevel secure network guard on Trusted Solaris. That guard handled HTTP, FTP, TDS, and a number of other protocols – sort of a very early application firewall. But unlike the modern WAFs, we took a whitelist approach where you would define exactly the data formats and rules for allowing messages.

In the mid-90’s, I chaired the group that authored the SSE-CMM, which is now ISO 21827. As it turns out, the processes involved in systems security engineering are quite similar to those necessary for secure software development. I’m very glad to see that the idea of assurance arguments from my work is starting to be used in the application security world.

Then in 1998, while I was the technical director of the Global Security Practice at Exodus Communications, a Fortune 10 company approached us and said “We’d like to host our applications with you, but we have this rule – every line of code has to be reviewed before it goes on the Internet.” So I started an application security practice and started providing application assessments, developer training, and help with security requirements and architecture. We built a successful practice securing some of the biggest and most complex web applications in the world.

In April 2002, together with Dave Wichers, Noelle Hardy, and some other great folks, I started Aspect Security to focus exclusively on application security. I just feel so fortunate to get to work with such an amazing group of consultants and customers. I’m having the most fun of my professional career.

I first heard of OWASP in 2001 from Chuck Pfleeger (the author of Security in Computing). The idea of a free and open community for application security was an interesting idea. At the time, getting companies to focus on application security was difficult. In meetings with several government agencies, they acknowledged that it was an issue, but that they were managing to the SANS Top 20. I came home and literally in the shower said to myself, “I wish we had an application security top ten…” So a small team of us at Aspect took the lead in drafting the first OWASP Top Ten.

Later, Aspect donated WebGoat, a hands-on training environment for application security issues that we had developed for our courses. A huge number of organizations, including Google, use WebGoat today to teach their developers about application security. We started to see that participation in OWASP allowed Aspect to demonstrate our skills in a very constructive way, and many of our customers have contacted us after seeing our participation in OWASP.

I was honored to take over the leadership of OWASP in 2003. At that time, we had a number of great contributors, but OWASP itself was just a domain name and a few small projects. So I got us set up as a 501c3 nonprofit organization and put a management structure in place. I want the OWASP Foundation to provide a free, open, supportive community infrastructure for application security projects. We’re making the barriers to entry for contribution so low that security experts will be motivated to make the effort and share their expertise.

One of the key challenges has been to ensure that OWASP is not influenced by commercial interests. When I set up the AppSec conference and local chapter rules, I made sure that vendors are cannot use OWASP to market their products. We’re also starting to ferret out abuse of the OWASP brand by companies that claim their products “address the OWASP Top Ten” or enable “OWASP Compliance.” The local chapters have been growing very quickly and starting to contribute back to the mothership. Our conferences have also been a great experience.

I think the switch to the MediaWiki platform in 2006 was a major step for OWASP. Prior to that, contributing content was a difficult and painful process. Now, anyone can create an account and contribute easily. We have a team set up to review all the contributions and the number of abuses in our first year has been astoundingly low (less than 10 incidents). We’re to the point now where we get dozens of articles and contributions every day. I don’t see how a non-open approach to building an application security body of knowledge can possibly keep up with our productivity.

We’re still a long way from the point where a company can go to OWASP for everything they need in order to build, acquire, and operate secure applications… but we’ve got an incredible process and we’re working very hard to get there.

I have big family and absolutely love my kids. We live in the woods and spend a lot of time outside with our two Labrador retrievers. I’m very much into sports – I rowed on the crew team at UVA and still play basketball three times a week (if you meet me you'll know why). For a while I was into extreme rollerblading and then I got into mountain bike trials – I broke a lot of equipment, but never had any serious injuries :)"

==Articles / Presentations==

Opening the Black Box: A Source Code Security Analysis Case Study
http://www.aspectsecurity.com/documents/Aspect_Opening_Black_Box.doc

Application Security Initiatives - The Best Defense Is a Good Offense
http://www.aspectsecurity.com/documents/Application_Security_Initiatives.htm

Let's Sue the Idiots -- Security, Software, Contracts, and Lawyers
http://www.aspectsecurity.com/article/sscl.htm

How to Build an HTTP Request Validation Engine for Your J2EE Application
http://www.aspectsecurity.com/article/bld_HTTP_req_val_engine.htm

Access Control (aka Authorization) in Your J2EE Application
http://www.aspectsecurity.com/article/access_control.htm

Trustworthy Java - Are your apps bulletproof?
http://www.aspectsecurity.com/article/trust_java.htm

The Ten Most Critical Web Application Security Vulnerabilities
http://www.aspectsecurity.com/owasp.htm

Security Code Review - the Best Way to Eliminate Vulnerabilities in Software" -
http://www.aspectsecurity.com/documents/AspectCodeReviewWhitePaper.pdf

Can a 'Social Protocol' Help Protect Privacy?
http://www.aspectsecurity.com/documents/p3p.pdf

Jini and Mobile Agent Security - Proceedings of the Workshop on Agent Technologies (AT ‘98)
http://www.aspectsecurity.com/documents/jini.pdf

A Practical Approach to Improving and Communicating Assurance - Proceedings of the 10th Canadian Information Technology Security Symposium (CITSS)
http://www.aspectsecurity.com/documents/Arguing.pdf

A Practical Approach to Measuring Assurance - Proceedings of the 1998 Security Applications Conference (ACSAC)
http://www.aspectsecurity.com/documents/Measuring.pdf

System Security Engineering Capability Maturity Model (SSE-CMM) version 2.0 - Released at the 21st Annual National Information System Security Conference (NISSC)
http://www.aspectsecurity.com/documents/SSECMMv2Final.pdf

Just Sick about Security - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Sick.pdf

An Enterprise Assurance Framework - Proceedings of the 5th Workshop on Enabling Technologies
http://www.aspectsecurity.com/documents/WetIce.pdf

Pretty Good Assurance - Proceedings of the New Security Paradigms Workshop
http://www.aspectsecurity.com/documents/Pretty.pdf

Need for a Framework for Reasoning about Assurance - Proceedings of the International Workshop on IT Assurance and Trustworthiness (WITAT)
http://www.aspectsecurity.com/documents/Need.pdf

Assurance is an N-Space (Where N is Hopefully Small) - Proceedings of the International Invitational Workshop on Developmental Assurance
http://www.aspectsecurity.com/documents/Nspace.pdf

A Capability Maturity Model For Security Engineering - Proceedings of the 6th Annual Canadian Computer Security Symposium
http://www.aspectsecurity.com/documents/CITSS94.doc

Unsafe at Any (CPU) Speed: Why We Keep Making the Same Mistakes - NSA High Confidence Software and Systems Conference

Web Applications: The “Last Mile” of Internet Security

A Constructionist Approach to Law and Society - Law and Society Seminar, Georgetown University Law Center

Interpreting Anticircumvention (DMCA) - Advanced International Copyright Law, Georgetown University Law Center

P3I – Protection Profile Process Improvement - Proceedings of the 22nd National Information System Security Conference (NISSC)

Windows NT Security - 17th Annual National Computer Security Conference (NCSC)

Windows NT Client Security and Windows NTAS Security - The Local Area Network Security Conference (LANSEC)

Reusing Existing C3I Systems in a Secure Environment - Proceedings of the Application of COTS and Reusable Components Conference

A Framework for Reasoning about Assurance - Published by the National Computer Security Center of the NSA
Proceedings of the 11th Annual Conference on Computer Assurance (COMPASS)

Interconnecting MLS Command Centers - White paper for the Multilevel Security Initiative at Hanscomb AFB

==Education==

* JD cum laude – Georgetown Law - Cyberlaw and Intellectual Property
* MA – George Mason - Human Factors Engineering
* BA – University of Virginia - Cognitive Psychology and Computer Science (Specialization in AI)

OWASP AppSec DC 2012/The Unfortunate Reality of Insecure Libraries

2012-03-12T20:54:15Z

Jeff Williams:

<noinclude>{{:OWASP AppSec DC 2012 Header}}</noinclude>
__NOTOC__
== The Presentation ==
Many organizations have started application security programs to focus on finding and subsequently preventing vulnerabilities in their custom code. However, the widespread use of common libraries introduces risks that are widely ignored and unappreciated. In this study, we analyze over 113 million library downloads from the Maven Central repository of the 31 most popular Java frameworks and security libraries by over 60,000 companies. The data show that there are a surprising amount of libraries with known vulnerabilities in common use. The data reveal some very interesting facts about our use of libraries, and we conclude that most organizations do not appear to have a strong process in place for ensuring that the libraries they rely on are up-to-date and free from known vulnerabilities.
== The Speakers ==
<table>
<tr>
<td>
===Arshan Dabirsiaghi===
[[Image:Owasp_logo_normal.jpg|left]]Bio TBA
</td>
</tr>
<tr>
<td>
===Jeff Williams===
[[Image:Owasp_logo_normal.jpg|left]]Bio TBA
</td>
</tr>
</table>
<noinclude>{{:OWASP AppSec DC 2012 Footer}}</noinclude>

XSS (Cross Site Scripting) Prevention Cheat Sheet

2012-02-23T01:33:24Z

Jeff Williams:

= 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.

Both [[XSS#Stored_and_Reflected_XSS_Attacks | reflected and stored XSS]] can be addressed by performing the appropriate validation and escaping on the server-side. The use of an escaping/encoding library like the one in [[ESAPI]] or the [http://wpl.codeplex.com Microsoft Anti-Cross Site Scripting Library] is strongly recommended as there are many special cases. [[DOM Based XSS]] can be addressed with a special subset of rules described in the [[DOM based XSS Prevention Cheat Sheet]].

For a 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, untrusted data is input that can be manipulated to contain a web attack payload. 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, PHP, Classic ASP, Cold Fusion, Python, and Haskell. Microsoft provides an encoding library named the [http://www.microsoft.com/download/en/details.aspx?id=325 Microsoft Anti-Cross Site Scripting Library] for the .NET platform.

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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; &apos; 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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 and validation 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 ==

'''OWASP AntiSamy'''

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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 Prevention Cheat Sheet]].

== Bonus Rule: Use 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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]owasp.org

[[Category:Cheatsheets]]

WebGoat Installation

2011-12-13T00:27:38Z

Jeff Williams:

<webgoat/>[[WebGoat User Guide Table of Contents]]
__TOC__

WebGoat is a platform independent environment.
It utilizes Apache Tomcat and the JAVA development environment.
Installers are provided for Microsoft Windows and UN*X environments, together with notes for installation on other platforms.

==Installing Java and Tomcat ==
'''Note''': This may no longer be necessary for v5.

===Installing Java===
# Install and deploy the approprite version from http://java.sun.com/downloads/ (1.4.1 or later)

===Installing Tomcat===
# Install and deploy core Tomcat from http://tomcat.apache.org/download-55.cgi

==Installing to Windows ==
# Unzip WebGoat-OWASP_Standard-5.2.zip to your working environment.
# To start Tomcat, browse to the WebGoat directory unzipped above and double click "webgoat.bat"
# Start your browser and browse to: <u>http://localhost/WebGoat/attack</u> This link is case-sensitive. Make sure to use a large ‘W’ and ‘G’.

==Installing to Linux ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing to OS X (Tiger 10.4+) ==
<ol>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on line 10 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Installing on FreeBSD ==
<ol>
<li>Install Tomcat and Java from the ports collection:<pre>
cd /usr/ports/www/tomcat55
sudo make install
</pre></li>
<li>You will be required to manually [http://www.FreeBSDFoundation.org/cgi-bin/download?download=diablo-caffe-freebsd6-i386-1.5.0_07-b01.tar.bz2 download the Java JDK] to install it. Instructions are given by the ports system about when and how to do this.</li>
<li>Unzip WebGoat-OWASP_Standard-x.x.zip to your working directory.</li>
<li>Change "1.5" on lines 17, 19, and 23 of webgoat.sh to "1.6".</li>
<li>Since the latest version runs on a privileged port, you will need to start/stop WebGoat & Tomcat either:</li>
<ol type="a">
<li>on port 80 as root:<pre>
sudo sh webgoat.sh start80
sudo sh webgoat.sh stop
</pre></li>
<li>or on port 8080:<pre>
sh webgoat.sh start8080
sh webgoat.sh stop
</pre></li>
</ol>
</li>
</ol>

==Running ==
# Start your browser and browse to: <u>http://localhost/WebGoat/attack</u>. Notice the capital 'W' and 'G'

Warning: The "WebGoat" part of the path (the "context root") should exactly match (case-sensitive) the
war (web archive) that gets deployed. When you launch WebGoat, the console will have a line like:

INFO: Deploying web application archive webgoat.war

This means that your URL will be <u>http://localhost/webgoat/attack</u> -- note the lowercase "webgoat"

# Login in as: user = guest, password = guest

==Building ==
Skip these instructions if you are only interested in running WebGoat.

WebGoat is built using eclipse WTP 1.5.x. Please read the instructions at [http://webgoat.googlecode.com/svn/trunk/webgoat/README.txt Goodle code] to build the WebGoat application.

==Installing WAR file to existing Tomcat server==
Place the .war file in your Tomcat webapps directory (it will self extract). You'll need to resolve several issues that are outlined in the [http://code.google.com/p/webgoat/wiki/FAQ Webgoat FAQ].

Return to the [[WebGoat User Guide Table of Contents]]
[[Category:OWASP WebGoat Project]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2011-11-09T15:13:20Z

Jeff Williams:

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 ==

'''OWASP AntiSamy'''

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

'''OWASP Java HTML Sanitizer'''

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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_Prevention_Cheat_Sheet]].

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

== Bonus Rule: Use 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2011-11-09T15:00:39Z

Jeff Williams:

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 And Strictly Validate 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

Please note there are some CSS contexts that can never safely use untrusted data as input - <b>EVEN IF PROPERLY CSS ESCAPED</b>! You will have to ensure that URLs only start with "http" not "javascript" and that properties never start with "expression".

For example:
{ background-url : "javascript:alert(1)"; } // and all other URLs
{ text-size: "expression(alert('XSS'))"; } // only in IE

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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

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 ==

= OWASP AntiSamy =

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

= OWASP Java HTML Sanitizer =

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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_Prevention_Cheat_Sheet]].

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2011-11-09T14:51:44Z

Jeff Williams: /* RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values */

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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 JavaScript Data Values ==

Rule #3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 And Strictly Validate 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 ==

= OWASP AntiSamy =

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

= OWASP Java HTML Sanitizer =

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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_Prevention_Cheat_Sheet]].

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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:Cheatsheets]]

XSS (Cross Site Scripting) Prevention Cheat Sheet

2011-11-09T14:48:59Z

Jeff Williams:

= 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. This includes "nested contexts" like a URL inside a javascript -- the encoding rules for those locations are tricky and dangerous. If you insist on putting untrusted data into nested contexts, please do a lot of cross-browser testing and let us know what you find out.

<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

<style>'''...NEVER PUT UNTRUSTED DATA HERE...'''</style> directly in CSS

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 javascript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, 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. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. However, we have intentionally made this rule quite broad because event handler attributes are often left unquoted. 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 And Strictly Validate 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 ==

= OWASP AntiSamy =

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

= OWASP Java HTML Sanitizer =

import org.owasp.html.Sanitizers;
import org.owasp.html.PolicyFactory;
PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);
String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

For more information on OWASP Java HTML Sanitizer policy construction, see [http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html http://owasp-java-html-sanitizer.googlecode.com/svn/trunk/distrib/javadoc/org/owasp/html/Sanitizers.html]

== 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_Prevention_Cheat_Sheet]].

= 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

'''A Systematic Analysis of XSS Sanitization in Web Application Frameworks'''

[http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf http://www.cs.berkeley.edu/~prateeks/papers/empirical-webfwks.pdf]

'''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:Cheatsheets]]