OWASP - User contributions [en]

PHP CSRF Guard

2012-12-06T14:05:19Z

Krzysztof Kotowicz: patched csrfguard_validate_token bypass vulnerability

=Code Snippet=

If you need to protect against CSRF attacks in your code, this little helper can reduce the risk:

session_start(); //if you are copying this code, this line makes it work.

function store_in_session($key,$value)
{
if (isset($_SESSION))
{
$_SESSION[$key]=$value;
}
}
function unset_session($key)
{
$_SESSION[$key]=' ';
unset($_SESSION[$key]);
}
function get_from_session($key)
{
if (isset($_SESSION))
{
return $_SESSION[$key];
}
else { return false; } //no session data, no CSRF risk
}

function csrfguard_generate_token($unique_form_name)
{
if (function_exists("hash_algos") and in_array("sha512",hash_algos()))
{
$token=hash("sha512",mt_rand(0,mt_getrandmax()));
}
else
{
$token=' ';
for ($i=0;$i<128;++$i)
{
$r=mt_rand(0,35);
if ($r<26)
{
$c=chr(ord('a')+$r);
}
else
{
$c=chr(ord('0')+$r-26);
}
$token.=$c;
}
}
store_in_session($unique_form_name,$token);
return $token;
}
function csrfguard_validate_token($unique_form_name,$token_value)
{
$token=get_from_session($unique_form_name);
if ($token===false)
{
return true;
}
elseif ($token===$token_value)
{
$result=true;
}
else
{
$result=false;
}
unset_session($unique_form_name);
return $result;
}

function csrfguard_replace_forms($form_data_html)
{
$count=preg_match_all("/<form(.*?)>(.*?)<\\/form>/is",$form_data_html,$matches,PREG_SET_ORDER);
if (is_array($matches))
{
foreach ($matches as $m)
{
if (strpos($m[1],"nocsrf")!==false) { continue; }
$name="CSRFGuard_".mt_rand(0,mt_getrandmax());
$token=csrfguard_generate_token($name);
$form_data_html=str_replace($m[0],
"<form{$m[1]}>
<input type='hidden' name='CSRFName' value='{$name}' />
<input type='hidden' name='CSRFToken' value='{$token}' />{$m[2]}</form>",$form_data_html);
}
}
return $form_data_html;
}

function csrfguard_inject()
{
$data=ob_get_clean();
$data=csrfguard_replace_forms($data);
echo $data;
}
function csrfguard_start()
{
if (count($_POST))
{
if (!isset($_POST['CSRFName']))
{
trigger_error("No CSRFName found, probable invalid request.",E_USER_ERROR);
}
$name =$_POST['CSRFName'];
$token=$_POST['CSRFToken'];
if (!csrfguard_validate_token($name, $token))
{
trigger_error("Invalid CSRF token.",E_USER_ERROR);
}
}
ob_start();
register_shutdown_function(csrfguard_inject);
}
csrfguard_start();

=Description and Usage=
The first three functions, are an abstraction over how session variables are stored. Replace them if you don't use native PHP sessions.

The '''generate''' function, creates a random secure one-time CSRF token. If SHA512 is available, it is used, otherwise a 512 bit random string in the same format is generated. This function also stores the generated token under a unique name in session variable.

The '''validate''' function, checks under the unique name for the token. There are three states:
* Sessions not active: validate succeeds (no CSRF risk)
* Token found but not the same, or token not found: validation fails
* Token found and the same: validation succeeds
Either case, this function removes the token from sessions, ensuring one-timeness.

The '''replace''' function, receives a portion of html data, finds all <form> occurrences and adds two hidden fields to them: CSRFName and CSRFToken. If any of these forms has an attribute or value '''''nocsrf'''''', the addition won't be performed (note that using default inject and detect breaks with this).

The other two functions, '''inject''' and '''start''' are a demonstration of how to use the other functions. Using output buffering on your entire output is not recommended (some libraries might dump output buffering). This default behavior, enforces CSRF tokens on all forms using POST method. It is assumed that no sensitive operations with GET method are performed in the application, as required by [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616].

To test this code, append the following HTML to it:

<form method='post'>
<input type='text' name='test' value='<?php echo "testing"?>' />
<input type='submit' />
</form>

<form class='nocsrf'>
</form>

=Author and License=
This piece of code is by [mailto:abbas.naderi@owasp.org Abbas Naderi Afooshteh] from OWASP under Creative Commons 3.0 License.

HTML5 Security Cheat Sheet

2011-10-19T02:32:42Z

Krzysztof Kotowicz: small additions

= Introduction =

The following cheat sheet serves as a guide for implementing HTML 5 in a secure fashion.

== Cross Origin Resource Sharing ==

*Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain.
*Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
*Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
*Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (either through <tt>*</tt> wildcard or echoing the <tt>Origin</tt> header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
*While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting sensitive information storage and their usage at run-time.

== WebDatabase ==

*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.

== Web Workers ==

*Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
*While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
*Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM Based XSS|DOM Based XSS]] vulnerability.

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

== Geolocation ==

*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the <tt>sandbox</tt> attribute of an <tt>iframe</tt> for untrusted content ==

*The <tt>sandbox</tt> attribute of an <tt>iframe</tt> enables restrictions on content within a <tt>iframe</tt>. The following restrictions are active when the <tt>sandbox</tt> attribute is set:

#All markup is treated as being from a unique origin
#All forms and scripts are disabled
#All links are prevented from targeting other browsing contexts
#All plugins are disabled

It is possible to have a [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox fine-grained control] over <tt>iframe</tt> capabilities using the value of the <tt>sandbox</tt> attribute.

== Web Messaging ==

Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:

*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format.
*Don't assume you have control over data attribute. Single [[Cross-site_Scripting_(XSS)|Cross Site Scripting]] flaw in sending page allows attacker to send messages of any given format.
*Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via eval() ) or insert it to a page DOM (e.g. via innerHTML) as that would create a DOM based XSS vulnerability. For more information see [[DOM based XSS Prevention Cheat Sheet|DOM based XSS Prevention Cheat Sheet]].

== XHR and DOM abuses ==

*XHR calls allow dynamic loading of streams into existing DOM under HTML5 framework, it can open up vulnerabilities like DOM based XSS and DOM driven open redirect and forwards. It is imperative to secure calls and streams. For more information see [[DOM based XSS Prevention Cheat Sheet]].

== HTML5 Widgets ==

*If the application allows loading of widgets within the HTML5 page structure, then it is important to make sure that they are not sharing the same DOM. Each widget should be running in its own sandbox/DOM running in separate iframe.

== Progressive Enhancements and Graceful Degradation Risks ==

*The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

Shreeraj Shah - shreeraj.shah [at] blueinfy.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-10-15T09:31:43Z

Krzysztof Kotowicz: added some points

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they relate to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but the <tt>sandbox</tt> attribute of <tt>iframe</tt>'s will be ignored in browsers except those HTML 5 compliant browsers which support it. If there are differences in implementations, there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain.
*Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
*Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
*Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (either through <tt>*</tt> wildcard or echoing the <tt>Origin</tt> header content).
*Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
*While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting sensitive information storage and their usage at run-time.

== WebDatabase ==

*Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
*If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.

== Web Workers ==

*Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
*While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
*Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval() as that could introduce a [[DOM_Based_XSS|DOM Based XSS]] vulnerability.

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

== Geolocation ==

*The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the <tt>sandbox</tt> attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==

Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:

*When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
*The receiving page should '''always''':
**Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
**Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format.
**Don't assume you have control over data attribute. Single [[Cross-Site_Scripting|Cross Site Scripting]] flaw in sending page allows attacker to send messages of any given format.<br>
*Both pages should only interpret the exchanged messages as '''data'''. Never evaluate passed messages as code (e.g. via eval() ) or insert it to a page DOM (e.g. via innerHTML) as that would create a DOM based XSS vulnerability. For more information see [[DOM_based_XSS_Prevention_Cheat_Sheet|DOM based XSS Prevention Cheat Sheet]].<span class="Apple-tab-span" style="white-space:pre" />

== XHR and DOM abuses ==

*XHR calls allow dynamic loading of streams into existing DOM under HTML5 framework, it can open up vulnerabilities like DOM based XSS and DOM driven open redirect and forwards. It is imperative to secure calls and streams. For more information see [[DOM based XSS Prevention Cheat Sheet]].

== HTML5 Widgets ==

*If the application allows loading of widgets within the HTML5 page structure, then it is important to make sure that they are not sharing the same DOM. Each widget should be running in its own sandbox/DOM running in separate iframe.

== Progressive Enhancements and Graceful Degradation Risks ==

*The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

Shreeraj Shah - shreeraj.shah [at] blueinfy.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML5 Security Cheat Sheet

2011-10-15T09:14:53Z

Krzysztof Kotowicz: filled-out webworkers section

= DRAFT CHEAT SHEET - WORK IN PROGRESS =

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they relate to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but the <tt>sandbox</tt> attribute of <tt>iframe</tt>'s will be ignored in browsers except those HTML 5 compliant browsers which support it. If there are differences in implementations, there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

* Validate URLs passed to <tt>XMLHttpRequest.open</tt>, current browsers allow these URLs to be cross domain.
* Ensure that URLs responding with <tt>Access-Control-Allow-Origin: *</tt> do not include any sensitive content or information that might aid attacker in further attacks. Use <tt>Access-Control-Allow-Origin</tt> header only on chosen URLs that need to be accessed cross-domain. Don't use the header for the whole domain.
* Take special care when using <tt>Access-Control-Allow-Credentials: true</tt> response header. Whitelist the allowed Origins and never echo back the <tt>Origin</tt> request header in <tt>Access-Control-Allow-Origin</tt>.
* Allow only selected, trusted domains in <tt>Access-Control-Allow-Origin</tt> header. Prefer whitelisting domains over blacklisting or allowing any domain (either through <tt>*</tt> wildcard or echoing the <tt>Origin</tt> header content).
* Keep in mind that CORS does not prevent the requested data from going to an un-authenticated location - it's still important for the server to perform usual [[Cross-Site Request Forgery (CSRF)|CSRF]] prevention.
* While the RFC recommends a pre-flight request with the <tt>OPTIONS</tt> verb, current implementations might not perform this request, so it's important that "ordinary" (<tt>GET</tt> and <tt>POST</tt>) requests perform any access control necessary.

== Local Storage (a.k.a. Offline Storage, Web Storage) ==
* Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
* Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting sensitive information storage and their usage at run-time.

== WebDatabase ==
* Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
* If utilized, WebDatabase content on client side can be vulnerable to SQLInjection and needs to have proper validation and parametrization.

== Web Workers ==
* Web Workers are allowed to use <tt>XMLHttpRequest</tt> object to perform in-domain and Cross Origin Resource Sharing requests. See relevant section of this Cheat Sheet to ensure CORS security.
* While Web Workers don't have access to DOM of the calling page, malicious Web Workers can use excessive CPU for computation, leading to Denial of Service condition or abuse Cross Origin Resource Sharing for further exploitation. Ensure code in all Web Workers scripts is not malevolent. Don't allow creating Web Worker scripts from user supplied input.
* Validate messages exchanged with a Web Worker. Do not try to exchange snippets of Javascript for evaluation e.g. via eval()

== WebSockets ==

* Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
* While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
* The protocol doesn't handle authorization and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
* Endpoints exposed through <tt>ws://</tt> protocol are easily reversible to plaintext. Only <tt>wss://</tt> (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
* Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
* When implementing servers, check the <tt>Origin:</tt> header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
* As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through [[Cross Site Scripting Flaw|Cross-Site-Scripting]]. Always validate data coming through WebSockets connection.

== Geolocation ==
* The Geolocation RFC recommends that the user agent ask the user's permission before calculating location, but whether or how this decision is remembered varies from browser to browser. Some user agents require the user to visit the page again in order to turn off the ability to get the user's location without asking, so for privacy reasons, it's recommended to require user input before calling <tt>getCurrentPosition</tt> or <tt>watchPosition</tt>.

== Use the <tt>sandbox</tt> attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Web Messaging ==
Web Messaging provides a means of messaging between documents from different origins in a way which is generally safer than JSON-P, however, there are still some recommendations to keep in mind:
* When posting a message, explicitly state the expected origin as the second argument to <tt>postMessage</tt> rather than <tt>*</tt> in order to prevent sending the message to an unknown origin after a redirect or some other means of the target window's origin changing.
* The receiving page should '''always''':
** Check the <tt>origin</tt> attribute of the sender to verify the data is originating from the expected location, and
** Perform input validation on the <tt>data</tt> attribute of the event to ensure it's in the desired format

== XHR and DOM abuses ==

* XHR calls allow dynamic loading of streams into existing DOM under HTML5 framework, it can open up vulnerabilities like DOM based XSS and DOM driven open redirect and forwards. It is imperative to secure calls and streams. For more information see [[DOM based XSS Prevention Cheat Sheet]].

== HTML5 Widgets ==

* If the application allows loading of widgets within the HTML5 page structure, then it is important to make sure that they are not sharing the same DOM. Each widget should be running in its own sandbox/DOM running in separate iframe.

== Progressive Enhancements and Graceful Degradation Risks ==

* The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Mark Roxbury - mark.roxberry [at] owasp.org

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

Will Stranathan - will [at] cltnc.us

Shreeraj Shah - shreeraj.shah [at] blueinfy.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML 5 Cheat Sheet

2011-09-09T10:44:15Z

Krzysztof Kotowicz:

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

*Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

== WebDatabase ==

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]

HTML 5 Cheat Sheet

2011-09-09T10:43:57Z

Krzysztof Kotowicz:

= Introduction =

= HTML 5 =

== Browser Securability Chart ==

There are a few sites charting browser capabilities as they related to the HTML 5 / CSS 3 standard. I have not seen any that mention security. There may not be a need for it, but e.g. 'sandbox' will be ignored in down browsers, but which HTML 5 compliant browsers support it. If there are differences in implementations, my assumption is that there will be differences in security configuration / settings.

== Cross Origin Resource Sharing ==

Validate URLs passed to XMLHttpRequest.open, current browsers allow these URLS to be cross domain.
*Ensure that URLs responding with Access-Control-Allow-Origin: * do not include any sensitive content or information that might aid attacker in further attacks. Use Access-Control-Allow-Origin header only on chosen URLs that need to be accessed cross-domain. Don't use that header for the whole domain.
*Take special care when using Access-Control-Allow-Credentials: true response header. Whitelist the allowed Origins and never echo back the Origin request header in Access-Control-Allow-Origin.<br>
*Allow only selected, trusted domains in Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (either through * wildcard or echoing the Origin header content).

== Input Validation ==

== Local Storage (a.k.a. Offline Storage, Web Storage) ==

== WebDatabase ==

== WebSockets ==

*Drop backward compatibility in implemented client/servers and use only protocol versions above hybi-00. Popular Hixie-76 version and olders are outdated and insecure.
*While it is relatively easy to tunnel TCP services through WebSockets (e.g. VNC, FTP), doing so enables access to these tunneled services for the in-browser attacker in case of a Cross-Site-Scripting attack. These services might also be called directly from a malicious page or program.
*The protocol doesn't handle authorisation and/or authentication. Application-level protocols should handle that separately in case sensitive data is being transferred.
*Endpoints exposed through ws:/ protocol are easily reversible to plaintext. Only wss:// (WebSockets over SSH) should be used for protection against Man-In-The-Middle attacks
*Spoofing the client is possible outside browser, so WebSockets server should be able to handle incorrect/malicious input. Always validate input coming from the remote site, as it might have been altered.
*When implementing servers, check the Origin: header in Websockets handshake. Though it might be spoofed outside browser, browsers always add the Origin of the page which initiated Websockets connection.
*As WebSockets client in browser is accessible through Javascript calls, all Websockets communication can be spoofed or hijacked through Cross-Site-Scripting. Always validate data coming through WebSockets connection.<br>

== Geolocation ==

== Use the "sandbox" attribute for untrusted content (iFrame) ==

[[http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox]]

== Content Deliverability ==

CDN or src links to foreign domains = know your content

== Progressive Enhancements and Graceful Degradation Risks ==

The best practice now is to determine the capabilities that a browser supports and augment with some type of substitute for capabilities that are not directly supported. This may mean an onion-like element, e.g. falling through to a Flash Player if the <video> tag is unsupported, or it may mean additional scripting code from various sources that should be code reviewed.

= CSS 3 =

I haven't seen any specific to CSS 3 and it's been a while since I worried about url / !import. I think privacy leaks are the most well know - e.g. querying global history using :visited (https://bugzilla.mozilla.org/show_bug.cgi?id=147777)

= Javascript and Javascript Frameworks =

Do we have cheatsheets for Javascript (e.g. use closures, protect the global namespace) or any of the frameworks like JQuery, script.aculo.us, Prototype, Mootools

= Related Cheat Sheets =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Krzysztof Kotowicz - krzysztof [at] kotowicz.net

[[Category:How_To]] [[Category:Cheatsheets]]