1999 marked the momentous introduction of HTML 4.01. Fast forward 14 years, and a lot has certainly changed since then.
We are now witnessing a very wide — albeit lively debated — adoption of HTML5 with the community split between those extremely excited about the possibilities and new UX frontiers, and the total naysayers. As always, the reality is somewhere in between.
What’s Different in HTML5
Should I develop an HTML5 website? HTML5 brings about new functions that make the web experience altogether more dynamic and interactive. The core aim behind HTML5 is to bring forward major improvements for the latest multimedia, reducing reliance on third-party plugins such as Flash, Shockwave and Silverlight.
An HTML5 website can expect to be supported by the latest browsers and mobile devices. Intended to subsume not only HTML4, but also XHTML 1 and DOM Level 2 HTML, HTML5 implements a plethora of new syntactic features such as <video>, <audio> and <canvas> elements as well as MathML and SVG elements. These new elements represent a huge leap forward giving HTML5 developers easy access to functionality without the need to learn how to interface with, and embed other components into, the HTML5 website.
In addition, HTML5 introduces some features that make the life of a web designer much easier. For example, in HTML4, we relied on JavaScript for client side input validation. The source of a standard form would look like this:
HTML4 Example:
First we need the JavaScript code for Validation:
function validateForm()
{
var x=document.forms["myForm"]["email"].value;
var atpos=x.indexOf("@");
var dotpos=x.lastIndexOf(".");
if (atpos<1 || dotpos<atpos+2 || dotpos+2>=x.length)
{
alert("Not a valid e-mail address");
return false;
}
}
Then we need the form:
<form name="myForm" action="demo_form.asp" onsubmit="return validateForm();" method="post"> Email: <input type="text" name="email"> <input type="submit" value="Submit"> </form>
HTML5 example:
<form action="demo_form.asp" autocomplete="on"> <input type="email" name="email" required placeholder="Enter a valid email address"> <input type="submit"> </form>
The same can be done on other types of fields, such as telephone numbers and URLs, simplifying client-side input validation in HTML5. The above HTML5 code includes input validation, which is by far more secure than the HTML4 version. In HTML4 everyone had to implement their own way of performing input validation.
On the other hand though, although HTML5 does try to be inherently more secure, it does leave dangerous and exploitable openings. Developers need to be aware that implementing an HTML5 website does not guarantee immunity from web vulnerabilities.
New Mark Up Language, Same Old Web Vulnerabilities
A new version or iteration of something has the tendency of providing us with a false sense of security. Same with HTML5. We seem to have expected an HTML5 website to be, by default, more secure from web vulnerabilities than its predecessor; almost immune.
This, of course, is unfortunately not the case. The motley crew of web vulnerabilities are still around. Their detection and remediation needs to form part of any web application development process.
The dangers lay within the superficial capabilities of current web vulnerability scanners in crawling an HTML5 website and web applications. Their limited understanding of the plenitude of new tags, attributes and events possible within dynamic websites means that only superficial crawling can be undertaken, leaving vulnerabilities in applications undetected.
An Example of an Inherent HTML5 Vulnerability
The HTML5 Geolocation API is used by supported browsers to locate a user’s position; allowing a website to customize the user’s experience based on their geographic position. This feature is common in various social sites for example, where users are matched based on their current geographical proximity.
This however adds another layer of complexity to HTML5 security.
What if a hacker wanted to know your location?
Using XSS vulnerabilities (which is not an HTML5-specific web vulnerability), a hacker is now able to request a user’s location from the browser. Most users would accept such a request when coming from a trusted site, allowing the attacker to know, with rather good accuracy, the location of the user.
And once the ALLOW (or Share Location) button is pressed, unless the user manually disables tracking for the site, the browser will be happy to comply with the request and continue exposing the user’s location in the future. This technique can be used to track employees’ activity in the office, allowing the attacker to get a good understanding of the topology of the company’s network. How’s that for giving hackers an extra step up!
If you are using one of the latest browsers, you can try this for yourself using the following code:
<script>
var x=document.getElementById("demo");
function getLocation()
{
if (navigator.geolocation)
{
navigator.geolocation.getCurrentPosition(showPosition);
}
else{x.innerHTML="Geolocation is not supported by this browser.";}
}
function showPosition(position)
{
x.innerHTML="Latitude: " + position.coords.latitude +
"<br>Longitude: " + position.coords.longitude;
}
</script>
So is HTML5 more dangerous than HTML4?
Whilst HTML5 does come with some security enhancements, hackers have much more accessible data that can be used to mount an attack.
A good example of this is HTML5 Local Storage, which updates the storage allowance from 4KB, the maximum size of a cookie, to 5MB per domain. That’s quite a lot of data; roughly 5 million characters. You can bet that some web developers will choose to store sensitive data in their domain’s local storage. This is a problem, because even though Local Storage is inherently more secure than using cookies, by exploiting a XSS vulnerability, a hacker can read data from the users’ local storage.
Over the last decade, the digital world has been reminded over and over again of the importance of sanitizing data, and this will remain relevant in the HTML5 era. When we opt to develop HTML5 websites and web applications, we are choosing to use an unfinished specification; and we are years away from it being ready. Having said that, HTML5 is here now and it is here to stay.
Developers need to understand and be trained that when developing an HTML5 website, they might be using specifications which are still in draft stage, meaning these might also include yet-to-be discovered vulnerabilities. Apart from that, different browsers tend to interpret and implement the rendering of pages differently. This is especially true for new technologies that are still being defined, as the browsers implement hastily the new specifications. We also cannot assume that everyone is using the latest browser updated with the latest set of security fixes. Users who do not appreciate the importance of security might choose to not update.
Therefore to answer the question, HTML4 has been around longer, tried and tested in the last decade, and any issues inherent in the specification are well known and documented. Hackers are busy identifying new and exploitable vulnerabilities introduced in HTML5. And developers are yet to understand how to completely secure it. To make things worse, the old exploits are still relevant.
HTML5 provides little protection for web vulnerabilities such as XSS, CSRF or SQL injection amongst many others. Even though the specification may seem more secure, most of the vulnerabilities available in the hackers’ arsenal continue to work on HTML5-based sites as well.
Education and prevention
It’s an accepted fact, that not enough focus is placed on security when training developers. And with the inherent dynamic nature of programming, it is pretty hard to do. We cannot expect developers to also be security experts.
We need a fall back plan. Acunetix is here to perform a leap towards combating known vulnerabilities in HTML5. With the new crawler being able to handle HTML5 with ease, Acunetix can find vulnerabilities such as XSS, SQL, Click jacking and hundreds of others.
At the same time our security researchers are totally committed to researching new vulnerabilities and building the technology to combat them.
When an interactive and dynamic user experience needs to be married with security concerns and business continuity, combating web vulnerabilities cannot be left to chance. Web vulnerability scanners that can crawl and scan modern HTML5 and JavaScript-based web applications have a very fundamental and important role to perform.
Should HTML5 be left alone until it’s more secure?
Is HTML5 simply too dangerous to take up? This question is plaguing the security industry. When it comes to companies wanting to have the best websites and deliver a top-notch user experience, this is not an option.
Acunetix believes in being forward when it comes to technology and experiences and we want our clients to be able to push the envelope in every way, whilst at the same time protecting their online assets.
For this reason Acunetix fully supports the crawling and scanning of HTML5 and JavaScript-based websites and web applications.
If you are developing with HTML5, scan your site today to ensure you are secure against known vulnerabilities.