State-Based Attacks CPSC 328 Spring 2009 State Web is “stateless” Server does not care what page or order Can follow any sequence of clicks to view content Can go straight to content External links URL typing 1
Saving State What if our service requires certain order? Must log in before accessing admin page What if server must keep track of things What you ordered, did you pay? How can Developer do this? Include additional information with each exchange (GET request) Forms, POST, URL parameters Hidden Fields Something that is part of page, but not shown Defined parameters & assigned values Sent back to server to communicate state Part of a form 2
Hidden Field Example <html> <head> <title>My Page</title> </head> <body> <form name="myform” action="http://www.foo.com/form.php” method="POST"> <div align="center"> <input type="text" size="25" value="Enter your name here!"> <input type="hidden" name="Language” value="English"> <br><br> </div> </form> </body> </html> Hidden Field Attack Look for them (scan source) Change their values 3
Protection - Hidden Fields Use misleading names for hidden fields Use hashed/encrypted values Don’t use them! Use them for innocuous input only Treat as user input! Check their values (content filtering again) CGI Parameters Part of the GET request with URL Name-Value pairs At end of URL (after ?) Pairs separated by & http://www.foo.com/script.php?user=mike&passwd=guessWho Data is sent to server for processing 4
Parameter Attack View source Observe URL targets In status bar In tool tip Edit request URL by hand http://www.foo.com/script.php?user=mike&passwd=bigDummy Parameter Attack Try changing values record=notMine item=6789 Adding parameters debug=on debug=true debug=1 5
Protection - Paramters Treat as user input! Check values (content filtering again) GET - POST, Who-What? Both send info to server GET Per W3C, for idempotent form processing No side-effect (e.g., database search) POST For transactions that change state on server Have a side-effect (e.g., database update/insertion) For sending large requests Reload/refresh a GET vs a POST form - different behaviors 6
Cookie Poisoning How to Off the Cookie Monster Cookies revisited Local file to store data Data about you, session, etc… Plain text Change information in cookie file Expiration date Authentication data Shopping cart Protection - Cookies Don’t use cookies for any authentication data Encrypt critical data - not fool proof Treat cookies as user input Be careful what you trust! 7
URL Jumping Breaking the standard (required) order of site traversal Access without logging in Shopping without paying Map the site, then try leaping around A10: Poor URL Restriction How do you protect a page for limited access? Don’t provide links to that page? Just because there’s no link, doesn’t mean people can’t find it Worse yet, that they won’t be able to access it! Security through obscurity does not work 8
Protection - URL Restriction Restrict all URLs unless public Don’t leave php/perl/cgi files around Don’t use “hidden” pages Block access to non-web pages Serve only known good (.html, .php, .asp, .pdf, …) Hidden Fields Cookies HTTP-REFERRER Server-Side Variables Validate client side input! Session Hijacking Making the stateless Web, more state-ful Keep track of the session between client & server with a unique identifier Session ID included with each request from client Session IDs delivered via… Hidden Fields, Cookies, CGI Parameters 9
Hijack Attack Guess Session IDs Sniff the wire to capture an ID XSS to capture a session ID cookie Session Fixation Sniffing the Wire & Guessing IDs Listen to unencrypted traffic Observe pattern in ID values, guess the next one 10
Fixation XSS 11
Protection - Session Hijacking Use cookies rather than hidden fields Send securely When user logs out, delete session Use meaningful cookie expirations 12
Recommend
More recommend
