Upload
trinhnhi
View
232
Download
6
Embed Size (px)
Citation preview
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
Browser-based protocols
Internet
Webserver
AJA
X e
ngin
e
Ren
derin
g
Java
scrip
t
ApplicationServer
Database
Browser-based protocols
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
1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents
Reflected XSS (non-persistent)
• Angreifer übergibt Skriptcode über einen eigens präparierten Hyperlink an das Opfer
• Typisches Angriffsziel: Suchfunktionen in Webseiten
Reflected XSS (non-persistent)
• 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>
Reflected XSS (non-persistent)
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
1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents
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
1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents
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
DOM based XSS (Local XSS)
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>
Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
DOM based XSS (Local XSS)
Result of:http://www.vulnerable.site/welcome.html?name=Joe
<HTML><TITLE>Welcome!</TITLE>HiJoe
<BR>Welcome to our system…
</HTML>
Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
DOM based XSS (Local XSS)
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>
Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
DOM based XSS (Local XSS)
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
Amit Klein, http://www.webappsec.org/projects/articles/071105.shtml
DOM based XSS (Local XSS)
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
1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents
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
1. Web Origins, Browser DOM and the Same Origin Policy2. Reflected XSS3. Stored XSS4. DOM XSS5. Classical Countermeasures6. JSAgents
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.