This document discusses security issues related to HTML 5. It begins by introducing new features in HTML 5 that enable rich functionality but also introduce new security vulnerabilities. It then reviews vulnerabilities such as cross-site request forgery (CSRF), cross-site scripting (XSS), clickjacking, local storage, and the geolocation API. The document analyzes proposed defenses against CSRF attacks in HTML 5 and proposes a hybrid solution using XMLHttpRequest with specific headers and attributes to help prevent CSRF attacks while using cross-origin requests in HTML 5. Finally, it discusses conclusions and potential future work analyzing the proposed solution and additional HTML 5 security issues.

1. Security Issues
in HTML 5
Sara Toufiq (2011-MS-CS-23)
Wasif Altaf (2011-MS-CS-19)

2. 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

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

4. Cross-site Request Forgery (CSRF)
• According to (Zeller and Felten, 2008) CrossSite 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).

5. 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.

6. 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.

7. 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.

8. 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.

9. 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 “AccessControl-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.

10. 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.

11. 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.

12. 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. JavaScript). 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.

13. 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).

14. 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.

15. 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.

16. 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.

17. Problem Statement
• To find ultimate defense mechanisms
against CSRF attacks in HTML 5

18. 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 AccessControl-Allow-Origin header in ajax request with
additional attribute “withCredentials” set to true and
cache to false to avoid CSRF attack.

19. Methodology
• For cross domain calls, we need to set header “AccessControl-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.

20. 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.

21. 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.

22. 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

23. 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.

24. Thank you!
Questions?