XSS – Cross Site Scripting

Transcription

XSS – Cross Site Scripting
Jörg Schwenk
Horst Görtz Institute
Ruhr-University Bochum
Dagstuhl 2009
http://en.wikipedia.org/wiki/Crosssite_scripting
• Cross-site scripting (XSS) is a type of computer security
vulnerability 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.
2.
3.
4.
5.
6.
Web Origins, Browser DOM and the Same Origin Policy
Reflected XSS
Stored XSS
DOM XSS
Classical Countermeasures
JSAgents
DNS
AJAX engine
Real
Malware
PDF
Rendering
Javascript
Flash
Browser-based protocols
Internet
Webserver Application Database
Server
PKI
AJAX engine
Javascript
Rendering
Internet
Webserver Application Database
Server
AJAX engine
Javascript
Rendering
3
4: CSS
www.css-repos.com
1
2: HTML+JS
www.example.org
5
6: JS-Lib
library.js.net
Web Origins and Browser DOM
window
document
document.location
body
defines
HTML
JS
CSS
JS-Lib
loaded from
loaded from
loaded from
loaded from
www.example.org
www.example.org
www.css-repos.com
library.js.net
grants access
rights to origin
www.example.org
Browser-based Cryptographic protocols:
SOP (Same Origin Policy)
Document1
Cookies
Name
Schwenk
Document2
Form
Account
443232
Script1
Script1:
GetCookie
Amount
Script2:
Modify
Account
Script3:
Send/
Request
data
66,43
Origin: https://banking.bank.com:443
Access Denied
SOP
Origin: http://attacker.org:80
Overview
1.
2.
3.
4.
5.
6.
Reflected XSS
Stored XSS
DOM XSS
JSAgents
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>
3: GET+
JS-XSS
AJAX engine
Javascript
Rendering
victim.com
4: HTML +
JS-XSS
(active)
1
2:
HTML +
JS-XSS
(inactive) attacker.org
Overview
1.
2.
3.
4.
5.
6.
Reflected XSS
Stored XSS
DOM XSS
JSAgents
Stored XSS (persistent)
Beispiel eBay
Phisher erstellt Angebot
Bettet im Angebot „bösartigen“
Code ein
Code kompromittiert „BietenButton“
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)
2: GET
AJAX engine
Javascript
Rendering
victim.com
3: HTML +
JS-XSS
1:
HTML +
JS-XSS
1
attacker.org
Overview
1.
2.
3.
4.
5.
6.
Reflected XSS
Stored XSS
DOM XSS
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
Typical use:
http://www.vulnerable.site/welcome.html?name=Joe
<HTML>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,
document.URL.length));
</SCRIPT>
<BR>
…
</HTML>
Result of:
http://www.vulnerable.site/welcome.html?name=Joe
<HTML>
Hi
Joe
<BR>
…
</HTML>
Result of:
http://www.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>
<HTML>
Hi
<BR>
…
</HTML>
Avoid detection by server side filtering:
http://www.vulnerable.site/welcome.html#name=
• # 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
GET welcome.html
3: GET HTTP 1.1
host: www.vulnerable.site
AJAX engine
Javascript
Rendering
victim.com
4: HTML
5: XSS executed during
(local) rendering
1: GET
2:
HTML +
<a href=″http://www.vulnerable.site/welcome.html#
JS-XSS
name= <script>alert(document.cookie)</script>″>Klick
me!</a>
(inactive) attacker.org
Overview
1.
2.
3.
4.
5.
6.
Reflected XSS
Stored XSS
DOM XSS
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
Request URL
IE XSS Filter
HTML Markup
Network Stack
Client Side: Webkit/Google Chrome XSS
Auditor
• Works similar to IE XSS
Filter
• Different position
HTML
Parser
Webkit
XSS
Auditor
Network Stack
Javascript
Engine
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
Request URL to Trusted Site
NoScript
Rewritten URL to Trusted Site
Network Stack
Content Security Policy
https://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.
2.
3.
4.
5.
6.
Reflected XSS
Stored XSS
DOM XSS
JSAgents
Ausblick: Cross Site Request Forgery
Schritt 2: Einloggen des Opfers bei
Hotmail.
1: Login auf NY Times Webseite
3: http-Link (z.B. in einem <img>-Tag)
enthält Query-String mit dem Befehl,
eine E-Mail an collect@attacker.org
zu senden.
Victim
38
nytimes.com
2: Anschauen der Webseite des Angreifers
http://www.freedom-totinker.com/blog/wzeller/popular-websitesvulnerable-cross-site-request-forgery-attacks
Microsoft Identity
Managment
Jörg Schwenk
Lehrstuhl für Netz- und
Datensicherheit
attacker.org
Ausblick: Cross Site Request Forgery
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.
39
http://www.freedom-totinker.com/blog/wzeller/popular-websitesvulnerable-cross-site-request-forgery-attacks
Microsoft Identity
Managment
Jörg Schwenk
Lehrstuhl für Netz- und
Datensicherheit

XSS – Cross Site Scripting

Transcription

Similar documents

Angriffsvektor JavaScript

XSS Cheat Sheet from Adobe