
2/19

CSRF DEFINED

CSRF DEFINITION

CSRF occurs when a malicious Web site causes a

users Web browser to perform an unwanted actionon a trusted site

CSRF is also known as Cross-Site Reference attack,One-Click attack, Sidejacking, or Session Riding

4


3/19

Authenticated session

The Web browser has established anauthenticated session with the Trusted site

5

CSRF ILLUSTRATED


The Web browser tries to perform a

trusted action initiated by the user

6


4/19


CSRF: The Attacking site causes the browser tosend a request to the Trusted site. The attack ispossible because the Trusted site authenticates

the browser, not the user

7

XXSVERSUS CSRF

Contrary to Cross-Site Scripting (XSS), which exploitsthe trust a user has for a particular site, CSRF exploitsthe trust that a site has for a particular user

It is not necessarily true that defenses against XSS alsoprotect against CSRF

8


5/19

SIMPLIFIED CSRF EXAMPLE

E-MAIL SYSTEM EXAMPLE

We consider a fictitious e-mail system example.comthat allows users to send mail from their browsers

10


6/19

HTML FORM IN BROWSER

To:

Subject:

Message:

CSRF

[email protected]

When the user clicks Send

the e-mail is sent in a HTTPGET request

Send

11

Web page http://

example.com/

compose.htm

Contains a HTMLform to send e-mail

GET REQUEST

The HTML form causes a GET request to append theform data to an URL:

http://example.com/send_email.htm?

to=bob%40example.com&subject=CSRF&

msg=When+the+user+...

The page send_mail.htmtakes the URL data and

generates an e-mail to the recipient from the user

12


7/19

VULNERABILITY!

The page send_mail.htmsimply performsactions with the received data

It does not care where the request originated

In fact, a user could manually type theURL in the browsers address bar

13

POSSIBLE ATTACK

If an attacker can force the users browser to send

a HTTP GET request to send_mail.htm, thenthis page will send an e-mail on the users behalfcontaining data chosen by the attacker

14


8/19

ATTACK ILLUSTRATION

15

User causes browser to loadWeb page from site controlledby an attacker

Request page

MALICIOUS WEB PAGE

16

Malicious Web pages uses HTML tag tosend a fake e-mail


9/19

ATTACK ILLUSTRATION ...

17

Downloaded malicious Webpage generates fake e-mail

Fake e-mail

IMPORTANT OBSERVATION

The attack can typically carry out the same actionsas the user

Hence, the more power a site gives to a user, themore serious are possible CSRFs

18


10/19

CSRF AND AUTHENTICATION

AUTHENTICATIONVULNERABILITIES

CSRF exploits the authentication mechanism,or the lack of such a mechanism, at a Web site

Usually, the authentication only ensures thata request is from the users browser, not thatthe user actually initiated the request

20


11/19

Username + password

21

EXAMPLE:EXPLOITING SESSION COOKIE

Step 1: When the user points the browserto the Trusted site, he is asked to log on

Browser cookie

22

EXAMPLE ...

Step 2: Trusted site registers that theuser is logged in and sets a session cookie

containing a session identifier in the Webbrowser


12/19

Malicious Web page

23

EXAMPLE ...

Step 3: User visits attacker-controlled site and downloadsWeb page with malicious code

Cookie for Trusted site

Malicious request

24

EXAMPLE ...

Step 4: Browser renders maliciousWeb page and generates request toTrusted site. Browser automaticallyadds session cookie to request.


13/19

DISCUSSION

CSRF is successful because the browserautomatically adds the session cookie tothe request

Other possible attacks can exploit stored

passwords or (semi-) permanent cookiesin the browser

25

SSL DOESNT PREVENT ATTACK

CSRF is possible because the SSL sessionis only linked to the browser

Note that the users browser must accessthe attacking site while the SSL session isactive

SSL session

26


14/19

CSRF ATTACK VECTORS

ATTACK VECTORS

User must be logged into Trusted site and visit

Attacking site

If Trusted site accepts GET requests, then the

tag can be used to generate a maliciousrequest

If Trusted site only accepts POST requests, thenit is necessary to use a JavaScript to generate

a malicious request

28


15/19


16/19

COUNTERMEASURES

SERVER-SIDE DEFENSE

1. Allow a GET request to only retrieve data, notmodify data on the server

This protects sites from CSRF using tags or other types of GET requests

Recommendation follows RFC 2616

32


17/19

SERVER-SIDE DEFENSE ...

2. Require all POST requests to include a pseudo-random value

Cryptographically strong value should be set asa cookie in the users browser and be includedin every form submitted to the server

The server should only accept POST request ifthe random values in the cookie and the formare equal

Attacker doesnt have access to cookie

33

SERVER-SIDE DEFENSE ...

In order to allow a user to have multiple formsopen on a site, the random value should be usedby all forms during a certain amount of time

34


18/19

CLIENT-SIDE DEFENSES

Log out immediately after a task has been completed

Do not start other tasks while a sensitive task isperformed

Never store usernames/password in browser

35

CONCLUSION


19/19

SIGNIFICANT PROBLEM

Numerous Web sites seem to be vulnerable to CSRF

Only standard programming techniques are neededto implement attacks

Consequently, CSRF is a significant problem that alldevelopers need to take seriously

37

SOURCE

W. Zeller and E. W. Felten, Cross-Site RequestForgeries: Exploitation and Prevention, TechnicalReport, Princeton University, 2008;

www.freedom-to-tinker.com/sites/

default/files/csrf.pdf

csrf(Crosss-Site Request Forgeries)

Documents

Transcript of csrf(Crosss-Site Request Forgeries)