HTML5 Security: Offline Web Application

Abdolmajid Shahgholi ∗

Jawaharlal Nehru Technological University

School of Information and Technology

Hyderabad, India

Shahgholi a@hotmail.com

HamidReza BarzegarJawaharlal Nehru Technological University

School of Information and Technology

Hyderabad, India

Hr.barzegar@gmail.com

G.Praveen BabuJawaharlal Nehru Technological University

School of Information and Technology

Hyderabad, India

pravbob@jntu.ac.in

Abstract: Offline Web Application [7]: Web applications are able through using HTML5 OfflineWeb Application to make them working offline. A web application can send an instruction whichcauses the UA to save the relevant information into the Offline Web Application cache. Afterwardsthe application can be used offline without needing access to the Internet. Whether the user is askedif a website is allowed to store data for offline use or not depends on the UA. For example, Firefox3.6.12 asks the user for permission but Chrome 7.0.517.44 does not ask the user for permission tostore data in the application cache. In this case the data will be stored in the UA cache withoutthe user realizing it.

Keywords: Offline Web Application, User Agent, Cache Poisoning

1 Introduction

Creating web applications which can be used offlinewas difficult to realize prior to HTML5. Some manu-facturers developed complex work around to make theirweb applications work offline. This was mainly realizedwith UA add-ons the user had to install. HTML5 in-troduces the concept of Offline Web Applications. Aweb application can send information to the UA whichfiles are needed for working offline. Once loaded theapplication can be used offline. The UA recognizes theoffline mode and loads the data from the cache. To tellthe UA that it should store some files for offline usethe new HTML attribute manifest in the < html >tag has to be used:

<!DOCTY PEHTML >

< htmlmanifest =′ /cache.manifest′ >< body >

The attribute manifest refers to the manifest filewhich defines the resources, such as HTML and CSSfiles, that should be stored for offline use. The mani-fest file has several sections for defining the list of fileswhich should be cached and stored offline, which filesshould never be cached and which files should be loadedin the case of an error. This manifest file can be namedand located anywhere on the server; it only has to endwith .manifest and returned by the web server withthe content-type text/cache-manifest. Otherwise theUA will not use the content of the file for offline webapplication cache.

User Agent (UA): The UA represents a web appli-cation consumer which requests a resource from a web

∗Corresponding Author, P. O. Box 1447653148, F: (+98) 021 8827-1350, T: (+91) 8686184291

CICIS’12, IASBS, Zanjan, Iran, May 29-31, 2012

application provider. This resource is processes by theUA and, depending on the resource, is rendered anddisplayed by the UA to the end-user. The UA hasthe capability to establish Hypertext Transfer Proto-col (HTTP) [6] connections to a web server, to renderHTML / CSS and execute JavaScript code correctly.

Further, the UA has implemented the HTML 4.01and HTML 5 standard and its corresponding capabili-ties such as the Geolocation API or Web Storage .

Web application: The web application is a genericterm of the entity providing web resources and is Com-posed out of the following three main parts:

Website: The website is composed out of severalsingle web resources and is accessible via its URI.

• Website: The website is composed out of severalsingle web resources and is accessible via its URI.

• Web server: The web server is hosting at leastone website. The HTTP(S) connection is es-tablished between the UA and the web server.Besides hosting websites additional resources arealso provided by the web server. Other connec-tions, such as Web Socket API connections, arealso established between the UA and the webserver.

• Database: The database stores any kind of dataneeded for the web application such as personalinformation about their users.

MotivationAs seen many attacks against web applications exist (in2010) and the need for security in the Internet grows.Beside the comfort the web provides, security concernsare critical points to be considered. This applies tocurrent web applications but also for future web appli-cations. The threats to web applications described inthis section need to be kept in mind when consideringHTML5 security issues.

2 Vulnerabilities

With the introduction of Offline Web Applications thesecurity boundaries are moved. In web applicationsprior to HTML5 access control decisions for accessingdata and functions were only done on server side. Withthe introduction of Offline Web Applications parts ofthese permission checks are moved towards the UA.Therefore, implementing protections of web applica-tions solely on server side is no longer sufficient if Of-

fline Web Applications are used. The target of attack-ing web application is not limited to the server-side; at-tacking the client-side part of Offline Web Applicationis possible as well. This mainly breaks the requirementof UA protection. But breaking this security require-ment all other security requirements are endangeredimplicitly as well. E.g., if the security requirement se-cure caching can be broken, an attacker can include anycontent into the Offline Web Application cache and usethis code for breaking the other security requirementsas well.

3 Threats and attack scenarios

Spoofing the cache with malicious data has been aproblematic security issue already prior to HTML5.Cache poisoning was possible with already existingHTML4 cache directives for JavaScript files or otherresources. However, UA cache poisoning attacks werelimited. With HTML5 offline application this cachepoising attacks are more powerful. The followingthreats are made worse in HTML5:

• Cache Poisoning: It is possible to cache the rootdirectory of a website. Caching of HTTP as wellas HTTPS pages is possible. This breaks the se-curity requirement of UA protection and Securecaching.

• Persistent attack vectors: The Offline applica-tion cache stays on the UA until either theserver sends an update (which will not happenfor spoofed contents) or the user deletes the cachemanually. However, a similar problem as for WebStorage exists in this case. The UA manufactur-ers have a different behavior if the ”recent his-tory” is deleted. This breaks the security require-ment of UA protection.

• User Tracking: Storing Offline Web Applicationdetails can be used for user tracking. Web ap-plications can include unique identifiers in thecached files and use these for user tracking andcorrelation. This breaks the security requirementof Confidentiality. When the offline applicationcache is deleted depends on the UA manufactur-ers.

As already mentioned, cache poisoning is the most crit-ical security issue for offline web applications. There-fore, possible cache poisoning attack scenario is givenin this section which is motivated on the ideas of anarticle from [8]. Figure 1 shows a sequence diagramwhich illustrates how an attacker can poison the cache

The Third International Conference on Contemporary Issues in Computer and Information Sciences

of a victim’s UA. The victim goes online through an un-secure malicious network and accesses whichever page(the page to be poisoned does not have to be accessednecessarily). The malicious network manipulates thedata sent to the client and poisons the cache of the UA.Afterwards, the victim goes online through a trustednetwork and accesses the poisoned website. Then theactual attack happens and the victim loads the poi-soned content from the cache.

Figure 1:

1 Victim access any.domain.com through a mali-cious access point (e.g. public wireless).

2 The HTTP GET Request is sent through the ma-licious access point to any.domain.com.

3 Any.domain.com returns the response.

4 The access point manipulates the responsefrom any.domain.com: A hidden Iframe withsrc=http://www.filebox-solution.com is added tothe response which is sent to the UA.

5 This hidden Iframe causes the UA to send a re-quest to www.filebox-solution.com in the back-ground (the user will not notice this request).

6 The request to www.filebox-solution.com is inter-cepted by the malicious access point and returnsa faked login page including malicious JavaScript.The HTML page contains the cache manifestdeclaration. The cache. Manifest file is config-ured to cache the root directory of www.filebox-solution.com (the cache. Manifest file itself isreturned with HTTP cache header to expire latein the future).

7 The victim opens his UA in a trusted networkand enters www.filebox-solution.com in the ad-dress bar. Because of the offline application cachethe UA loads the page from the cache includingthe malicious JavaScript. No request is sent towww.filebox- solution.com.

8 After the user has entered the login credentials tothe faked login form (offline application), it poststhe credentials to an attacker controlled server(JavaScript code execution).

9 The JavaScript performs the login request towww.filebox-solution.com (From here the stepsare optional; they’re performed to hide the ac-tual attack from the user).

10 The Login request is sent to www.filebox- solu-tion.com.

11 Login successful (The user does not notice theattack performed).

One may argue that a similar kind of attack waspossible also with standard HTML cache features.That is correct but the offline application attack hastwo advantages:

• Caching of the root directory is possible: If theuser opens the poisoned website, the UA will notmake any request to the network and loads thepoisoned content from the cache. If the root di-rectory is cached using HTML4 cache directives,a request to the server is sent as soon the userclicks refresh (Either the server sends a HTTP304 not modified or an HTTP 200 OK or the pageis loaded from the server and not from cache).

• SSL-Resources can be cached as well: In HTML4Man-in-the-middle attacks were possible butthen the user had to access the website throughthe unsecured network. With offline applicationcaching of the root of an HTTPS website can becached; the user does not have to open the web-site. The user may accept an insecure connection(certificate warning) in an unsecured network be-cause he does not send any sensitive data. Thereal attack happens if the user is back in his se-cured network, feels safe and logs in to the poi-soned application.

4 Countermeasures

The threats Persistent attack vectors and Cache poi-soning cannot be avoided by web application providers.The threats are defined in the HTML5 specification.To come around this problem is to train the users toclear their UA cache whenever they have visited the In-ternet through an unsecured network respectively be-fore they want to access a page to which sensitive dataare transmitted. Further, the user needs to learn to

CICIS’12, IASBS, Zanjan, Iran, May 29-31, 2012

understand the meaning of the security warning andonly accept Offline Web Applications of trusted sites.

5 Conclusion

Applications such as e-mail clients, word processingor image manipulation applications will have the ca-pabilities to run completely in the browser. Makinguse of HTML5 running these application completelyoffline in the browser will also be possible. This pro-vides new ways for malware. Everything the user needsto run HTML5 web application is a HTML5 support-ing browser. This is an ideal target for a malware forwrite-once, run everywhere - HTML5 is platform inde-pendent. Malware only making use of JavaScript andHTML5 features may be seen numerous with the ini-tiation of HTML5. It will be new that the targets ofHTML malware will no longer be limited to web appli-cation servers but move to the UA as well (beside theproblematic of exploiting browser vulnerabilities) be-cause HTML5 provides feature rich capabilities to theUA; they can even be persisted without exploiting UAvulnerabilities, e.g. in the Web Storage. Overall it canbe said that making web applications secure solely withtechnological solutions is a very complex task and can-not be done by all web application providers. There-fore, the end-user is highly responsible for using web

applications carefully and only providing personal andsensitive data if a strong trust relationship exists.

Refrences

[1] World Wide Web Consortium (W3C), HTML4.01 Specification, and W3C Recommendation,http://www.w3.org/TR/1999/REC-html401-19991224/(1999).

[2] The World Wide Web Consortium (W3C) and XHTML1.0 The Extensible HyperText Markup Language,http://www.w3.org/TR/xhtml1/ (2000).

[3] The World Wide Web Consortium (W3C), HTML5 - A vo-cabulary and associated APIs for HTM and XHTML, and E.Jamhour, http://www.w3.org/TR/html5/ 4786 (2007), 196-199.

[4] M. Pilgrim, HTML5: Up and Running, Sebastopol: OReillyMedia, 2010.

[5] Web Hypertext Application Technology WorkingGroup (WHATWG), What is the WHATWG?:http://wiki.whatwg.org/wiki/FAQ (2011).

[6] Internet Engineering Task Force, The Internet So-ciety: Hypertext Transfer Protocol – HTTP/1.1,http://www.ietf.org/rfc/rfc2616.txt (1999).

[7] The World Wide Web Consortium (W3C), Offline Web Ap-plications: http://www.w3.org/TR/offline-webapps/ (1999).

[8] Lavakumar Kuppan and Attack and Defense Labs, Chromeand Safari users open to stealth HTML5 AppCacheattack: http://blog.andlabs.org/2010/06/chrome-and-safari-users-open-to-Stealth.Html (2010).