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.
CORS (Cross Origin Resource Sharing) Attacks – Obtaining a Reverse Shell
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.
- An internal employee logs into the site which is not accessible over the internet.
- 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)
- The employee receives a link in mail and clicks on it.
- 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 )
- The Java Script parses the response and sends it back to the attacker’s server. (can be done easily through XMLHttpRequest )
- 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
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.
- The user connects to an unsecured Wi-Fi network in a shopping mall.
- The user browses to a random site.
- The attacker responds to this request with a page, and this page contains a hidden iframe pointed to say Facebook login.
- So the user’s browser will automatically send a request to the Facebook login page.
- 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.
- 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.
- The browser will now load the fake login page from the cache.
- 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.