HTML5 Attacks: What You Need to Know

HTML5 Attacks: What You Need to Know

HTML5 is one of the promising new key technologies that powers the web. Though it is still under development, HTML5 is high in demand especially given the fact that the use of smart phones and internet enabled mobile devices is growing exponentially every year. HTML, the heart of the web, has made big advances with HTML5 by providing support for latest multimedia and server communication.

All the latest versions of browsers have their support for HTML5 and hence the industry is on a high to embrace this technology and get adapted to it soon. The features are designed to make it easy to include, and handle multimedia and graphical content on the web without having to use any third-party plug-ins or APIs. This article aims to cover various new kinds of attacks that HTML5 brings to the world of web especially with CORS and other new implementations.

HTML5 Attacks: What You Need to Know

HTML5 Attacks

CORS (Cross Origin Resource Sharing) Attacks – Obtaining a Reverse Shell

To address the growing needs of developers to build high quality sites, HTML5 has relaxed some of the restrictions which were placed earlier by the SOP (Same Origin Policy). Same Origin Policy stated in simple terms is as follows: It allows scripts running on pages originating from the same site to access each other’s methods and properties, but prevents access to methods and properties across pages on different sites. (SOP is itself a huge topic, and it’s recommended to go through it first). Now HTML5 breaks these restrictions. For instance, Ajax requests can be made across different domains. Same Origin Policy made sure that in order for JavaScript to access the contents of a web page, both the JavaScript and the web page must originate from the same domain. Without the SOP, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client’s credentials and communicates it back to the attacker. So HTML5 makes it possible for JavaScript to access data across domains.

So as long as allows it, can make Ajax calls to and can read the response. This feature has been exploited to tunnel HTTP traffic over a cross domain. Ajax calls, and sets‐up a browser equivalent of a reverse shell as demonstrated by Lava Kumar (all the credit goes to him) with a simple tool named ‘Shell of the future’. The tool is based on the concept that if an attacker is able to find a cross site scripting flaw in a site, he can execute a JavaScript payload (by convincing a user to click on a link) and this script talks to the attacker’s server through Cross Origin Requests. Exploiting this further, the attacker can browse the victim’s session by tunneling his requests through the victim’s browser.

Important Question: How is the victim’s session displayed to the attacker?
This is possible because the script which is loaded by the user’s browser, starts talking to the attacker’s site using COR (Without HTML5 that wouldn’t have been possible). So the attacker is just tunneling his request through the victim’s browser.

Stealing CSRF Tokens

With HTML5, it is possible to steal CSRF tokens. If the CSRF token goes in the URL (i.e. in GET request) then, taking advantage of the earlier description of CORS. An attacker can inject a CSRF payload on a cross domain page that triggers a request to the target site, without the user noticing it. Please note that for CORS to be enabled an extra HTTP header called ‘origin’ needs to be added. Setting the attribute “withCredentials” to ‘true’ will replay the cookies along with the request. Access-Control-Allow-Origin: * will precisely be the response header.

The user has no idea that all this has happened in the background. Thus in HTML5, you can steal CSRF tokens and execute the operations without the user noticing a thing.

Accessing Internal Servers

Many corporate companies have internal sites which are used to handle the internal requirements of employees. They are generally intranet applications and not accessible over the internet. Since there are many different internal applications, all related to the employees, they might have the need to interact with one another. So most of the developers, in a rush to provide rich functionality, add the below header Access-Control-Allow-Origin: * and enable the CORS to take advantage of it. This can be very well exploited by an attacker who can use social engineering to make an internal employee click on a link and then he can access the content very easily. Below are the steps to execute the same.

  1. An internal employee logs into the site which is not accessible over the internet.
  2. Intranet Server returns the response with a header set as Access-Control-Allow-Origin: * (Why? He wants to allow other sites in the intranet to access the data from this server)
  3. The employee receives a link in mail and clicks on it.
  4. This site contains normal UI stuff so the internal user doesn’t notice a thing. But it contains a JavaScript code which will be executed in the user’s browser.
  5. The Java Script silently sends an XMLHttpRequest in the background and it can access the response too. (Why? Because the header Access-Control-Allow-Origin: * is set )
  6. The Java Script parses the response and sends it back to the attacker’s server. (can be done easily through XMLHttpRequest )
  7. Thus the attacker gets hold of the data present in the internal site of the company.

New XSS HTML 5 Vectors

Developers always like to develop their own custom filters in order to block XSS attacks. Most of them involve black listing the characters like <img , <script etc. HTML5 introduces many new tags to extend the multimedia support and to allow dynamic loading of audio and video tags. New tags, attributes and events have been introduced and if carefully crafted can become potential vectors to bypass XSS filters. Below are some of the possible vectors that I have gathered so far from various sources.

List of XSS vectors for HTML5

<video> <source onerror="javascript:alert(1)">
<video onerror="javascript:alert(1)"><source>
<audio onerror="javascript:alert(1)"><source>
<input autofocus onfocus=alert(1)>
<select autofocus onfocus=alert(1)>
<textarea autofocus onfocus=alert(1)>
<keygen autofocus onfocus=alert(1)>
<button form=test onformchange=alert(2)>X
<form><button formaction="javascript:alert(1)">

Offline Web Application Cache Poisoning

HTML offline Application cache has been implemented by most browsers – Google Chrome, Mozilla, Opera, and Safari etc. So an application can cache the content for the user to make use of it offline. The main problem with these caches is that they are susceptible to an attack called ‘Cache Poisoning’. If the JS file of a particular site is poisoned the attacker can very well take control of the user account. The main difference between normal cache and the application cache in HTML5 is that the former does not allow you to cache all the files, while the later allows you to cache any file. By exploiting this feature an attacker can steal the credentials of a legitimate user. So let’s see how an attacker can take advantage of this and steal the user credentials.

  1. The user connects to an unsecured Wi-Fi network in a shopping mall.
  2. The user browses to a random site.
  3. The attacker responds to this request with a page, and this page contains a hidden iframe pointed to say Facebook login.
  4. So the user’s browser will automatically send a request to the Facebook login page.
  5. Since the network is controlled by the attacker, he serves a page which looks exactly like the Facebook login page but with some additional code. This code would basically send the entered credentials to the attacker’s site. Also, the page contains tags to cache this in the user’s system (by including the manifest attribute in the HTML). So nothing actually happened till this moment except that the Facebook login page is cached in the user’s system.
  6. Now the victim, after a day or two connects to a secured network at his home or office, and tries to login to Facebook by typing the Facebook link.
  7. The browser will now load the fake login page from the cache.
  8. When the user enters the credentials, they are transported to the attacker simply because the cached page is designed that way.


Thus by poisoning the application cache an attacker can steal the credentials of a legitimate user. These are some of the attacks which are unearthed so far by the security researcher. In the coming years surely more variety of attacks will emerge exploiting other features present in HTML5.

Rohit is a certified ethical hacker who works as an Information Security Consultant. He is experienced in penetration testing, social engineering, password cracking and malware obfuscation.

Leave a Reply

Your email address will not be published. Required fields are marked *


Iconfinder Coupon Code and Review

Iconfinder offers over 1.5 million beautiful icons for creative professionals to use in websites, apps, and printed publications. Whatever your project, you’re sure to find an icon or icon…

WP Engine Coupon

Considered by many to be the best managed hosting for WordPress out there, WP Engine offers superior technology and customer support in order to keep your WordPress sites secure…

InMotion Hosting Coupon Code

InMotion Hosting has been a top rated CNET hosting company for over 14 years so you know you’ll be getting good service and won’t be risking your hosting company…

SiteGround Coupon: 60% OFF

SiteGround offers a number of hosting solutions and services for including shared hosting, cloud hosting, dedicated servers, reseller hosting, enterprise hosting, and WordPress and Joomla specific hosting.