HTML5 - a look through the security lens
HTML5 is the future standard for Internet markup language. While it is in the draft stage, but more and more of its capabilities are realized in popular web browsers. But as is usually the case, new technologies carry with them new dangers that can be successfully exploited.
Many probably already heard about the confrontation of codecs for the technology of embedding videos on the pages. With the help of the <video> tag it is supposed if not to replace, then at least to make a serious competition to Adobe Flash. Starting a conversation about HTML5, it is often remembered exactly this innovation. Still: such video hosting giants as Youtube and Vimeo have already implemented support for the new technology. And Apple's mobile products, in which there was no official support for Flash, and most likely will not, are already actively using it. So the streaming video inserted into the page using the <video> tag is something that you can feel right now.
Among the other "goodies" that HTML5 offers are the following:
It is not surprising that with the advent of the era of web applications (such as Gmail), there is a need to store data arrays on the side of a web browser. A striking example of this is the attempt to make working with such web applications offline. In this, Google has achieved great success with its technology Google Gears. Cookies with their limits (especially in 4KB size) and methods of working with them are clearly inappropriate and outdated solutions for such tasks. For this reason, it was decided to develop a new mechanism, similar to the cookies, but devoid of their shortcomings. They became the technology and WebStorage. In 2 words, thanks to HTML5, we now have a repository (or rather two repositories) of the “key-value” form on the side of a web browser with access from JavaScript:
')
Let's look at the security side of this technology. Like much in the JS API in HTML5, it is subject to the HTML5 Origin mechanism, that is, data is available for all pages on the same domain, taking into account the protocol and port number (for example, example.com : 80). As noted above, the web storage is free of the 4KB limit and the specification recommends using 5 MB per domain. In fact, for Firefox, Safari, Opera, Google Chrome, the limit is 5MB, for IE - 10MB. But the most interesting thing is not the quota itself, but how the browser uses them.
For example, Firefox has a limit on .example.com. Thus, (and here attention!) One subdomain can completely take the place reserved for the domain:
Not without the omnipresent null-byte. In this web browser, inserting a null byte into the localStorage key causes Firefox to be “forgetful”. In other words, the place, although only 1B is occupied, but the web browser does not take it into account. "A trifle, but nice" (c).
Go ahead. Google Chrome is trying to be more stringent on domain restrictions and the entire domain is taken into account in calculating the limit. But at the same time in Google Chrome, you can take in general * all * your disk space by creating a bunch of i-frames on the wildcard-domain, in which you can take 5 MB each!
This bug is still not fixed. Among other things, old problems migrated from the cooks to a new kind of storage, including:
It is also worth noting another important feature of the web storage - in contrast to cookies to the server, nothing is transmitted within the framework of the usual HTTP requests. Data is available only from the web browser through the JS API. As well as other technologies that transfer most of the work of a web application to the side of a web browser, this increases the risks from traditional XSS vulnerabilities. And if cookies were stolen before, now there is a great chance to steal more “tasty” data, and in 5 MB you can fit them a lot! For session cookies, however, it was possible to severely reduce their accessibility with JavaScript using the HTTPOnly attribute, which is good. But for WebStorage such mechanisms are not provided, and access will be complete.
If we are talking about data storage, we recall and even more advanced tool - web SQL database right in the browser! Let it and SQLite, but this is not bad! We will not consider in detail the rather specific syntax of query execution to the database, but rather consider the following code immediately, which should simply output information about the book by its ID:
What happens if you go to an address like the following?
We get DOMXSS + SQL injection! It is a pity that the possibilities for using this vulnerability are quite small (by the way, Oxod wrote a good article about injections in SQLite, look for the link below). Especially considering that both Opera and Chrome are stored in separate sqlite-database files for sites. Of course, the authors have foreseen the possibility and recommend performing “secure” parameterized SQL queries. But let's see how the developers will follow their advice. Among other things, web SQL databases are characterized by the same problems as localStorage and sessionStorage.
In HTML5, new tags and attributes were added - this means that it’s time to update your WAF rules / signatures (we wrote in detail about firewalls for web applications in the article “Last minute walls of protection” in # 10/2009 issue] [). One of the new markup elements is the autofocus attribute. This is a long-awaited attribute, because as before, almost all the time I had to do JavaScript-processing of autofocus. And in HTML5, finally, they added an attribute for autofocusing on a certain text field. But let's imagine using this attribute as a way to automatically execute code:
This technique can be useful, for example, when angle brackets are filtered. The <video> tag that we recalled today carries, besides the multimedia functions itself, the ability to execute JavaScript code (who would have thought :) through the poster attribute:
The "merit" of <video> can also be attributed to the ability to accurately identify the web browser. It will be another reception in the piggy bank Metasploit Decloak . Examples with newer elements can be continued. How do you, for example, use JavaScript to execute an onscroll tag handler and the same autofocus attribute?
Or another trick, though it works so far only in the latest versions of Opera:
In addition to new tags and attributes, HTML5 pays great attention to the interaction of web applications with the user and added a large number of input text field types: datetime, datetime-local, date, month, time, week, number, range, email, url, search, tel color. They are designed to add more meaning to ordinary text fields. So for the date field it will be possible to conveniently select a date without resorting to using ready-made calendars in JavaScript. No more bother with the text-stub. In general, finally, there will be more convenient and context-appropriate input tools.
What is important from a security point of view is that the fields will validate themselves!
On the one hand, hurray - you no longer need to write regulars for RFC (although no one takes this right away from you, since the special attribute pattern has been added) and bother with JavaScript checks before sending the form data to the server. On the other hand, we should not forget about the validation on the server side of the web application! Strangely enough, but practice shows that even now there are cases when server checks are forgotten or implemented insufficiently strictly. Checking on the side of a web browser, as you understand, is certainly not worth trusting. Especially "zamylitsya eye" may be in the development of AJAX-part of modern web applications. And that's what I fear: if this validation is simplified even more, then how would the developers forget about it at all!
Web browsers for security reasons limit the interaction (access and data exchange) of client parts of web applications hosted on different domains. Despite the fact that the restriction seems to be really necessary from the point of view of security, interdocument interaction in some cases is often necessary. For example, this may be relevant for widget technologies. The system of inter-document messages allows (ideally) a secure way to share data with documents hosted on different domains, and at least Firefox, Google Chrome is supported.
Consider how this mechanism works. Let the site (or rather, its client part) example.com/index.html want to interact with foo.com/iframe.html, which is loaded in an iframe. In this case, the "recipient" of messages is initialized on foo.com. The code of the recipient of messages on foo.com:
Pay attention to an explicit sender check (e.origin). But even with such a check, we must not forget to validate the incoming data in case that a sender suddenly finds, say, XSS. And in the document (client side) a.example.com we send a message to the recipient:
Here it is important to explicitly specify the recipient of the targetOrigin message. Even despite the fact that the standard provides the ability to specify "*" and thereby allow sending messages to any addressee. IMHO, the main risk in this mechanism is in the initial complexity of the secure messaging implementation. A developer needs to clearly understand what he is doing. TV set risk elementary forget about the sender check. It may be dangerous to "blindly" use incoming data, which will lead to the rebirth of DOM-based XSS.
Current location is a rather important aspect of privacy (“privacy”), therefore, it is necessary to implement the mechanisms for determining it with great care. This aspect is described in the “Security and privacy considerations” section of the W3C specification. In a nutshell, the specification states that the location must be explicitly allowed by the site visitor. Technically, this is implemented by calling the special method of the navigator.geolocation object.
In all popular browsers (with the exception of MS Internet Explorer, in which the Geolocation API is simply not implemented), when logging into a page that uses gelocation, a warning about collecting information is displayed and permission is asked from the user. At the same time, it is possible to remember your choice and / or place the site on a white or black list. It is important that this takes into account the site domain, not including the full path to the script ...
During positioning, a web browser collects data about your IP address, the closest wireless access points and possibly other similar information (for example, a random client ID assigned by Google that expires in 2 weeks) and sends it all to the location service . And now, paranoid brothers, guess who will be this very service in a large number of cases (Google Chrome, Firefox, Opera) ?! Right, Google Location Services! Of course, we are promised that:
“Neither Mozilla nor Google will ever use the information collected by Google Location Services to identify you and will never spy on you.”
But we know that no one can be trusted! :) You should also pay attention to the sad consequences that XSS will bring on the site allowed for collecting coordinates.
I would like to hope that the developers of web applications, who have been taught by bitter experience, will not only rush to implement all the really interesting and necessary HTML5 chips, but also study the Security sections of the corresponding specifications. He is glad that various tools for pentesters, including the W3AF, which is a powerful and free framework for conducting web application security audits, are not far behind the progress. Your humble servant is one of the participants in this project and we have already added modules to search for places to use WebStorage and other risky sections of code. So at the next site security audit you can determine if HTML5 chips are used there :).
Taras "oxdef" Ivaschenko
Dmitry "Invent" Sidorov
Subscribe to "Hacker"
HTML5: short summary
Many probably already heard about the confrontation of codecs for the technology of embedding videos on the pages. With the help of the <video> tag it is supposed if not to replace, then at least to make a serious competition to Adobe Flash. Starting a conversation about HTML5, it is often remembered exactly this innovation. Still: such video hosting giants as Youtube and Vimeo have already implemented support for the new technology. And Apple's mobile products, in which there was no official support for Flash, and most likely will not, are already actively using it. So the streaming video inserted into the page using the <video> tag is something that you can feel right now.
Among the other "goodies" that HTML5 offers are the following:
- “Offline” data storage in the browser - web storage, local databases;
- Canvas 2D API;
- Cross Domain Interaction (Cross Domain Messaging);
- "Drag-and-drop" -functional;
- Work with the network using web sockets;
- Geolocation
Web storage is a powerful alternative to cookies
It is not surprising that with the advent of the era of web applications (such as Gmail), there is a need to store data arrays on the side of a web browser. A striking example of this is the attempt to make working with such web applications offline. In this, Google has achieved great success with its technology Google Gears. Cookies with their limits (especially in 4KB size) and methods of working with them are clearly inappropriate and outdated solutions for such tasks. For this reason, it was decided to develop a new mechanism, similar to the cookies, but devoid of their shortcomings. They became the technology and WebStorage. In 2 words, thanks to HTML5, we now have a repository (or rather two repositories) of the “key-value” form on the side of a web browser with access from JavaScript:
- localStorage - for long-term data storage;
- sessionStorage - for session use.
')
<p> <span id="count">- </span> .</p> <script> if (!localStorage.pageLoadCount) localStorage.pageLoadCount = 0; localStorage.pageLoadCount += 1; document.getElementById('count').textContent = localStorage.pageLoadCount; </script> Let's look at the security side of this technology. Like much in the JS API in HTML5, it is subject to the HTML5 Origin mechanism, that is, data is available for all pages on the same domain, taking into account the protocol and port number (for example, example.com : 80). As noted above, the web storage is free of the 4KB limit and the specification recommends using 5 MB per domain. In fact, for Firefox, Safari, Opera, Google Chrome, the limit is 5MB, for IE - 10MB. But the most interesting thing is not the quota itself, but how the browser uses them.
For example, Firefox has a limit on .example.com. Thus, (and here attention!) One subdomain can completely take the place reserved for the domain:
// Firefox 3.6.8 for (var i = 0; i < 100; i++) { try { localStorage.setItem(rand(1, 10000).toString() + 'foo'+i.toString(), 'AA...AA'+i.toString()); } catch (e) { alert(i.toString()+'|'+e);break; } } Not without the omnipresent null-byte. In this web browser, inserting a null byte into the localStorage key causes Firefox to be “forgetful”. In other words, the place, although only 1B is occupied, but the web browser does not take it into account. "A trifle, but nice" (c).
Go ahead. Google Chrome is trying to be more stringent on domain restrictions and the entire domain is taken into account in calculating the limit. But at the same time in Google Chrome, you can take in general * all * your disk space by creating a bunch of i-frames on the wildcard-domain, in which you can take 5 MB each!
for(var i=0; i<10; i++) { var iframe = document.createElement('iframe'); iframe.src = 'http://'+randomString()+'.example.com/ddos.html'; document.body.appendChild(iframe); } This bug is still not fixed. Among other things, old problems migrated from the cooks to a new kind of storage, including:
- user tracking;
- DNS spoofing attack.
It is also worth noting another important feature of the web storage - in contrast to cookies to the server, nothing is transmitted within the framework of the usual HTTP requests. Data is available only from the web browser through the JS API. As well as other technologies that transfer most of the work of a web application to the side of a web browser, this increases the risks from traditional XSS vulnerabilities. And if cookies were stolen before, now there is a great chance to steal more “tasty” data, and in 5 MB you can fit them a lot! For session cookies, however, it was possible to severely reduce their accessibility with JavaScript using the HTTPOnly attribute, which is good. But for WebStorage such mechanisms are not provided, and access will be complete.
SQL injection in web browser
If we are talking about data storage, we recall and even more advanced tool - web SQL database right in the browser! Let it and SQLite, but this is not bad! We will not consider in detail the rather specific syntax of query execution to the database, but rather consider the following code immediately, which should simply output information about the book by its ID:
function showById() { var pos = document.URL.indexOf("book=")+5; var bookId = document.URL.substring(pos,document.URL.length); var author = ''; var title = ''; db.transaction(function(tx) { tx.executeSql("SELECT * FROM books WHERE id = " + bookId, [], function(tx, result){ if ( result.rows.length > 0) { document.getElementById('bookAuthor').textContent =result.rows.item(0)['author']; document.getElementById('bookTitle').textContent = result.rows.item(0)['title']; } }, function(tx, error){}); }); } What happens if you go to an address like the following?
target.com/html5/websql.html?book=1/**/AND/**/1=2We get DOMXSS + SQL injection! It is a pity that the possibilities for using this vulnerability are quite small (by the way, Oxod wrote a good article about injections in SQLite, look for the link below). Especially considering that both Opera and Chrome are stored in separate sqlite-database files for sites. Of course, the authors have foreseen the possibility and recommend performing “secure” parameterized SQL queries. But let's see how the developers will follow their advice. Among other things, web SQL databases are characterized by the same problems as localStorage and sessionStorage.
New tags and attributes - update IDS and WAF signature databases
In HTML5, new tags and attributes were added - this means that it’s time to update your WAF rules / signatures (we wrote in detail about firewalls for web applications in the article “Last minute walls of protection” in # 10/2009 issue] [). One of the new markup elements is the autofocus attribute. This is a long-awaited attribute, because as before, almost all the time I had to do JavaScript-processing of autofocus. And in HTML5, finally, they added an attribute for autofocusing on a certain text field. But let's imagine using this attribute as a way to automatically execute code:
<input onfocus=alert(1) autofocus> <input onblur=write(1) autofocus><input autofocus> This technique can be useful, for example, when angle brackets are filtered. The <video> tag that we recalled today carries, besides the multimedia functions itself, the ability to execute JavaScript code (who would have thought :) through the poster attribute:
<video poster=javascript:alert(1)// <video><source onerror="javascript:alert(1)"> The "merit" of <video> can also be attributed to the ability to accurately identify the web browser. It will be another reception in the piggy bank Metasploit Decloak . Examples with newer elements can be continued. How do you, for example, use JavaScript to execute an onscroll tag handler and the same autofocus attribute?
<body onscroll=alert(1)><br><br><br>...<br><input autofocus> Or another trick, though it works so far only in the latest versions of Opera:
<form id="test" /><button form="test" formaction="javascript:alert(1)"> New types of form fields
In addition to new tags and attributes, HTML5 pays great attention to the interaction of web applications with the user and added a large number of input text field types: datetime, datetime-local, date, month, time, week, number, range, email, url, search, tel color. They are designed to add more meaning to ordinary text fields. So for the date field it will be possible to conveniently select a date without resorting to using ready-made calendars in JavaScript. No more bother with the text-stub. In general, finally, there will be more convenient and context-appropriate input tools.
<style> [required] { background-color: green; } :invalid { background-color: red; } </style> … <input name="email" type="email"/> What is important from a security point of view is that the fields will validate themselves!
Validation of data in forms
On the one hand, hurray - you no longer need to write regulars for RFC (although no one takes this right away from you, since the special attribute pattern has been added) and bother with JavaScript checks before sending the form data to the server. On the other hand, we should not forget about the validation on the server side of the web application! Strangely enough, but practice shows that even now there are cases when server checks are forgotten or implemented insufficiently strictly. Checking on the side of a web browser, as you understand, is certainly not worth trusting. Especially "zamylitsya eye" may be in the development of AJAX-part of modern web applications. And that's what I fear: if this validation is simplified even more, then how would the developers forget about it at all!
Cross-document messaging
Web browsers for security reasons limit the interaction (access and data exchange) of client parts of web applications hosted on different domains. Despite the fact that the restriction seems to be really necessary from the point of view of security, interdocument interaction in some cases is often necessary. For example, this may be relevant for widget technologies. The system of inter-document messages allows (ideally) a secure way to share data with documents hosted on different domains, and at least Firefox, Google Chrome is supported.
Consider how this mechanism works. Let the site (or rather, its client part) example.com/index.html want to interact with foo.com/iframe.html, which is loaded in an iframe. In this case, the "recipient" of messages is initialized on foo.com. The code of the recipient of messages on foo.com:
<div id="msg">...</div><script> window.addEventListener('message', receiver, false); function receiver(e) { if (e.origin != 'http://example.com') { return; } document.getElementById('msg').innerHTML = 'Origin: ' + e.origin + ' From: ' + e.source + ' Data: ' + e.data; } </script> Pay attention to an explicit sender check (e.origin). But even with such a check, we must not forget to validate the incoming data in case that a sender suddenly finds, say, XSS. And in the document (client side) a.example.com we send a message to the recipient:
function postMsg() { var o = document.getElementById('ifra'); o.contentWindow.postMessage(document.getElementById('msg').value, 'http://foo.com/'); return false; } Here it is important to explicitly specify the recipient of the targetOrigin message. Even despite the fact that the standard provides the ability to specify "*" and thereby allow sending messages to any addressee. IMHO, the main risk in this mechanism is in the initial complexity of the secure messaging implementation. A developer needs to clearly understand what he is doing. TV set risk elementary forget about the sender check. It may be dangerous to "blindly" use incoming data, which will lead to the rebirth of DOM-based XSS.
Positioning
Current location is a rather important aspect of privacy (“privacy”), therefore, it is necessary to implement the mechanisms for determining it with great care. This aspect is described in the “Security and privacy considerations” section of the W3C specification. In a nutshell, the specification states that the location must be explicitly allowed by the site visitor. Technically, this is implemented by calling the special method of the navigator.geolocation object.
if (navigator.geolocation) { navigator.geolocation.getCurrentPosition(function(position) { var lat = position.coords.latitude; var lng = position.coords.longitude; var options = {position: new google.maps.LatLng(lat, lng) } var marker = new google.maps.Marker(options); marker.setMap(map); }); } In all popular browsers (with the exception of MS Internet Explorer, in which the Geolocation API is simply not implemented), when logging into a page that uses gelocation, a warning about collecting information is displayed and permission is asked from the user. At the same time, it is possible to remember your choice and / or place the site on a white or black list. It is important that this takes into account the site domain, not including the full path to the script ...
During positioning, a web browser collects data about your IP address, the closest wireless access points and possibly other similar information (for example, a random client ID assigned by Google that expires in 2 weeks) and sends it all to the location service . And now, paranoid brothers, guess who will be this very service in a large number of cases (Google Chrome, Firefox, Opera) ?! Right, Google Location Services! Of course, we are promised that:
“Neither Mozilla nor Google will ever use the information collected by Google Location Services to identify you and will never spy on you.”
But we know that no one can be trusted! :) You should also pay attention to the sad consequences that XSS will bring on the site allowed for collecting coordinates.
Finally
I would like to hope that the developers of web applications, who have been taught by bitter experience, will not only rush to implement all the really interesting and necessary HTML5 chips, but also study the Security sections of the corresponding specifications. He is glad that various tools for pentesters, including the W3AF, which is a powerful and free framework for conducting web application security audits, are not far behind the progress. Your humble servant is one of the participants in this project and we have already added modules to search for places to use WebStorage and other risky sections of code. So at the next site security audit you can determine if HTML5 chips are used there :).
Useful links:
- Website from Google about HTML5
- HTML Specifications
- "HTML5 Security Cheatsheet"
- HTML 5 Security by Frank Ruske
- "Dive into html5" by Mark Pilgrim
- The article "Injection, lungs on the rise exploit injections in SQLITE" by Oxod
Taras "oxdef" Ivaschenko
Dmitry "Invent" Sidorov
Subscribe to "Hacker"
Source: https://habr.com/ru/post/108901/
All Articles