Revision as of 21:00, 2 August 2014

Code review on HTML5

HTML5 was created to replace HTLML4, XHTML and the HTML DOM Level 2. Main purposes of this new standard is to provide dynamic content without the use of extra proprietary plugins such as Silverlight. This allows designers and developers to create exceptional sites providing a great user experience without having to install any additional plug-ins into the browser. Ideally users should have the latest web browser installed but this does not happens as regularly as security experts advice, therefore the website should implement 2 layer controls, one layer independent from Browser type, second , as an additional control.

What and where to look for in the code

Communication APIs

Web Messaging

otherWindow.postMessage(message, targetOrigin, [transfer]);

Web Messaging (also known as Cross Domain Messaging) provides a means of messaging between documents from different origins in a way that is generally safer than the multiple hacks used in the past to accomplish this task. However, there are still some recommendations to keep in mind:

• When posting a message, explicitly state the expected origin as the second argument to postMessage rather than * 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 origin attribute of the sender to verify the data is originating from the expected location.
  • Perform input validation on the data attribute of the event to ensure that it's in the desired format.
• Don't assume you have control over the data attribute. A single Cross Site Scripting flaw in the sending page allows an 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.
• To assign the data value to an element, instead of using a insecure method like element.innerHTML = data;, use the safer option: element.textContent = data;
• Check the origin properly exactly to match the FQDN(s) you expect. Note that the following code: if(message.orgin.indexOf(".owasp.org")!=-1) { /* ... */ } is very insecure and will not have the desired behavior as www.owasp.org.attacker.com will match.
• If you need to embed external content/untrusted gadgets and allow user-controlled scripts (which is highly discouraged), consider using a JavaScript rewriting framework such as Google's Caja Google Caja or check the information on sandboxed frames. Google's Caja

Many vulnerabilities are indeed patched through the implementation of proper HTTP Headers. Part of these vulnerabilities include Cross Site Scripting, Click jacking and Cross Site Forgery among others. For more info regarding these vulnerabilities, please consult the OWASP Top 10. The code reviewer must focus on looking for specific implementation of certain features and code

Clickjacking and CSRF

To avoid click jacking or Cross Site Request Forgery of the website, look for implementation of X-Frame-Options .Keep in mind that this code might not work on legacy browsers. The website http://erlend.oftedal.no/blog/tools/xframeoptions/ does a compatibility test on the browser’s x-frame-options support. For more info on Clicjacking/Jacking/Framing please refer to chapter Jacking/Framing (https://www.owasp.org/index.php/CRV2_ClientSideCodeJackingFraming)

Client Side: Disable scripts

A known client side protection on the browser is the disabling of scripts. The code should consider this scenarios and implement proper code to allow the user understand why the code does not work properly on his browser, if this is the case

<script>
document.write("Hi!")
</script>
<noscript> browser does not support JavaScript!</noscript>

Server side code implementation

Implementation of the code is also dependent on the type of web server technology used, therefore the code might be implemented in configuration files on the server side scripts (for example apache does this in the httpd.conf file). Header always append X-Frame-Options SAMEORIGIN

PHP

<?php 
header("X-Frame-Options: SAMEORIGIN"); 
?>

IIS (.NET)

<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>

Ruby On Rails

Configure config/application.rb fil with the folowing code

config.action_dispatch.default_headers.merge!({'X-Frame-Options' => 'ALLOWALL'})

Java (Spring Framework)

Add security dependencies by configuring this correctly in the pom.xml configuration file

 pom.xml 

<dependencies>
  <dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-web</artifactId>
    <version>3.2.3.RELEASE</version>
  </dependency>
  <dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-config</artifactId>
    <version>3.2.3.RELEASE</version>
  </dependency>
</dependencies>

Implementation of HTML5 Sandbox attribute

It is possible to set the sandbox attribute and this helps set restrictions on content hosted in the iframe. The value must be correctly implemented by setting an unordered unique space-separated token which are ASCII case sensitive, these are allow-forms, allow-pointer-lock, allow-popups, allow-same-origin, allow-scripts, and allow-top-navigation.

Modern browsers including Chrome, Firefox, and IE10 Platform Preview are based on the W3C IFrame Sandbox Attribute.

<iframe src="dontrtustthis.html" sandbox></iframe>

Keep in mind that these security restrictions can be easily lifted by placing allow tokens in the attributes value such as this:

<iframe src=" dontrtustthis.html" sandbox="allow-scripts allow-forms"></iframe>

For more info on correct implementation of HTML5 Sandbox code please visit http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element