xss – cross site scripting · • cross-site scripting (xss ) is a type of computer security...

XSS – Cross Site Scripting

Jörg SchwenkHorst Görtz InstituteRuhr-University Bochum

Dagstuhl 2009

http://en.wikipedia.org/wiki/Cross-site_scripting

• Cross-site scripting (XSS) is a type of computer securityvulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites accounted for roughly 80.5% of all security vulnerabilities documented by Symantec as of 2007.[1] Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner.

Overview

1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents

Browser-based protocols

Internet

Webserver

AJA

X e

ngin

e

Ren

derin

g

Java

scrip

tF

lash

Rea

l

PD

F

Mal

war

e

ApplicationServer

Database

DNS

PKI


Internet

Webserver

AJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

ApplicationServer

Database


2: HTML+JS

www.example.orgAJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

1

www.css-repos.com

library.js.net

4: CSS

3

6: JS-Lib

5

Web Origins and Browser DOM

window

document document.location

HTML www.example.orgloaded from

defines

JS www.example.orgloaded from

CSS www.css-repos.comloaded from

JS-Lib library.js.netloaded from

body

grants accessrights to originwww.example.org

Browser-based Cryptographic protocols: SOP (Same Origin Policy)

Document1

Cookies Form

Name Account Amount

Schwenk 443232 66,43

Script1

Document2

Script1:GetCookie

Script2:ModifyAccount

Script3:Send/Requestdata

SOP

Origin: https://banking.bank.com:443 Origin: http://attacker.org:80

Access Denied

Overview


Reflected XSS (non-persistent)

• Angreifer übergibt Skriptcode über einen eigens präparierten Hyperlink an das Opfer

• Typisches Angriffsziel: Suchfunktionen in Webseiten


• Normale URL, die eine Suche auf der Webseite triggert: http://example.com/?suche= Suchbegriff

• Resultat: <p>Sie suchten nach: Suchbegriff</p>

• Präparierte URL: http://example.com/?suche=<script type="text/javascript">alert("XSS")</script>

• Resultat: <p>Sie suchten nach: <script type="text/javascript">alert("XSS")</script></p>


AJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

victim.com

attacker.org

4: HTML +JS-XSS(active)

3: GET+JS-XSS

2: HTML + JS-XSS (inactive)

1

Overview


Stored XSS (persistent)

Beispiel eBay

Phisher erstellt AngebotBettet im Angebot „bösartigen“

Code einCode kompromittiert „Bieten-

Button“Benutzer wird zur Eingabe seiner

Zugangsdaten aufgefordert, wobei diese Seite vom Angreifer stammt

Benutzer gibt seine Zugangsdaten preis

Quelle: http://www.heise.de/security/result.xhtml?url=/security/news/meldung/54272&words=eBay%20Scripting

Stored XSS (persistent)

AJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

victim.com

attacker.org

3: HTML +JS-XSS

2: GET

1: HTML + JS-XSS

1

Overview


DOM based XSS (Local XSS)

Consider the following webpage located at http://www.vulnerable.site/welcome.html

<HTML><TITLE>Welcome!</TITLE>Hi<SCRIPT>var pos=document.URL.indexOf("name=")+5;document.write(document.URL.substring(pos, document.URL.length));</SCRIPT><BR>Welcome to our system…

</HTML>

Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml


Typical use:http://www.vulnerable.site/welcome.html?name=Joe

<HTML><TITLE>Welcome!</TITLE>Hi<SCRIPT>var pos=document.URL.indexOf("name=")+5;document.write(document.URL.substring(pos, document.URL.length));</SCRIPT><BR>Welcome to our system…

</HTML>



Result of:http://www.vulnerable.site/welcome.html?name=Joe

<HTML><TITLE>Welcome!</TITLE>HiJoe

<BR>Welcome to our system…

</HTML>



Result of:http://www.vulnerable.site/welcome.html?name=

<script>alert(document.cookie)</script>

<HTML><TITLE>Welcome!</TITLE>Hi<script>alert(document.cookie)</script>

<BR>Welcome to our system…

</HTML>



Avoid detection by server side filtering:http://www.vulnerable.site/welcome.html #name=

<script>alert(document.cookie)</script>

• # indicates that the string following this character is a fragment identifier, i.e. it is only an indication to the browser which part of the document to display

• The string following # is thus never sent to the server, but it is stored in DOM-properties like document.location or document.URL



AJA

X e

ngin

e

Ren

derin

g

Java

scrip

t

victim.com

attacker.org

4: HTML

3: GET

2: HTML + JS-XSS (inactive)

1: GET

<a href= ″http://www.vulnerable.site/welcome.html#name= <script>alert(document.cookie)</script> ″>Klick me!</a>

GET welcome.html HTTP 1.1host: www.vulnerable.site

5: XSS executed during (local) rendering

Overview


Server Side: Blocking

• If unsolicited content (e.g. Overlong cookies) is detected, processing of the http request is blocked.

• Instead, e.g. A static webpage can be displayed.

• Can be misused to perform DoS attacks:– Vela 2009: Overlong Google Analytics tracking code snippets

Server Side: Stripping and Replacing

• PHP strip_tags() removes potentially dangerous characters from user input

• If this seems too rigid, $allowable_tags can be defined; this may open doors for XSS in single web applications

• Stripping substrings is complex: e.g. Stripping „fromCharCode “from „fromCfromCharCodeharCode “

• Character replacement is more reliable, but can nebertheless be circumvented (Amazon AWS attack)

Server Side: Escaping

• Potentially dangerous characters like < are prepended with a backslash character: \<

• Potential problems with unicode characters may lead to SQLi• innerHTML and CSS attacks

Server Side: Encoding

• PHP htmlentities() and htmlspecialchars() encode potentially dangerous characters

• May be bypassed with e.g. UTF7 encoding of attack vectors: +Adw-script+AD4-alert(1)+Adw-/script+AD4-

Server Side: Rewriting

• HTMLPurifier for PHP, AntiSamy for Java, SafeHTML for Windows Server environments

• Web application want to allow posting of harmless HTML• Different approaches:

– Only regular expressions: broken– HTMLPurifier: Build new DOM tree, match this tree aganinst

XHTML DTD, remove non-matching elements– Google Caja: rewrites Javascript (+HTMl + CSS) code, may

result in code expansion (1 line -> 130 lines)

Client Side Filtering

• Server does not see complete code that is rendered by the browser– innerHTML– DOM XSS– Flash Parameters

• Therefore, client side filtering is applied

Client Side: IE XSS Filter

• Checks for matches between Request URL fragments and the resulting HTML markup

• Problems with detecting fragmented attack vectors (because they are only completed by the markup parser)

Markup Parser

Network Stack

IE XSS Filter

Request URL

HTML Markup

Client Side: Webkit/Google Chrome XSS Auditor

• Works similar to IE XSS Filter

• Different position

HTML Parser

Network Stack

Webkit XSS Auditor

JavascriptEngine

Client Side: NoScript XSS Filter (Firefox)

• Rewrites URL parameters if URL request goes to a trusted site

• insecure.php?a="><img/src= onerror=alert(1)

• Is changed to• insecure.php?a=>

img%2Fsrc= ONERROR=ALERT 1 #some_random_number

HTML Parser

Network Stack

NoScript

Request URL to Trusted Site

Rewritten URL to Trusted Site

Content Security Policyhttps://wiki.mozilla.org/Security/CSP/Specification

• Example 2: Auction site wants to allow images from anywhere, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from its server hosting sanitized JavaScript:

X-Content-Security-Policy: allow 'self'; img-src *; object-src media1.com media2.com *.cdn.com;

script-src trustedscripts.example.com

• Example 4: Online payments site wants to ensure that all of the content in its pages is loaded over SSL to prevent attackers from eavesdropping on requests for insecure content:

X-Content-Security-Policy: allow https://*:443

IFrame Sandboxing

Sandboxed Iframes: New feature in HTML5• No script execution• No plugin execution• No top oder parent access• No form submissions• ... Only display static HTML• ... But this can of course be relaxed ☺

Javascript Sandboxing

• JSReg: purely written in Javascript, uses regular expressions, often broken.

• Dojo Sandbox: blocks access to sensitive DOM properties, broken in 2010 (e.g. Unicode escapes)

• Rhino and LiveConnect: Run Javascript inside an Java applet, which has its own Javascript parser – should be safe, broken by Heiderich et.al.

• JSAgents/IceShield: see below

Overview


Microsoft Identity Managment

Jörg SchwenkLehrstuhl für Netz- und

Datensicherheit

38

Ausblick: Cross Site Request Forgery

Schritt 2: Einloggen des Opfers bei Hotmail.

nytimes.com

attacker.org

Victim

1: Login auf NY Times Webseite

2: Anschauen der Webseite des Angreifers

3: http-Link (z.B. in einem <img>-Tag) enthält Query-String mit dem Befehl,eine E-Mail an [email protected] zu senden.

http://www.freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

Microsoft Identity Managment

Jörg SchwenkLehrstuhl für Netz- und

Datensicherheit

39

Ausblick: Cross Site Request Forgery

http://www.freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks

1. ING Direct (ingdirect.com)– Status: Fixed

2. YouTube (youtube.com)– Status: Fixed

3. MetaFilter (metafilter.com)– Status: Fixed

4. The New York Times (nytimes.com)– Status: Fixed.

xss – cross site scripting · • cross-site scripting (xss ) is a type of computer security...

Documents