XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
A 3.1 Defenses:
Encode untrusted data:
|Data Type||Context||Code Sample||Defense|
|String||HTML Body||<span>UNTRUSTED DATA</span>|
|String||Safe HTML Attributes||<input value="UNTRUSTED DATA">||
|String||GET Parameter||<a href="/site/search?value=UNTRUSTED DATA">clickme</a>|
|String||Untrusted URL in a SRC or HREF attribute|| <a href="UNTRUSTED URL">clickme</a>
<iframe src="UNTRUSTED URL" />
|String||CSS Value||<div style="width:UNTRUSTED DATA">Selection</div>||
|HTML||HTML Body||<div>UNTRUSTED HTML</div>|
|String||DOM XSS||<script>document.write("UNTRUSTED INPUT: " + document.location.hash);<script/>|
Unless maven is managing your CLASSPATH for you, you need to add both owasp-java-html-sanitizer.jar and the Guava JAR.
Once you have your CLASSPATH set up correctly with the relevant JARs you should be able to addimport org.owasp.html.HtmlPolicyBuilder;to one of your project's;.java;files and compile it.
Unless maven is managing your CLASSPATH for you, you need to add both owasp-java-html-sanitizer.jar;and the Guava JAR.
Generally Encode.forHtml(UNTRUSTED) is also safe but slightly less efficient for the above two contexts (for textarea content and input value text) since it encodes more characters than necessary but might be easier for developers to use.
Is safe for the above two contexts, but encodes more characters and is less efficient.
When handling a full url with the OWASP Java encoder, first verify the URL is a legal URL.
Then encode the URL as an HTML attribute when outputting to the page. Note the linkable text needs to be encoded in a different context.
Other contexts can be found in the org.owasp.Encode class methods, including CSS strings, CSS urls, XML contexts, URIs and URI components.
A 3.2.3 DOMPurify
A 3.2.4 MentalJS
A 3.2.5 OWASP JSON Sanitizer
- Use .innerText instead of .innerHtml
- Don't use eval
- Canonicalize data to consumer (read: encode before use)
- Don't rely on client logic for security
- Don't rely on client business logic
- Avoid writing serialization code
- Avoid building XML or JSON dynamically
- Never transmit secrets to the client
- Don't perform encryption in client side code
- Don't perform security impacting logic on client side
- Server Side
- Protect against JSON Hijacking for Older BrowsersUse CSRF Protection
- Always return JSON with an Object on the outside
- Avoid writing serialization code. Remember ref vs. value types!
- Services can be called by users directly
- Avoid building XML or JSON by hand, use the framework
- Use JSON And XML Schema for Webservices
Major form of attacks can result from HTTP Response Splitting:
- Cross-site Scripting
- Web Cache Poisoning
- Hijacking pages
- Browser cache Poisoning
- Cross User attacks (single user, single page, temporary defacement)
Investigate all uses of HTTP headers, such as:
- setting cookies
- using location (or redirect() functions)
- setting mime-types, content-type, file size, etc.
- or setting custom headers
If these contain unvalidated user input, the application is vulnerable when used with application frameworks that cannot detect this issue.
If the application has to use user-supplied input in HTTP headers, it should check for double “\n” or “\r\n” values in the input data and eliminate it.
Many application servers and frameworks have basic protection against HTTP response splitting, but it is not adequate to task, and you should not allow unvalidated user input in HTTP headers.
But if you must have it the right order to encode is as follows:
- JS encode first
- HTML attribute encode second
Do not use eval()
When the seal function is called, the following steps are taken:
1. If Type(O) is not Object, return O.
2. Let status be Set Integrity Level( O, "sealed").
3. Return IfAbrupt(status).
4. If status is false, throw a TypeError exception.
5. Return O.
Allow-same-origin, allow-top-navigation, allow-forms, allow-scripts
DENY (prevent any domain from framing your page),
SAMEORIGIN (only allows the current site to frame your page)*** ALLOW FROM X
Set X-Frame-Options to SAMEORIGIN to stop framing and limit clickjacking. Must be added to response header because x-frame-option http request headers does nothing.
x-content-type-options: nosniffTo stop guessing of mime type, applies to IE and Chrome
Powerful mechanism for controlling which sites can execute JS, current standard.
Implement secure headers:
allow-control-allow-origin, xdomain use image
strict-transport-security, forces browser to use https, critical
cache-control: no-store, no-cache, must-revalidate, expiresz; -1 (expire in the past)
JSF output components filter output and escape dangerous characters as XHTML entities
Set the IS_SUPPORTING_EXTERNAL_ENTITIES property in xalan to FALSE:
Set the IS_SUPPORT_DTD property in xalan to FALSE:
- OWASP XSS Prevention Cheat Sheet
- XSS Prevention Rules Summary
- OWASP Cross-Site Scripting Article
- Unraveling Some Mysteries around DOM-based XSS
- ESAPI Project Home Page
- ESAPI Encoder API
- ASVS: Output Encoding/Escaping Requirements (V6)
- ASVS: Input Validation Requirements (V5)
- Testing Guide: 1st3 Chapters on Data Validation Testing
- OWASP Code Review Guide: Chapter on XSS Review
- CWE Entry 79 on Cross-Site Scripting
- Rsnake’s XSS Attack Cheat Sheet
- [XXE Cheat Sheet]
- XML Parser Evaluation
- RSPEC proposal about Java and XXE