Security Issues in HTML 5

Sara Toufiq (2011-MS-CS-23)Wasif Altaf (2011-MS-CS-19)

Introduction• Technological changes to HTML 4.0 giving rise to

many existing and new security threats and vulnerabilities

• Security is an important part of HTML 5 specifications from initial

• HTML 5 provides us with rich features, with additional tags and enhanced functionality

• Exploitation scenarios have not changed in HTML 5 with some exceptions an attacker can do multiple attacks with new features of HTML 5

Vulnerabilities• Cross-site Request Forgery (CSRF)• Cross-site Scripting (XSS)• Clickjacking• Local Storage• Geolocation API

Cross-site Request Forgery (CSRF)

• According to (Zeller and Felten, 2008) Cross-Site Request Forgery attacks occur when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site.

• (Jeremiah Blatz, 2011) described that CSRF takes advantage of the inherent statelessness of the web to simulate user actions on one website (the target site) from another website (the attacking site).

Review of Literature (CSRF)• Adam Barth et al. 2008 presented and analyzed defense

mechanisms against cross-site requests forgery. Researchers proposed defense mechanisms against CSRF attacks (Login CSRF attacks), third-party content vulnerability, and they also recommended usage of HTTPS. Mainly, they proposed Origin header to be used for all state modifying requests (such as Login and other form submissions) lodged over HTTP POST request method. Through Origin header it can be ensured that authenticated sites’ lodged requests are entertained only, and hence the requests from attackers are not fulfilled. They advised that Origin header be used over HTTPS by secure websites such as banks and other financial organizations in their web applications. As a future work they proposed to extend the capabilities of Origin header within frame hierarchy.

Review of Literature (CSRF)• Devdatta akhawe et al 2010, discussed CSRF in reference to

XMLHttpRequest API and HTML5 form element. They discussed that HTML5 form elements generate GET & POST requests that may lead to CSRF attack. These requests can be sent to any origin but contain certain methods and headers. There is great chance of CSRF attack by using XMLHttpRequest API and HTML 5 form elements as these requests be sent based on data in user’s cookies and the response are interpreted by user’s browser. They proposed solution by first checking session integrity by “cause” of each Http Request. When a request is generated, the session should be checked whether the request is from trusted user or not by adding origin header. If the header is not set, then there is chance that the request is sent to attacker’s server by a POST request. The attacker can redirect the request back to original header as origin header lists original source which violates session integrity. The solution to this vulnerability proposed by them is naming all origins in redirect chain in origin header. The problem with this solution is that naming can be done up to a certain limit otherwise it would lead to server loading, with time and performance issues.

Review of Literature (CSRF)• Devdatta akhawe et al 2010 (Continues), The other solution is to

use pre-flight request as subtype of HttpRequest by using CORS that includes number of headers and named as CORSResponse header which leads pre-flight requests to attacker’s site. This is done as HTML5 allows CORS and now browsers contain open redirectors and does not manage whitelists. These attacks occur when a user requests a page from target website by following link from another website with some input. The solution to this problem proposed is to use referrer header. By using referrer header, CSRF attack can be controlled if the site’s origin in referrer header is not from trusted user or request is redirected to gateway. But if server sends request to attacker’s server first (attacker injects some malicious hyperlink) then it leads to CSRF attack. This can be controlled by setting referrer header as no-referrer in requests but still there is possibility to this attack. The flaw in this solution is open redirectors which allow every request to be entertained, including requests which should otherwise be discarded.

Review of Literature (CSRF)• Jeremiah Blatz, 2011, But again, we cannot

depend totally on fact that referer header will go with each request. The fact is that some browsers never send referer header, others send oftenly. There is also possibility that proxy servers strip out this header. So, there is still possibility of CSRF attack.

Review of Literature (CSRF)• Robert McArdle 2011, described that XMLHttpRequest is very

common API used in applications specially those websites that make AJAX calls like Gmail, Facebook and Google Maps. Before HTML5, these requests were made only in Same Origin Policy (SOP). HTML5 overcomes this situation and provides a method called Cross Origin Resource Sharing (CORS), which enable users to make XMLHttpRequest throughout the world by adding “Access-Control-Allow-Origin” header in response which itself gives rise to CSRF attack. As HTML5 allows cross origin requests, so by default the response header allows all cross origin requests even if the user doesn’t set it. This is gap from where attacker can inject some malicious code to victim’s website. When a victim visits that site, the malicious code makes a cross domain call to attacker’s site establishing a two-way communication with attacker’s server through cross domain calls and would be able to send commands using victim’s browser.

Review of Literature (CSRF)• Shreeraj Shah, 2012 explained CSRF as silent attack over browser

by HTML5 Cross Origin Resource Sharing method (CORS). He described that a CSRF attack can be injected through a payload on cross domain page by a request without knowledge of victim. He explained ‘CORS’ as a ‘blind response’ technique that is controlled by extra HTTP header ‘origin’ that hit the target establishing a CSRF vector using XHR – Level 2 on HTML5 pages. XHR establishes a connection using POST method with attribute ‘withCredentials’ set to true which allows cookies to be replayed for CSRF attack without knowledge of user. XHR – Level 2 calls embedded in HTML5 browser can open cross domain socket and send Http Request. Browser would go for preflight requests to check policy and allow cookie replay if ‘withCredentials’ set to true that would lead towards critical business logic functionalities to be exploited like file uploads on facebook, invoices, contacts etc.

Review of Literature (CSRF)• De Ryck et al. 2012 analyzed emerging web

standards in detail from security point of view. They undertook analysis of HTML 5 specifications as well as implementation by major web browsers, and identified 45 security issues. They revealed that through injection of submission controls provided by HTML 5 hidden security tokens from forms can be stolen. As per (Zeller and Felten, 2008) the de facto step against CSRF attack is the use of a unique token to authenticate future requests. Since hidden security tokens can be stolen using injection of submission controls so CSRF attacks are still probable.

Cross-site Scripting (XSS)• Iha and Doi, 2009 stated that, Cross-site scripting

attack is a technique which injects a malicious dynamic executable code prepared by an attacker into a user's web browser via vulnerable web applications. Typically, the malicious code is written in the language that can be executed dynamically on the web browser (e.g. Java- Script). As the result of the attack to the user's web browser by using the vulnerable web application, the attacker can force the execution of the malicious code into the user's web browser by avoiding the restrictions in the same origin policy.

Clickjacking• As of Balduzzi et al. 2010, A malicious page

constructed such that it tricks victims into clicking on an element of a different page that is only barely (or not at all) visible. By stealing the victim’s clicks, an attacker could force the user to perform an unintended action that is advantageous for the attacker (e.g., initiate an online money transaction).

Review of Literature (Local

Storage)• Robert McArdle, 2011, described that HTML5

provides a very useful feature of local storage to save persistent data on user’s system. It allows the information to store as key pairs and can be easily retrieved even through event handlers and javascript. If developers store sensitive information in local storage then attacker may have access to confidential data or even he can delete the storage data without knowledge of user.

Review of Literature (Local

Storage)• Shreeraj Shah, 2012, explained that HTML5 has

the feature of local storage for applications to store some information and is available everywhere within application. This feature provides great flexibility on client side but at the same time leverages a way for attacker to steal information via XSS. Local storage not only gives access to local variables but also to global variables. Global variables may contain important information like usernames, passwords, tokens, hash etc that can easily be exploited by attacker through javascript.

Geolocation API• De Ryck, 2012, illustrated that, HTML 5

Geolocation API provides us with fast access to maps and allows users to share their current location on site. A user can check his/her location anytime with just internet available. On the other side, it also violates users’ confidentiality and integrity. The Geolocation API has built-in caching features which save users’s position which he visited after certain time period, this can be used by attacker to exploit user’s data.

Problem Statement

• To find ultimate defense mechanisms against CSRF attacks in HTML 5

Proposed Work• We have proposed a hybrid solution based on

Robert McArdle, 2011 and Shreeraj Shah, 2012 in which they used XMLHttpRequest through ajax calls in cross origin domains using HTML 5 Access-Control-Allow-Origin header, and XMLHttpRequest with attribute “withCredentials” set to true, respectively. Our proposed solution is that, for cross origin requests, we set Access-Control-Allow-Origin header in ajax request with additional attribute “withCredentials” set to true and cache to false to avoid CSRF attack.

Methodology• For cross domain calls, we need to set header

“Access-Control-Allow-Origin” to * or to some specific site which allows resource sharing and attribute “withCredentails” provided by HTML 5 to true for credentialed request and to get data in response through cross domain which allows to save response in cookies leading towards CSRF. If we set an additional attribute cache as false in ajax request which does not allow browsers to save response in cache even in cookies. Each time fresh response would be fetch directly from server. In this way, we can avoid CSRF attack and safely use HTML 5 CORS feature. This would work for HTML 5 online applications but this may not work in HTML 5 offline applications in which response and all connect is saved to cache locally for next time use.

Conclusions• We have studied security issues of HTML 5

features and found vulnerabilities in solutions provided. Our main focus has been on CSRF attacks and we have proposed a solution to avoid CSRF attacks while using CORS method of HTML 5. Our proposed solution would work for HTML 5 online applications but as HTML 5 provides us with great and advanced features like offline applications, so this may not be a feasible solution for offline applications.

Future Work• We have proposed a solution to avoid

CSRF attack against HTML 5 CORS feature. Technically, we envisage to analyse and validate this solution on different websites with different requests in future. Also, we would focus on some more security issues and attacks posed by HTML 5, that may have been present before advent of HTML 5, or may have risen due to HTML 5’s advance functionality.

References• Adam Barth et al. 2008, “Robust defenses for cross-site request

forgery”, In Proceedings of the 15th ACM conference on Computer and communications security , pp. 75-88, 2008

• Devdatta Akhawe, Adam Barth, Peifung E. Lam, John Mitchell and Dawn Song, “Towards a Formal Foundation of Web Security”, In Proceedings of 2010 23rd IEEE Computer Security Foundations Symposium, pp. 290-304, 2010

• Doug DePerry, “HTML5 SECURITY THE MODERN WEB BROWSER PERSPECTIVE”, iSEC Partners, December 2012

• Genta Iha, Hiroshi Doi, “An Implementation of the Binding Mechanism in the Web Browser for Preventing XSS Attacks: Introducing the Bind-Value Headers”, In Proceedings of 2009 International Conference on Availability, Reliability and Security, pp. 966-971, 2009

• Lavakumar Kuppan, “Attacking with HTML5”, Attack and Defense Labs, 18th October, 2010

References• Marco Balduzzi, Manuel Egele, Engin Kirda, Davide Balzarotti,

Christopher Kruegel, “A Solution for the Automated Detection of Clickjacking Attacks”, In Proceedings of ASIACCS '10 Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security, pp. 135-144, April 2010

• Philippe De Ryck, Lieven Desmet, Frank Piessens, Wouter Joosen, “A Security Analysis of Emerging Web Standards - Extended Version”, Department of Computer Science, K.U.Leuven, May 2012

• Robert McArdle, “HTML5 OVERVIEW: A LOOK AT HTML5 ATTACK SCENARIOS”, Trend Micro Research Labs, 2011

• Shreeraj Shah, “HTML5 Top 10 Threats Stealth Attacks and Silent Exploits”, Blueinfy Solutions, March 2012

• W3C Editor’s Draft, “Geolocation API Specification”, http://dev.w3.org/geo/api/spec-source.html, May 2012, Accessed 5th April, 2013

• Zeller and Felten, “An Implementation of the Binding Mechanism in the Web Browser for Preventing XSS Attacks: Introducing the Bind-Value Headers”, In Proceedings of 2009 International Conference on Availability, Reliability and Security. Pp. 966-971, 2009.

Thank you!

Questions?