All the latest versions of browsers support HTML5, therefore, the industry is at the peak of its readiness to adopt technology and adapt to it. The technology itself is designed to make it simple to include and process graphics and multimedia content on the web, without using third-party plug-ins or APIs. This article will tell about new types of attacks that HTML5 “presented” to the world.

HTML5 attacks

Attacks on CORS (Cross origin resourse sharing) - receiving a reverse shell code

To meet the growing needs of developers to make high-quality websites, HTML5 has relaxed attention to some of the limitations that were previously proclaimed by the concept of SOP (same origin policy). The concept has simple rules: scripts run on the site have access to the methods and properties of this site, but do not have such to the pages of another site (the SOP itself has an extensive separate topic, we recommend that you read it before further reading).

Now HTML5 breaks these restrictions.
')
For example, AJAX requests can run between different domains. SOP restricts JavaScript access to web page content by enforcing the following prerequisite: JavaScript and the content itself are on the same domain. Without such a restriction, a malicious website can launch a javascript that loads personal information from other sites using stored user authentication data and returns information to the attacker. So HTML5 made it possible to get data from other domains using JavaScript.

So, while xyz.com allows you to receive data, abc.com can make an AJAX request to xyz.com and read the response. This feature is used to tunnel HTTP traffic with a cross-domain call.

AJAX calls and creates the browser equivalent of a reversible shell using the simple Shell of the future tool. The tool is based on the concept that if an attacker is able to find a cross-domain query leak, he can use JavaScript stuffing (convincing the user to click on the link) and his script will run to the attacker's server via a cross-domain query. Using this flaw in the future, an attacker can view the victim’s sessions by tunneling his requests through the victim’s browser.

An important question: how is the victim session displayed for the attacker?

This is possible because the script launched by the user's browser begins to access the site of the attacker through the Cross Origin Resource (without HTML5, this would not be possible). Thus, the attacker simply tunnels his request through the victim's browser.

Stealing CSRF Tokens

With HTML5, it became possible to steal CSRF- tokens - if the token goes through a URL (for example, a GET request), using the previously named CORS rules. The attacker can inject into the CSRF-stuffing on a page that uses cross-domain queries, after which a request is made to the target site, without notifying the user. Note that for CORS, an additional HTTP header must be added, called origin . Changing the value of the attribute withCredentials to true will allow cookies to be stolen along with the request. The server header in this case should be Access-Control-Allow-Origin: * . Instead of an asterisk, you can specify the address of a specific domain or domains that are allowed to receive a response. If you leave an asterisk - the resolution will apply to all domains.

The user will not even suspect what is happening in the background. Thus, HTML5 allows you to steal CSRF tokens and perform operations without the user's knowledge.

Access to internal servers

Many commercial organizations have internal sites that are used for internal business needs. In fact, these are intranet applications that are not accessible via the Internet. Since there are many such applications, they must somehow interact with each other. And, in a hurry, most developers simply add the Access-Control-Allow-Origin: * header already known to us Access-Control-Allow-Origin: * and include CORS. This can be used by an attacker, who can use social engineering to force a company employee to click on a link, after which the attacker gets access to the content very easily.

Peculiar "step by step instructions":

1. An employee of the company is logged in on a site that is not available via the Internet.
2. The intranet server returns a request with an Access-Control-Allow-Origin: * header Access-Control-Allow-Origin: * (Why? He wants to allow other sites on the intranet to access the server data).
3. The employee receives a link from the attacker in the mail and clicks on it.
4. The site looks completely normal, the employee does not notice anything suspicious. But the site contains JavaScript code that runs in the employee’s browser.
5. The script in the background sends an XMLHttpRequest request and it also receives a request (Why? Because the server header contains Access-Control-Allow-Origin: * .
6. Javascript parsit the request and sends it to the attacker's server (easily done via XMLHttpRequest).
7. The attacker intercepts data stored on the company's internal website.

New XSS HTML5 Vectors

Developers always love to make their own custom filters in order to block XSS attacks. Most of them are blacklisted by characters such as <img, <script and so on. HTML5 introduces many new tags to support multimedia and dynamic audio / video downloads. New tags, attributes and events can, with due diligence, become potential vectors for traversing XSS filters. Below are several possible vectors that were collected from various resources:

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

Offline HTML applications cache is used by most browsers - Google Chrome, Mozilla, Opera, Safari, and so on. So, the application can cache the content in order to make it available offline. The main problem of such a cache is its vulnerability to a class of attacks called “cache poisoning”. If the JS file of a particular site is poisoned by an attacker, it can very easily get a user account. The main difference between the normal cache and the HTML5 application cache is that the first one does not allow caching all types of files, and the second one does. Using this feature, an attacker can steal user authentication data.

Let's see how an attacker can do this:

1. The user connects to an unsecured Wi-Fi network in the mall.
2. The user visits a random site.
3. The attacker responds to his request with a page that contains a hidden IFrame, designed to collect his Facebook login from the user.
4. The user's browser automatically sends a request for authorization.
5. From now on, the network is controlled by the attacker; it gives the user a page that looks exactly like the Facebook login page, with only one additional code.
6. This code will send the entered access to the attacker's site. The page also contains a command to cache this in the user's system. So, up to this point, nothing actually happened - except that the authorization page was cached in the user's system.
7. Now, after one or two days, the victim connects to a secure network at home or in the office and tries to log in to Facebook by typing a link to the site in the address bar.
8. The browser loads the fake cache login page.
9. When the user enters accesses, they are passed to the attacker, because the cached page was so programmed.

Conclusion

Thus, through the poisoning of the web application cache, an attacker can steal the user's access. These are several attacks that security experts have discovered. In the coming years, no doubt, even more HTML5-based attacks will emerge.

As a bonus, the authoritative commentary of our chief information defender, Alexei Fedorovich:

Actually, attacks on HTML5 as such are rarely used; attackers do not like to complicate the process of gaining access to confidential data; in reality, the usual compromise of mailboxes is becoming more and more important, with further recovery of passwords from the necessary resources to this box. And of course, the most favorite way of all the black-sleddies, an exact copy of the site authorization form (fake), such as Facebook or your own, located on the attacker's server.

And CSRF, XSS, SQLinj, etc. they start searching on sites only when a person is sitting on that side, and social engineering + does not help when the attacker has enough time and technical knowledge to carry out his plans. If you want to hack, hack, no options. You can only lower the threshold of penetration and at the first level weed out students with security scanners and haktulsami. Good luck.

Original article on Onextrapixel .