Bachelor thesisHTML5 Web application security with OWASP

top ten 2013

Daniel Nilssondand10@student.bth.se

Hampus Aberghaaf10@student.bth.se

Supervisor: Edgar Lopez-Rojasedgar.lopez@bth.se

Blekinge Institute of Technology, School of Computing

May 31, 2013

Abstract

HTML5 has gained a lot of interest the last couple of years from web developers.HTML5 is the new upcoming standard for HTML set to be released in the endof 2014 (W3C). In this report HTML5 is reviewed in order to determine if it hasmade web applications more secure. This is done with information study and theuse of experimental test cases. We use the latest OWASP top ten list of securityrisks in web applications as a benchmark. As a result we found five correlationsbetween OWASP top ten list and HTML5 functionality. The results clearly indi-cates that HTML5 is affecting web application security. The security risks that wassuccessfully exploited is Cross-site scripting, Security Misconfiguration, SensitiveData Exposure, Cross-site request forgery and Unvalidated redirects and forwards.We suggest countermeasures for the tests performed and discuss how developersshould have security in mind when it comes to developing with HTML5.

Acknowledgements

We would like to thank our supervisor Edgar Lopez-Rojas for his contributionand help throughout this project. He has been pushing us in the right direction,motivated our work and helped us with our report. Furthermore we would like tothank the community and the people who has published material on HTML5 andweb application security that has been of great use for us.

Contents

1 Introduction 11.1 Purpose and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theoretical framework 52.1 HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Open web application security project - OWASP . . . . . . . . . . . 11

3 Experimental test cases 153.1 Test case structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 T1 - Cross-site scripting . . . . . . . . . . . . . . . . . . . . . . . . 173.4 T2 - LocalStorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5 T3 - CORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6 T4 - Clickjacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Discussion 294.1 Analysis of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Analysis of methodology . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Conclusions 33

References 35

Appendices 37

i

A Test case 1 Cross-site Scripting . . . . . . . . . . . . . . . . . . . . 38B Test case 2 Localstorage . . . . . . . . . . . . . . . . . . . . . . . . 39C Test case 3 CORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41D Test case 4 Clickjacking . . . . . . . . . . . . . . . . . . . . . . . . 43

ii

List of Figures

2.1 HTML5 API’s1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 High level overview of the web model . . . . . . . . . . . . . . . . . 72.3 High level overview for localstorage . . . . . . . . . . . . . . . . . . 82.4 Five most common browsers support of HTML5 [6] . . . . . . . . . 9

3.1 Symbols used in scenarios . . . . . . . . . . . . . . . . . . . . . . . 163.2 Scenario cross-site scripting . . . . . . . . . . . . . . . . . . . . . . 183.3 XSS test before attack . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 XSS vector in the input field . . . . . . . . . . . . . . . . . . . . . 193.5 XSS alert(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6 Scenario stealing LocalStorage . . . . . . . . . . . . . . . . . . . . 223.7 Empty local storage . . . . . . . . . . . . . . . . . . . . . . . . . . 223.8 Data successfully added in local storage . . . . . . . . . . . . . . . 233.9 Output from external server . . . . . . . . . . . . . . . . . . . . . . 233.10 Example view of clickjacking with 60% opacity . . . . . . . . . . . 27

iii

List of Tables

3.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 XSS Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 XSS Results for cross-site scripting . . . . . . . . . . . . . . . . . . 203.4 Characters to escape to prevent XSS . . . . . . . . . . . . . . . . . 20

4.1 Test cases results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

iv

Glossary and Abbreviations

API Application Programming Interface

Attack Vector An attack vector is a path or means by which a hacker (or cracker)can gain access to a website or web server in order to deliver a payload ormalicious outcome

ClickJacking A malicious technique to deceive the end user to click on some-thing they perceive as legitimate.Which potentially can expose the end userconfidential information

CORS Cross-Origin Resource Sharing

CSRF Cross-Site Request Forgery

DRM Digital Rights Management

FrameKiller a piece of JavaScript code that prevents web page from being dis-played within a frame

HTML5 Hyper Text Markup Language 5

OWASP Open Web Application Security Project

WebRTC enables the web with Real Time Communication capabilities

XSS Cross-site scripting

v

Chapter 1

Introduction

Web technologies have grown exponentially during the last few years and it hasbecome more and more depended on accessibility and functionality. Hyper TextMark-up Language (HTML) 4.01 is the current standard for HTML. A new stan-dard HTML5 is at this moment being developed. The development is done mainlyby Web Hypertext Application Technology Working Group (WHATWG) but alsotogether with World Wide Web Consortium (W3C) and Internet Engineering TaskForce (IETF). This new standard has several new features, which results in newrisks and threats that needs to be addressed.

HTML5 has become very popular, which makes it important that it is testedcontinuously. At this moment when writing this report the status of the standardis “Working draft - Candidate Recommendation” but most browsers are alreadycompatible with the new features that HTML5 introduce. In 2011 WHATWG andW3C decided that they have different goals with HTML5. W3C wants to publish afinished version[1]. WHATWG however wants the work to be continued on a livingstandard. WHATWG’s purpose is to maintain the specification, fix problem andadd new features to evolve the platform.[3] Reviewing HTML5 from a security per-spective Open Web Application Security Project (OWASP) top 10 list of securityrisks were used as a benchmark. OWASP is an open community which providesdocumentation and tools to improve web application security. Every third yearthey publish a top 10 list of security risks in web applications.

During the project the OWASP top 10 list was a candidate release, it is now anofficial release as of June 12 this year (2013). The security risks was not changedbetween the candidate release and the official release. This makes it possible forus to assume that our tests are still valid for the official release.

1

The security risks that are included this year:

• A1 Injection

• A2 Broken authentication and session management

• A3 Cross-site scripting

• A4 Insecure direct object reference

• A5 Security misconfiguration

• A6 Sensitive date exposure

• A7 Missing function level access control

• A8 Cross-site request forgery

• A9 Using Known Vulnerable Components

• A10 Unvalidated redirects and forwards

A short description of all the security risks is presented in section 2.2.1.

1.1 Purpose and objectives

The purpose of this project is to review HTML5 to asses if it has any impacton web application security. The focus in this thesis is to have security in mindwhile reviewing the new features. This project presents test cases to determine ifHTML5 can exploit security risks specified in OWASP Top 10 release 2013.

1.2 Intended audience

This thesis is written for developers of web applications to increase security aware-ness while developing applications with HTML5.

1.3 Research question

Can the security risks specified in OWASP top 10 release 2013 be exploited usingnew features introduced HTML5?

2

1.4 Scope

The scope of this project is to develop 4 experimental test cases which can deter-mine if OWASP top 10 list could be influenced by HTML5. The test cases includereasonable scenarios which are likely to happen in a production environment. Allthe test cases include results and conclusions. Furthermore because of the fact thatHTML5 is introducing many new things and improvements it was not possible forus to test everything. So we selected to implement 5 of the risks specified in theOWASP top 10, we implemented A3 Cross-site Scripting (XSS), A5 Security Mis-configuration, A6 Sensitive data exposure, A8 Cross-site Request Forgery (CSRF)and A10 Unvalidated redirects and forwards. These risks we chose because theycould be affected by a client side implementation. In order for us to assume thiswe had to discuss all the security risks and see which ones could be implemented.We found no direct association with the remaining 5 security risks. This does notmean these are unaffected by HTML5 functionality.

1.5 Limitations

All browsers were not used in the test cases since it might require different im-plementations for each test and browser. Google Chrome was used throughout alltest cases and in some cases also Firefox, these browsers were used because theyare in top regarding HTML5 support and also the most commonly used.[6]

1.6 Methodology

This thesis is based on information study, experimental and empirical studies.The information studies was done by studying W3C’s working draft, informationfrom WHATWG[1] and also information from OWASP was studied. W3C’s draftand WHATWG was studied in order for us to gain more knowledge about thenew features and functionalities introduced in HTML5. OWASP was studied toget the knowledge about the new security risks published in their new top 10 listpublished 2013 [12]. The information that we gained from these sources was thenused to create our experimental test cases which was the basis for our empiricalresults and conclusions.

3

1.7 Document structure

This thesis report has been divided into different chapters and sections.Chapter 1 contains background information about this project, research question,scope, limitations and methodology. Chapter 2 presents the theoretical frameworkused in this project. What is used in the test cases and why. Chapter 3 containsexperimental test cases. Each test case contains a description of the test case, usagescenario, result and conclusion. Chapter 4 presents the results, analysis of results,analysis of methodology and discussion. Chapter 5 presents the conclusions andfurther work.

4

Chapter 2

Theoretical framework

HTML5 is the fifth revision of the HTML markup language created by W3C,IETF and WHATWG. HTML5 consists of a collection of features, technologiesand APIs that enhances the multimedia experience of the web. HTML5 does notonly include the HTML markup language but also consists of CSS3 and a series ofJavaScript APIs. The developers behind HTML5 have been focusing on develop-ing a web application environment that is fast, secure, responsive, interactive anda good looking experience for the users. This thesis is focusing on the secure partof HTML5 and why it is secure. Even though they put a great deal of thoughtin developing a secure platform, there is still vulnerabilities that can be exploited.While reading this report keep in mind that HTML5 is a working draft (May 2013)and things that has been written during this period may have been changed.

Offline and Storage in subsection 2.1.1, Event attributes in subsection 2.1.2 andNetwork and Access in subsection 2.1.3 gives a brief introduction about the fea-tures used in the test cases. Web workers in subsection 2.1.5 and Premium videocomponents in subsection 2.1.6 contains a brief information about important func-tionality for HTML5 which has not been used in any of the test cases in thisthesis.

5

2.1 HTML 5

HTML5 is backward compatible with HTML 4.01. That said threats from HTML4.01 still remains. The threats have even in some cases been made easier or worseto exploit. XSS are still a factor and changes to prevent XSS have not beenmade for the old Attack Vectors. HTML5 elements creates new vectors for XSSattacks[16].

Figure 2.1: HTML5 API’s1.

In the figure 2.1 we can see all the new API’s and related technologies whichis introduced in HTML5. As the picture shows there is a lot of new API’s andtechnologies introduced which forced us into reducing the scope. We have markedthe ones which we covers in this thesis with a black square.

High level overview of the web model as shown in figure 2.2 demonstrates the pro-cess of how the end user interacts with a website. LocalStorage and applicationcache can be manipulated with JavaScript executed in the user agent and createsnew threats as they are global objects. The server side implementation need tofollow the implementation instructions referred from W3C standard to avoid risk,the client side also needs to be protected. The browser vendors need to keep the

1Image based on original work by Sergey Mavrody.

6

client side protected as they can expose you to unwanted functionality, therefore itis important to keep up-to-date with your web browser. The server side needs tobe mitigating the attack vectors from XSS and keep track on their implementationof Cross-Origin Resource Sharing and storage settings.[4]

Figure 2.2: High level overview of the web model

2.1.1 Offline and Storage

Web applications can now be run offline with the help of application cache, Local-Storage, sessionStorage, IndexedDB and File System.

In the specification for LocalStorage and SessionStorage they specify that Security-Error should be thrown whenever the storage is accessed from outside its origin.[2]This means that two different websites cannot access each other’s entries in Lo-calStorage. This However also means that if a website includes a script which ishosted externally like this:

1 <script

src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js">

2 </script>

Then the script is considered a part of the origin website and will be granted accessto the LocalStorage.

In figure 2.3 you can see how the LocalStorage relates to the browser and not thewebserver. LocalStorage can only be accessed on client side and from the sameorigin as mentioned before.This scenario is tested in section 3.4 T2 - LocalStorage.

7

Figure 2.3: High level overview for localstorage

2.1.2 Event attributes

HTML 5 introduces new event attributes, some of those have been used in the newXSS attack vectors. An event attribute is an attribute which triggers JavaScript torun. All the new event attributes that has been added can be found at w3schools2.The ones that has been used in the new attack vectors published on html5sec isoninput, onerror, onforminput, onformchange, onscroll and onblur.[16]

2http://www.w3schools.com/tags/ref_eventattributes.asp

8

2.1.3 Network and access

HTML5 introduces several new features for network access such as XMLHttpRe-quest (XHR) level 2 and Cross-orgin resource sharing (CORS).

What is level 2?XMLHttpRequest Level 2 was developed in a seperated draft until the endof 2011, at which point the two drafts were merged and XMLHttpRequestbecame a single entity again. [19]

This could be used to send and receive HTTP/HTTPS requests direct to the webserver and load the content dynamically into the JavaScript. Web workers enablesJavaScript to be executed in the background of website, see subsection 2.1.5 forfurther information about this subject.

2.1.4 HTML5 compability

Not all web browsers has same support for HTML5 functionality, this can dependon the browser vendor standard and/or rendering engine. Figure 2.4 presents theHTML5 support from Jan 2009 to Jan 2013.

Figure 2.4: Five most common browsers support of HTML5 [6]

The score indicates how well a browser supports HTML5 standard and relatedspecifications.

9

2.1.5 Web workers

Web workers is a new feature that gives JavaScript the ability to run in the back-ground without interrupting the web user experience.

“This allows for long-running scripts that are not interrupted by scriptsthat respond to clicks or other user interactions, and allows long tasksto be executed without yielding to keep the page responsive.”[7]

“...Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost.”[7]

Alone Web workers are not a security issue. A developer could use this to executelong running code without the user permission for malicious purposes.

Andlabs.org demonstrate this with their program Raven to decrypt hashed keyson a distributed computing system using HTML5 web worker.

2.1.6 Premium video components

W3C is moving towards developing protected video playback to replace third partyplugins such as Silverlight and Flash. Its replacement is based on 3 new compo-nents which is still a draft on W3C. Netflix is planning to adopt these componentsonce they are finished as Microsoft will drop support for Silverlight in 2021. 3

They will use the encrypted media extensions to access digital rights managementfor their media playback.4

Media source extension

“This specification extends HTMLMediaElement to allow JavaScript togenerate media streams for playback. Allowing JavaScript to generatestreams facilitates a variety of use cases like adaptive streaming andtime shifting live streams.”[8]

Encrypted media extension

Encrypted media extensions is still an editor’s draft but once it’s finished it willprovide

3 http://support.microsoft.com/gp/lifean45#sl54 http://techblog.netflix.com/2013/04/html5-video-at-netflix.html

10

“This proposal extends HTMLMediaElement providing APIs to controlplayback of protected content.”[9]

In other words this will provide an API for DRM protection. EME define howthe browsers will detect that the media has been encrypted and which encryptionmethod is being used. Once it reach the client browser content decryption mod-ule(CDM) will be used to verify that the license is being fulfilled and then decryptthe data.

Web cryptography API

The web cryptography API from W3C provides:

“Basic cryptographic operations in web applications, such as hashing,signature generation and verification, and encryption and decryption.”[10]

2.1.7 Real time communication - WebRTC

“WebRTC is a free, open project that enables web browsers withReal-Time Communications (RTC) capabilities via simple JavaScriptAPIs.”[11]

This could change the internet and web applications enormously, this technologycould make it possible to replace software like Skype with a web application. Allbrowsers should ask the users for permission to use microphone and camera, thiscould otherwise compromise privacy and the integrity of the users.

This will not be tested during this thesis but currently W3C is working on aspecification[11]. Google Chrome, Firefox and Opera is pushing the develop-ment of this feature and are already far into the implementation of this into thebrowsers

2.2 Open web application security project - OWASP

OWASP non-profit organization which distributes material about web applicationsecurity. On their web site you can find a lot of documentation and tools that canbe used in order to improve security in a web application. It is open for Everyoneand anyone can participate in OWASP and contribute.

”We advocate approaching application security as a people...”[12]

11

OWASP published a top 10 list of vulnerabilities in year 2004, since then everythird year they have published a new top 10 list. The 2013 was released on June12, 2013.

2.2.1 OWASP top ten 2013

This section covers the ten security problems from OWASP top ten list and usagescenario from an HTML5 functional point of view.

A1 - injection

Injection flaws occurs when user-supplied data is sent as part of a command orquery. There is several different types of injections SQL, LDAP, XPath, XSS andmany more. A successful injection means the attacker success to trick the inter-preter into executing their specially crafted data. HTML5 will affect some typesof injections, Cross-Site Scripting is one type of injection that is affected.

A2 - Broken authentication and session management

Authentication and session management is about handling active sessions and userauthentication. Account management functions such as change password, forgotpassword and account update is also a part of this topic. An example could be thatthe attacker shouldn’t be able to change password without the old password, thiscould otherwise compromise the user. Furthermore the user credentials should beencrypted or hashed when they are stored. Sessions should time-out and sessionID’s shouldn’t be exposed.

A3 - Cross-site scripting

Cross-site scripting is a vulnerability which lets an attacker inject code into awebsite which is then viewed and executed by other users. This vulnerabilityusually occurs when user provided input is dynamically added to the content. Toprevent this input should always be validated before it’s added to the content. Aclassic example is a website with a guestbook which doesn’t validate the inputbefore adding the message. Then someone could send in the following code as amessage:

1 <script> window.location = ’http://google.com’; </script>

12

This would redirect all the users which visits the guestbook to google.com. Thisis of course considered bad by the applications owner since it loses traffic andvisitors. This vulnerability is commonly used to wreck websites, steal cookies, runmalicious code on end users computers and to create fake requests. [14]

A4 - Insecure direct object references

This risk occurs if an application use actual name or key of an object when gener-ating pages. This could easily be manipulated and it’s called insecure direct objectreference. When accessing restricted objects applications should verify that theuser is authorized in order to prevent this risk. It’s easy to test and detect theseflaws by manipulating the parameters.

A5 - Security misconfiguration

Security misconfiguration can occur in all layers of an application. Unnecessaryservices, default passwords and ports are just some examples.

A6 - Sensitive data exposure

OWASP has added Sensitive Data Exposure to their candidate release as a poten-tial security problem. From the point of view of HTML5 features there is LocalStorage, Application Cache, Indexed DB which could be used as new attack vectorsif sensitive data has been stored in these functions. OWASP recommend in theirspecification that developers don not use these features to store user credentials[13].In test T2 - LocalStorage these locations are compromised by third party applica-tion or cross domain JavaScript’s.

A7 - Missing function level access control

Could privileged functionality which normally requires authentication be usedanonymously? This is usually caused by incorrect implementations from the back-end development and is not affected of any the new HTML5 features.

13

A8 - Cross-site request forgery (CSRF)

CSRF vulnerabilities occur when a website allow an authenticated user to performsensitive actions. Only the browser of the authenticated user is verified and notthe user actions.

Cross-Site Request Forgery could be used with CORS and XHR. Shreeraj Shahfrom Blueinfy has done a great deal of work in this area and this could be foundat his blog.[15]

A9 - Using Known Vulnerable Components

Using third-party libraries with known vulnerabilities is placed number 9 on OWASPtop 10. This could with ease be avoided if the developers keep up to date withlatest in security CVE and vendor release notes.

A10 - Unvalidated redirects and forwards

Unvalidated redirect and forwards could be used to redirect the end user to phish-ing or malicious website without proper validation from server side implementa-tion.

2.2.2 HTML5 and OWASP list

Looking through the OWASP list we can see a few interesting security risks. Thesewill be presented in chapter 3. We could discard A1 (Injection), A2 ( Broken au-thentication and session management), A4 (Insecure direct object references), A7(Missing function level access control) and A9 (Using Known Vulnerable Compo-nents). These risks contains backend implementations and we could not find anyusage of these risk with HTML5 functionality.

Even though we did not find any usage of these risk this does not mean they can’tbe exploited using HTML5.

14

Chapter 3

Experimental test cases

We will present 4 test cases were we found 5 exploits of the OWASP list usingHTML5 functionality. This will present usage of Cross-site scripting (A3) usingnew elements introduces in HTML5. Security misconfiguration (A5) and Cross-siterequest forgery (A8) is explained in test case 3 using cross-origin resource sharingand exploiting same origin policy. Sensitive data exposure (A6) is exploited usingLocalstorage in the second test case. And the last of the OWASP risk is presentedusing Clickjacking with HTML5 functionality to exploit Unvalidated redirect andforwards (A10). The results found no support for the remaining 5 security riskfrom OWASP.

ID Test case name

T1 XSS (A3)T2 LocalStorage (A6)T3 CORS (A5 & A8)T4 ClickJacking (A10)

Table 3.1: Test cases

3.1 Test case structure

This section will present the experimental test cases that were conducted dur-ing this project. Each test case presents explanation of usage, input variables,scenarios, expected result, result and conclusions.

15

Figure 3.1: Symbols used in scenarios

Every test case has an unique ID and a descriptive name and all test cases hasatleast one of OWASP risk. If a test is successful it proves that specified securityrisk can be exploited using HTML5.The symbols shown in Figure 3.1 is the symbols presented in the test case scenar-ios.

3.2 Environment

All test ran on a PC running on Windows 8. The hardware in the computer thatwe used in the tests corresponds to a minimum of 4 GB memory, Intel core i5processor and NVIDIA GT 555M as graphics processing unit. Google Chrome(version 27.0.1453.93) was used as user-agent and finally WAMP (version 2.2E)as a web server. Some tests required an external host, in this case either thestudent server was used or hampusaberg.com 1. Tests that required a databaseused SQLite. We used git to handle the versions in case of that we were workingon the same experiment or just editing in the same files.

1Web server running Apache on a foreign host

16

3.3 T1 - Cross-site scripting

This test will show if HTML5 Event attributes affects A3 Cross-site scripting. XSShas been in all top 10 lists that OWASP has published since 2004. XSS has beena problem for at least 9 years. With HTML5 new attack vectors has been addedand Html5sec.org has already done a great job and found a lot of new vectors thatare introduced in HTML5.

3.3.1 Description

Cross-site scripting is considered to be a server-side problem because the inputshould be interpreted on the server. In HTML5 new vectors has been added,to test those we have implemented a test case without any server-side interpreter.This test case uses two input elements to add dynamic content to the site. The goalwas to input specially crafted vectors which will execute a script. Scripts in thistest are replaced with alert(1). Two vectors that were published on html5sec.orgare used in order to test that they really work and to demonstrate Cross-sitescripting.

3.3.2 Inputs

Appendix A - XSS.php This file implements just a form with dynamic content.This is done with the POST variable, since no server validation is included in thistest.

ID Test case name

1 <input onblur=alert(1) autofocus>2 <input onfocus=alert(1)>

Table 3.2: XSS Vectors

3.3.3 Expected

XSS is still applicable and the two vectors tested should successfully be injected.These vectors should generate an alert(1).

17

3.3.4 Scenario

A website with a XSS vulnerability is attacked and a script is successfully injected.The script is added to the content of the site and when a legitimate user entersthe site they will fetch the content. The content in this case which includes thescript that was injected. For a simple illustration, see Figure 3.2.

Figure 3.2: Scenario cross-site scripting

18

3.3.5 Implementation

The test case was implemented and tested on a local webserver. Here is pictureshow it looked like. Two simple input fields, the input from the first field is thendisplayed on the second field. The text which is marked in red is one examplevector that was used during development.

Figure 3.3: XSS test before attack

Figure 3.4: XSS vector in the input field

Figure 3.5: XSS alert(1)

19

3.3.6 Results

Vector ID Result

1 Successful2 Successful

Table 3.3: XSS Results for cross-site scripting

To prevent these XSS vectors it’s important to use quotes around attributes andto escape the submitted data before it’s added to the content. By doing this youprevent execution of the code and the content is recognized as plain text instead ofcode.2 Sanitizing should be done from backend, therefore it should not be affectedby HTML5. HTML5 however introduces some new input types, which will improveinput control and validation of input on client-side. One of the new input types isemail 3 , this will only allow strings which matches a regular email address. Thisis not enough as protection against XSS but this together with sanitizing in thebackend can mitigate most XSS vulnerabilities.

Table 3.4: Characters to escape to prevent XSS

Character Replace with

& &amp;< &lt;> &gt;‘ &#x27;/ &#x2F;

2https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_

Sheet3http://www.w3.org/TR/html-markup/datatypes.html#form.data.emailaddress

20

3.4 T2 - LocalStorage

This test case determines that A6 Sensitive data exposure is affected by HTML5.LocalStorage is storing simple key/value pairs on the client and this data has noexpiration date. The data stored should only be accessible by the website thatinitiated the storage. LocalStorage maximum size in chrome is 5,242,880 byteswhich is 5mb.4 OWASP has a HTML5 security cheat sheet which suggests thatno sensitive data is stored in LocalStorage because it can easily be stolen with aJavaScript.[13]

3.4.1 Inputs

The goal of this files is to steal the information stored locally on the client in theLocalStorage.Localstorage.js - External script that steals all entries in LocalStorage. This isdone with a for-loop that loops thru all entries. This entries are then sent to theexternal host.lsave.php – This file basically just saves all the data it receives via AJAX into aSQLite database.

3.4.2 Scenario

A website is using LocalStorage to store information, furthermore the website hasincluded a third-party script. This script will fetch all the information in theLocalStorage and save it into a database.

3.4.3 Expected

All entries in LocalStorage on the client is fetched and sent to an external serverwhich is saving the data into a database.

4 http://developer.chrome.com/extensions/storage.html#property-local-

QUOTA_BYTES

21

Figure 3.6: Scenario stealing LocalStorage

3.4.4 Implementation

In the implementation there is a form where the user can input a key and a valueand then save it into the LocalStorage.

Figure 3.7: Empty local storage

Before anything was added in the LocalStorage, as shown in the picture there isno data in the LocalStorage. “testkey” and “*sensitive data*” was inserted in theinput fields.

22

Figure 3.8: Data successfully added in local storage

“testkey” and “*sensitive data*” was added to the LocalStorage which is markedwith green in the picture. The site was then updated, this made the maliciousscript run which steals the information stored in LocalStorage.

Figure 3.9: Output from external server

The information was successfully stolen and stored in a database on external hostas marked in green in the picture. On this site all entries in the database is justfetched and printed out.

3.4.5 Results

By including an external script it was possible to steal the LocalStorage data andsave it into an external database as expected.

3.4.6 Conclusions

This is a good feature to have in the browsers, as long as the developers knowsthat no sensitive data should be stored here. This is recommended by OWASP

23

[12] and also proven to be easily stolen in this test. If sensitive data were to bestored in LocalStorage this would affect the A6 Sensitive data exposure.

To minimize the risk to include a malicious third party script we would recommendto not include the scripts from external hosts. We would instead recommend youto save the script on the server and manually update the script when a new versionis released. When updating the script with a new version you should check whathas been updated and added to the script. This should be done in order to findout if malicious code has been added.

3.5 T3 - CORS

Before HTML5 Cross-Origin Resource Sharing (CORS) came the developers neededto use third-party applications to allow cross domain request such as Java andSilverlight. Java and Silverlight depended on crossdomain.xml (flash) and clien-taccesspolicy.xml (Silverlight). With HTML5 CORS the User Agent can makeXMLHttpRequest to other than the origin domain. With CORS enables the de-velopers to fetch data from other website outside their domain.

Syntaxes used in this test case:

• Access-Control-Allow-Origin: http://AllowedDomain.com

• Access-Control-Allow-Credentials: Boolean

• Access-Control-Max-Age: seconds

All modern browsers mentioned in subsection 2.1.4 is supporting CORS.

3.5.1 Description

CORS introduces the security problem that XMLHttpRequest can be sent withoutany user permission or knowledge. This test case will test to make a request toforeign host with Access-Control-Allow-Origin: *.This test will determine if there is a association with OWASP TOP 10 2013 A5- Security misconfiguration and A8 - Cross-site request forgery.

24

3.5.2 Inputs

corstest.js - Appendix C is used to demonstrate receiving content with XML-HTTPREQUEST from a domain using Access-Control-Allow-Origin: *.http://dev.hampusaberg.com/corsAllow.php is the foreign host used to receivedata to the local test environment.

3.5.3 Scenario

Universal allow: Using wildcard value for ‘Access-Control-Allow-Origin: ‘ willaccept any CORS request from any domain. This should be used very carefullyand not used on private sites.

Access-control Based on Origin header: Origin header can be spoofed anddevelopers should add another step to verify that the Origin header matches theHost header.

Site-level cross-origin access: Using CORS within your own domain should beconfigured with care seeing that misconfiguration could allow foreign domains toaccess.

Prolonged caching of preflight result: If a client has cached the preflight re-sponse for an period of time, the client will remember that policy even if it hasbeen changed on the server side. Therefore Access-Control-Max-Age should be setto less than 30 minutes to avoid this.

3.5.4 Expected

Receiving Cross-origin resource request from http://dev.hampusaberg.com/corsAllow.phpto local test environment.

3.5.5 Results

As expected when trying to request http://dev.hampusaberg.com/corsAllow.phpfrom http://localhost/kandidat/index.php?p=cor with cortest.js, the request came

25

thru.

3.5.6 Conclusions

http://dev.hampusaberg.com/corsAllow.php contains:

1 <?php

2 header(’Access-Control-Allow-Origin: * ’);

3 echo ’Allow all foreign domains to access this page.’;

4 ?>

Access-Control-Allow-Origin: * specifies that any foreign host may request this siteas a resource for their site. This could be considered as a security misconfigurationif this apply for a web application with sensitive user information.It has been presented that Cross-origin Resource could be used combined combinedwith CSRF A8 as an attack vector. [15]

3.6 T4 - Clickjacking

ClickJacking [21] - User Interface redress attack is a technique to trick the web userinto clicking on something different from what the user might expect. This canbe used to perform an action with user’s credentials. ClickJacking is commonlyimplemented with iframes and different CSS settings to trick the user, such as theopacity option.

User might think he is interacting with the domain host(blue window) when he isactually clicking on the iframe(green window).

This can allow an attacker to perform actions as the user. Clickjacking has itslimitations:

• Can only inject user clicks

• Require user interaction

• Bypass Cross-site request forgery (CSRF)

• Can break if page layout changes

26

Figure 3.10: Example view of clickjacking with 60% opacity

3.6.1 Description

This test case will examine the usage of iframe and BreakSandBox() 5 and demon-strate a workaround for a FrameKiller. This test has an moderate association withA10 - Unvalited redirect and forwards from OWASP Top 10 2013.

3.6.2 Inputs

clickjack.html - Appendix D is a code snippet to demonstrate the usage ofcss to manipulate the user experience. the JavaScript function is used as aFrameKiller.

3.6.3 Expected

Load hampusaberg.com into an iframe with onload=Breaksandbox()

5JavaScript function, see Appendix D

27

3.6.4 Results

Succesfully loaded iFrame source http://dev.hampusaberg.com to the iframe.

3.6.5 Conclusions

The HTTP header option X-Frame-Option is used to prevent ClickJacking usingthe X-Frame-Options: DENY; X-Frame-Options: same-origin; iframe attributesandbox. [18]

28

Chapter 4

Discussion

This report is based on HTML5 versus OWASP top ten release 2013. We have de-veloped 4 test cases which highlighted 5 security problems associated with OWASPtop ten 2013. Our test cases may give the impression that HTML5 is not secure.This is done intentionally to increase the awareness, we do however believe thatHTML5 is not negative from a security perspective. First of all it has started abig community and a lot of people are experimenting with security in HTML5.However its important that developers have security in mind when using thesenew features that HTML5 offers.

HTML5 is today (May 2013) in a candidate release for W3C. WHATWG wantsto keep working on the standard for a few more years before releasing an finalversion.[1]

The community and developers should keep on experimenting with HTML5 spec-ification in order keep an high security on the standard. By testing HTML5 andexperimenting W3C will be motivated to do further work and web applications willbenefit from this. HTML5 introduce a lot of new features and functionality, wecould not cover everything and decided to focus on security risks in the OWASPlist. This decision was made because of the fact that OWASP published theirfinal release on June 2013 which makes it highly relevant and up-to-date at thistime.

4.1 Analysis of results

In table 4.1 we can see that we implemented 5 out 10 security risks from the top10 list in 4 test cases. The security risks that were highlighted in our test cases is

29

Cross-site scripting, security misconfiguration, sensitive data exposure, cross-siterequest forgery and unvalidated redirects and forwards. This shows that HTML5snew features are clearly affecting web application security.

The results are based on empirical studies and the experimental test cases that wasconducted during this project. As shown in Table 4.1 we found 5 matches betweensecurity risks specified in OWASP top ten list and the test cases conducted.

OWASP risks T1 T2 T3 T4A1 InjectionA2 Broken Authentication and Session managementA3 Cross-site scripting xA4 Insecure direct object referenceA5 Security misconfiguration xA6 Sensitive data exposure xA7 Missing function level access controlA8 Cross-site request forgery (CSRF) xA9 Using Known Vulnerable ComponentsA10 Unvalidated redirects and forwards x

Table 4.1: Test cases results

Cross-site scripting is as described in the test case in section 3.3 a server-sideproblem but we choose to skip the server input sanitizer. This was chosen becausewe wanted to focus on the client-side since we are reviewing HTML5.This madethe results from this test slightly less worth than if we had a input sanitizer onthe server. But the test case generated a result and demonstrated the scenariowell.

The LocalStorage results in section 3.4.5 shows that if a script is included from anexternal host it will be executed as a part of the origin. This could potentially beexploited by someone who is hosting a script that people includes into their sites.Everyone trusts that the code that Google are hosting is safe and secure, but whatif their jQuery library were to include the same script as we used in the test case?Well a lot of sites would be affected and if any of those sites stored sensitive datain either LocalStorage och SessionStorage it would be stolen. This would definitelyviolate integrity of the users and developers should be careful with what scriptsthey include from external hosts. This is a test case which could arise awarenessvery much and it might be possible to develop it further and make it even moreremarkable.

Cross-Origin resource sharing may be one of the biggest features introduced toHTML5 from a developers point of view. A lazy developer may implement CORS

30

using Access-Control-Allow-Origin: *. This is the worst mistake the developer canmake allowing any foregin host to access their website to another. This opens aattack vector for one-way CSRF attacks using XMLHttpRequest. This is shown inthe test case therefore we recommend using Access-Control-Max-Age: and settingthis to 30 minutes or less to avoid session hijacking.

The fourth test case present clickjacking with HTML5 using arbitrary CSS3 func-tionality combined with nested iframes with the sandbox attribute. As mention inthe test case ClickJacking is used unbeknownst to the user to trick the user to doa action that was not attended. A website using this technique has only maliciousintent for the user. This has been around almost as long as the web has beenaround, this is just a new attack vector to interact with the user.

4.2 Research question

Can the security risks specified in OWASP top 10 release 2013 be exploited usingnew features introduced HTML5?” Answer is yes A3, A5, A6, A8 and A10 can beexploited with HTML5 functionality as presented in the test cases.

The security risks that were not implemented in our test cases should not be con-sidered to be unaffected by HTML5. We think Broken authentication and sessionmanagement could be affected by the new keygen tag and WebCrypto.

Injection though is considered a server-side problem and since HTML5 is focusingon client-side this wasn’t tested. Insecure direct object reference, missing functionlevel access control and using known vulnerable components was not tested becauselack of time. These risks is however not affected as obvious as the ones we testedand matched.

4.3 Analysis of methodology

The information study of the specification at WC3 and WHATWG was reallyimportant because it is the sources for the specification. We needed to read thespecification in order to gain knowledge about the new features and make it pos-sible for us to determine if they can be used to implement security risks in thetop 10 list. Furthermore we needed to study OWASP so that we got knowledgeabout the new security risks in the top 10 list. We think this information studywas necessary for us to get a good knowledge. We think our information study

31

could be optimized and maybe we should have focused on one of the specificationsources W3C or WHATWG. This decision is hard though, because W3C is the or-ganization who should set the standard of the web but WHATWG is the browservendors who are implementing the standards. This means that WHATWG hasthe last word, and can decide how they want to interpreter and implement thestandard.

The experimental test cases were done to test whether or not the new featuresreally could implement the security risks that we expected. The test cases werealso done to increase the awareness in the reader and for us to get some hands-onexperience. We believe that the reader will get a better understanding in boththe security risks and HTML5 by looking at our test cases. Another approach tothis project could have been to just try to implement a secure HTML5 site usingmost of the new features and check if there is any security flaws or improvementssince HTML 4. It would also be possible to test the security risks from OWASPon this fully implemented HTML5 site. This approach though would probably bevery time consuming.

32

Chapter 5

Conclusions

Our research question was Can the security risks specified in OWASP top 10 release2013 be exploited using new features introduced HTML5?” and as it is specifiedin the results we implemented 5 of those security risks. This means that whendeveloping with HTML5 it’s important to have security in mind to avoid imple-menting any of those security risks. We think that the awareness in the reader willbe increased after reading this report and looking at the results. Regarding thesecurity we think that it will be enhanced over time in HTML5 if the standard iskept alive and updated continuously.

Trying to predict the security aspect of HTML5 for web application may be ob-scure until it has reached a standard. Comparing HTML5 to HTML 4.01 has madethreats in some cases worse or eased, XSS is a good example for this. HTML5creates new attack vectors for cross-site scripting and made it worse. Two ofthose new vectors is used in the test case about Cross-site scripting. HTML5 hasbrought a lot of people together in different communities which is experimentingon the specifications. We believe this will result in better web applications whichare more secure. At last our main purpose of this project was to “review HTML5to determine if it will have any impact on web application security”. We weresuccessful with this and the results clearly shows that HTML5 is affecting webapplication security.

One goal of this report is to raise awareness and by proving how relevant securityis in HTML5 we think that this goal was achieved. Furthermore it is proven thatHTML5 can implement security risks published by OWASP.

33

Further work could include the new keygen 1 tag introduced in HTML5. Theoret-ically this could be used in order to create client certificate. This could then beused in the same way as server certificates is used when authenticating a serverusing SSL connection.2

This could potentially make authentication much securer. Another thing thatcould be included in further work is the WebRTC which we covered small partsabout in section 2.1.7. This is still a draft and we didn’t have time to reallydig deep into it, but it could also be a potential threat. As we mentioned thebrowsers should definitely ask the users for permission to start their webcam andmicrophone. Another interesting thing that could be included is to analyze thenetwork traffic between the browsers using WebRTC. The last thing that couldbe included in further work the DRM which we addressed in section 2.1.6. Thisis also just a draft right now, but there is a lot of discussions already on internetabout this.

1http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080714/

07ea5534/attachment.txt2StackOverflow discussion:

http://stackoverflow.com/questions/4501196/keygen-tag-in-html5

34

References

[1] W3C Candidate Recommendation 17 December 2012, accessed on May 2013from, http://www.w3.org/TR/html5/WHATWG Living Standard — Updated 5 May 2013, accessed on May 2013from, http://www.whatwg.org/specs/web-apps/current-work/

[2] W3C Web Storage,W3C Proposed Recommendation 9 April 2013, accessed onMay 2013 from http://www.w3.org/TR/webstorage/

[3] The Web Hypertext Application Technology Working Group (WHATWG),accessed on May 2013 from http://wiki.whatwg.org/wiki/FAQ#What.27s_

this_I_hear_about_2022.3F

[4] Michael Schmidt, Compass Security AG. (2011). HTML5 web security. ac-cessed on May 2013 from http://media.hacking-lab.com/hlnews/HTML5_

Web_Security_v1.0.pdf

[5] W3 Browser Statistics and Trends, accessed on May 2013 from http://www.

w3schools.com/browsers/browsers_stats.asp

[6] HTML5 Browser Test, accessed on May 2013 http://html5test.com/

results/desktop.html

[7] Web Workers, W3C Candidate Recommendation 01 May 2012, accessed onMay 2013 from http://www.w3.org/TR/workers/

[8] w3.org Media source extensionaccessed on May 2013 from http://www.w3.org/TR/media-source/

[9] Encrypted media extensions, W3C Editor’s Draft 4 June 2013, accessedon May 2013 from https://dvcs.w3.org/hg/html-media/raw-file/tip/

encrypted-media/encrypted-media.html

[10] Web Cryptography API, W3C Working Draft 8 January 2013, accessed onMay 2013 from http://www.w3.org/TR/WebCryptoAPI/

35

[11] WebRTC 1.0: Real-time Communication Between Browsers, W3C Editor’sDraft 03 June 2013, accessed on May 2013 from http://dev.w3.org/2011/

webrtc/editor/webrtc.html

Project website: http://www.webRTC.org/

[12] Open Web Application Security Project,accessed on May 2013 from https://www.owasp.org/

https://www.owasp.org/index.php/Top_10_2013

[13] OWASP HTML5 Security cheat sheet, accessed on May 2013 from https:

//www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

[14] D.Stuttard, M.Pinto, Web Application Hacker’s Handbook Second Edition,Chapter 12, ISBN 978-1118026472

[15] Blueinfy, Shreeraj Shahaccessed on May 2013 from http://shreeraj.blogspot.se/

[16] HTML5sec.org, accessed on May 2013 from http://www.html5sec.org/

[17] Trend Micro, Research Paper 2011, HTML5 Overview: A look at HTML5attack scenariosaccessed on May 2013 from http://www.trendmicro.com/cloud-

content/us/pdfs/security-intelligence/reports/rpt_html5-attack-

scenarios.pdf

[18] Iframe w3.org Editor’s Draft, access on May 2013 from http:

//www.w3.org/html/wg/drafts/html/master/embedded-content-

0.html#the-iframe-element

Mike West, HTML5 Rocks,Play safely in sandboxed IFrames, Ar-ticle,Published Jan. 4, 2013 , accessed on May 2013 from http:

//www.html5rocks.com/en/tutorials/security/sandboxed-iframes/

[19] XMLHttpRequest, W3C Working Draft 6 December 2012, accessed on June2013 from, http://www.w3.org/TR/XMLHttpRequest/

[20] Ilya Grigorik, High Performance Browser Networking, O’Reily Media,[EarlyRelease Ebook] Accessed on May 2013 from http://chimera.labs.oreilly.

com/books/1230000000545/index.html

[21] Gustav Rydstedt, Elie Bursztein, Dan Boneh, Collin Jackson, Busting FrameBusting: a Study of Clickjacking Vulnerabilities on Popular Sites, accessed onMay 2013 fromhttp://cdn.ly.tl/publications/busting-frame-busting-a-study-of-

clickjacking-vulnerabilities-on-popular-sites.pdf

Appendices

Appendix A

Test case 1 Cross-site Scripting

Used in test case 1. file name xss.php

Listing A.1: Appendix A - XSS test case 1

1 <form id="xss" method="post">

2 <label for="xss">Input:</label>3 <input type="text" name="xss"></input>

4 <input type="submit" value="Submit" id="submit"></input>

5 <p>

6 <input type="text" value=<?php if(isset($_POST[’xss’])) echo$_POST[’xss’]; ?> ></input>

7 </p>

38

Appendix B

Test case 2 Localstorage

Used in test case 2. file name localstorage.js

Listing B.1: Appendix B - LocalStorage external script test case 2

1 var lsvalue = [];

2 var lskey = [];

3 for (i=0; i<localStorage.length; i++)

4 {

5 lskey[i] = localStorage.key(i);6 lsvalue[i] = localStorage.getItem(lskey[i]);

7 }

8 for(var i=0; i<localStorage.length; i++) {

9 console.log("Key: " + lskey[i] + " Value: " + lsvalue[i]);

10 $.ajax({

11 url: "http://localstorage.hampusaberg.com/lsave.php",

12 data:{

13 ’key’: lskey[i],

14 ’value’: lsvalue[i]

15 },

16 }).done(function( data ) {

17 console.log(data);18 });

19 }

39

Used in test case 2. file name lsave.php

Listing B.2: Appendix C - Save localStorage entries in SqlLite

1 <?php

2 header(’Access-Control-Allow-Origin: *’);

3 echo ’Allow all foreign domains to access this page.’;

4 if ( isset ($_GET["key"]) && isset($_GET["value"])){5 $key = $_GET["key"];

6 $value = $_GET["value"];

7 echo $key, $value;

8 $file = dirname(__FILE__) . "/db/db.sqlite";

9 $db = new PDO("sqlite:$file");

10 $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING); // Display

errors, but continue script

11 $stmt = $db->prepare("INSERT INTO localstorage VALUES(NULL , ’$key’,

’$value’);");

12 $stmt->execute();

13 $stmt = $db->prepare(’SELECT * FROM localstorage;’);

14 $stmt->execute();

15 $res = $stmt->fetchAll(PDO::FETCH_ASSOC);

16 }

17 ?>

40

Appendix C

Test case 3 CORS

Used in test case 3. file name cortest.js

Listing C.1: Appendix D - COR javascript

1 // Create the XHR object.

2 function createCORSRequest(method, url) {

3 var xhr = new XMLHttpRequest();

4 if ("withCredentials" in xhr) {

5 // XHR for Chrome/Firefox/Opera/Safari.

6 xhr.open(method, url, true);7 } else if (typeof XDomainRequest != "undefined") {

8 // XDomainRequest for IE.

9 xhr = new XDomainRequest();

10 xhr.open(method, url);

11 } else {

12 // CORS not supported.

13 xhr = null;

14 }

15 return xhr;

16 }

17 // Helper method to parse the title tag from the response.

18 function getTitle(text) {

19 return text.match(’<title>(.*)?</title>’)[1];

20 }

21 // Make the actual CORS request.

22 function makeCorsRequest() {

23 // All HTML5 Rocks properties support CORS.

24 //var url = ’http://updates.html5rocks.com’;

25 var url = document.getElementById(’url’).value;

41

26 console.log(url);27 document.getElementById(’status’).innerHTML = "fetching data from "

+ url;

28 var xhr = createCORSRequest(’GET’, url);

29 if (!xhr) {

30 //alert(’CORS not supported’);

31 document.getElementById(’status’).innerHTML =’CORS not supported’;

32 $(’#status’).removeClass("label-success");

33 $(’#status’).addClass("label-warning");

34 return;

35 }

36 // Response handlers.

37 xhr.onload = function() {

38 var text = xhr.responseText;

39 document.getElementById(’results’).innerHTML = xhr.responseText;

40 var title = getTitle(text);

41 //alert(’Response from CORS request to ’ + url + ’: ’ + title + ’

CORS CONF ’ +corsconf);

42 $(’#status’).removeClass("label-warning");

43 $(’#status’).addClass("label-success");

44 document.getElementById(’status’).innerHTML =’Response from CORS

request to ’ + url;

45 };

4647 xhr.onerror = function() {

48 //alert(’Woops, there was an error making the request.’);

49 document.getElementById(’status’).innerHTML =’Woops, there was an

error making the request.’;

50 $(’#status’).removeClass("label-success");

51 $(’#status’).addClass("label-warning");

5253 };

54 xhr.send();

55 }

56 $(’#test’).click(function(){

57 makeCorsRequest();

58 });

42

Appendix D

Test case 4 Clickjacking

Used in test case 4. file name clickjack.html

Listing D.1: Appendix E - ClickJack Example

1 ...

2 <script type="javascript/text">

3 function breakSandbox() {

4 var doc = window.frames.loader.document;

5 var html = ’’;

6 html += ’<p>inline iframe in another iframe</p><iframe

src="//dev.hampusaberg.com/corsAllow.php" id="iframe"

7 name="iframe"

onload="alert(window.frames.iframe.document.getElementsByTagName

8 (\’body\’)[0].innerHTML);

9 alert(window.frames.iframe.document.cookie);"></iframe>’;

10 doc.body.innerHTML = html;

11 }

12 </script>

1314 <div id="blue" style="background:blue; width:350px; height:300px;">

15 <div

16 style="background:green; width:250px;

17 height:250px; opacity:0.5; z-index:1; position:absolute; top:150px;

overflow:hidden; left:250px;">

18 <span style="font-weight:bold; color:yellow;">cross domain

iframe</span>

19 </div>

20 </div>

21 ...

43