Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

Cross-Site Request Forgery

Vladimir Polumirace-mail: v.polumirac@sbb.rsblog: d0is.wordpress.comFB: facebook.com/vpolumiracTwitter twitter.com/d0is

23/07/2012

OWASP 2

Content

1) INTRODUCTION2) WEB APPLICATION SECURITY3) CSRF ATTACKS4) DEFENSES 5) CONCLUSION

OWASP

1. INTRODUCTION

Cross-Site Request Forgery (CSRF) - malicious use of user rights in which the

unauthorized user to transmit commands over the locations which the user believes

- ranking in the OWASP top 10 and the CWE/SANS top 25

Note: Common Weakness Enumeration (CWE)

3

OWASP

1. INTRODUCTION

Exploits implicit authentication mechanisms Known since 2001 XSRF a.k.a. CSRF a.k.a. “Session Riding”

(a.k.a. “Sea Surf”) Unknown/underestimated attack vector

(compared to XSS or SQL injection)The Attack: The attacker creates a hidden http request inside

the victim’s web browser This request is executed in the victim’s

authentication context

4

OWASP

WEB APPLICATION SECURITY

5

OWASP

2.1 CSRF Demonstration

6

OWASP

2.1 CSRF Demonstration

7

OWASP

2.2 Attack characteristics

Conditions:I. page that the attack does not check the source

of messages, or HTTP referrer header orII. Web browser allows users faking the headerIII.uses the HTTP request that such change is

performed on the attacked site or user account (for example password change), 

IV.attacker has access authentication cookies and security badges by which accessing the site and 

V.the attacker is in able to specify the victim to open a malicious web links.

8

OWASP

2.3 Potential riscs

CSRF is not so easily done But the problem with CSRF is that the scope of

its consequences is practically unlimited Any action that may be on the web to perform

URL links, or by submitting a web form:I. publishing content on blogs and forums on

behalf of users,  sending different messages, II.on-line shopping, III.subscription to the virtual content etc.

9

OWASP

2.4 Related attacks

Distinguishing between CSRF and XSS- Myth: CSRF is just a special case of XSS. - Fact: CSRF is a separate vulnerability from XSS,

with a different solution. XSS protections won’t stop CSRF attacks, although XSS are important to solve and should be prioritized

a. While XSS attacks using the trust that the user has a web site, CSRF attacks abusing the trust that has a web site to users.

b. CSRF attack and are much more dangerous, unpopular (which means less resources for developers) and much harder to defend against XSS attacks.

10

OWASP

3. CSFR ATTACKS

CSRF attacks can be carried out in various ways: 

I. use maliciously formed HTML objects II.using scripting code embedded in HTML

(JavaScript, PHP, JScript, ...) and abuse III.Automatic generation of application in a

web browser (XMLHttpRequest).

11

OWASP

3.1 Attacks HTML objects

By HTTP GET methods

input fake code in attribute ”src” request to another web location

input fake code in attribute ”src” in SCRIPT and FRAME object request to another web location

12

<img src=”picture.gif" alt=”Picture" title=" Picture " />

<img src="http://server/false_request"/>

<iframe src=" http://server/false_request"/>

<script src=“http://server/false_request"/>

OWASP

3.2 Attacks scripting code Example abusing by object Image()

By object ActiveXObject in Microsoft JScript

13

<script>var picture = new Image();picture = http://server/false_request“;<script>

<script>var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");xmlhttp.open("POST", 'http://server/fake_code', true);xmlhttp.onreadystatechange = function () {if (xmlhttp.readyState == 4){alert(xmlhttp.responseText); } };xmlhttp.send(null);</script>

OWASP

3.3 Attacks XML HTTP Request

an API available in web browser script languages such as JavaScript

 important role in the Ajax web development technique

14

<script>xmlhttp=new XMLHttpRequest() ;xmlhttp.open(“GET”, “http://urlAdress”,true);xmlhttp.onreadystatechange = writeAnswer();xmlhttp.send(null);function writeAnswer(xmlhttp,element_id){var element = document.getElementById(element_id);if (xmlhttp.readyState == 4){var tekst = http.responseText;dokument.write.text;} }</script>

OWASP

3.4 CSRF with AJAX Attack

AJAX calls can enable malicious web sites to: i. Analyze the content returned and locate sensitive

information. ii. Locate anti-CSRF tokens in pages that precede a

CSRF protected entry point. iii.Dynamically locate the CSRF target entry points,

instead of constructing the CSRF payload in advance.

iv.Overcome custom header requirements, and bypass incomplete CSRF prevention mechanisms.

v. Perform CSRF on entry points that require JSON, XML or different content delivery methods.

15

OWASP

3.4 CSRF with AJAX Attack

following conditions must be met: a. Same Port – the malicious website and the

vulnerable website reside on the same port. b. Same Protocol – the malicious website and the

vulnerable website must use the same protocol. c. The victim must use a “permissive browser”,

meaning a browser that supports permissive intranet settings (a concept which will be described in the following section).

d. The malicious web site must be perceived as "Internal" by the browser – the user should access the attacking web site while using an Intranet address.

16

OWASP

3.4.1 Demonstrating CSRF with AJAX

By creating the malicious website (abstract)

Step 1 - The user authenticates in front of the vulnerable website, which populates the session memory associated with the browser' cookie with the user identity and permissions.

Step 2 – The authenticated user uses a second tab to surf to the malicious website

http://absractSite/Ajax-CSRF.html

17

OWASP

3.4.1 Demonstrating CSRF with AJAX

function csrfAjax() { if (window.XMLHttpRequest) { xmlhttp=new XMLHttpRequest(); } else { xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); } xmlhttp.onreadystatechange=function() { if (xmlhttp.readyState==4 && xmlhttp.status==200) { document.getElementById("myDiv").innerHTML=xmlhttp.responseText; } } xmlhttp.open("GET","http://edition.cnn.com/search/?query=123hacked123&primaryType=mixed&sortBy=date&intl=true",true); xmlhttp.send(""); }

18

OWASP

3.4.1 Demonstrating CSRF with AJAX

19

innocent looking popup

Step 3 – The user clicks "yes" and the following request is generated (intercepted with a proxy)

OWASP

3.4.1 Demonstrating CSRF with AJAX

The browser sends the request to the target while automatically adding the users`cookie, and thus, causes the victim to perform the action that the attacker intended.

Now, the malicious website is able to analyze the response, and presents it under the malicious domain.

20

OWASP

4. DEFENSES

Defenses against CSRF and other attacks on web applications consists of: 

I. the application of appropriate principles and safeguards when designing programs 

II. the responsible handling of the program, code and test

III.test the program.

OWASP is helping by publishing application and documentation related to web protection, discovering vunerability and security maintaince.

21

OWASP

4. DEFENSES

Secret Validation Token

Referer Validation

Custom HTTP Header

22

<input type=hidden value=23a3af01b>

Referer: http://www.facebook.com/home.php

X-Requested-By: XMLHttpRequest

OWASP

4.1 Client-side defenses

Can browsers help with CSRF? Does not break existing sites Easy to use Hard to misuse Allows legitimate cross-site requests Reveals minimum amount of information Can be standardized

23

OWASP

4.1 Client-side defenses

Can browsers help with CSRF? Does not break existing sites Easy to use Hard to misuse Allows legitimate cross-site requests Reveals minimum amount of information Can be standardized

24

OWASP

4.1 Client-side defenses

25

private searching history in FireFox secure possibilities in FireFox

OWASP

4.1 Client-side defenses

The Firefox add-on CsFire protects the Internet user against malicious cross-domain requests. The add-on basically nullifies them by removing authentication information like cookies and authentication headers to eliminate the possibility that these requests can be harmful to the user.

26

OWASP

4.2 Web-browser defenses

a) re-apply each time users log critical GET and POST requests, 

b) limit the validity of the authentication cookie time, c) checking the source message (HTTP Referer header) d) introduction of additional secret security badges,

which joins the identifiers and the session request e) the use of cookies in the new each new legend form,

even within the same session f) reject cookies and outdated g) avoid displaying attributes in the URL link. 

It is recommended to send them in hidden fields of web forms.

27

OWASP

4.3 Protection Approaches

Approach 1: Use cryptographic tokens to prove the action formulator knows a session‐ and action‐specific secret.

Level of protection: Very High Recommended by iSEC

Advantages: Very strong protection, no additional memory requirements per user session.

Disadvantages: Requires the dynamic generation of all actions. This widespread change can be eased through integration with a thin client framework. The approach also requires a small amount of computation when actions are formulated and verified.

28

OWASP

4.3 Protection Approaches

Approach 2: Use secret tokens to prove the action formulator knew an action‐ and session‐specific secret.

Level of protection: Very High Recommended by iSEC

Advantages: Very strong protection, minimal computational overhead.

Disadvantages: Requires the dynamic generation of all actions. This widespread change can be eased through integration with a thin client framework. Requires additional memory on the order of 128 bits times the number of actions per session.

29

OWASP

5. CONCLUSIONS AND ADVICE

• Login CSRF. Strict Referer validation to protect against login CSRF because login forms typically submit over HTTPS, where the Referer header is reliably present for legitimate requests. If a login request lacks a Referer header, the site should reject the request to defend against malicious suppression.• HTTPS. For sites exclusively served over HTTPS, such as banking sites, we recommend strict Referer validation to protect against CSRF. Sites should whitelist specific “landing” pages, such as the home page, that accept cross-site requests.• Third-party Content. Sites that incorporate thirdparty content, such as images and hyperlinks, should use a framework, such as Ruby-on-Rails, that implements secret token validation correctly. If such a framework is unavailable, sites should spend the engineering effort to implement secret token validation and use HMAC to bind the token to the user’s session.

30

OWASP

Resources

1. OWASP http://www.owasp.org/

2. CSRF - An introduction to a common web application weakness - Jesse Burns https://www.isecpartners.com/

3. Jason Lam,Johannes B. Ullrich: CSRF: What Attackers Don’t Want You to Know A Study of Browser Implementations and Security Mechanisms for XMLHttpRequest and XDomainRequest, http://www.sans.org/reading_room/application_security/protecting_web_apps2.pdf

4. Robert Auger - CSRF/XSRF FAQ http://www.cgisecurity.com/articles/csrf-faq.shtml

5. Cross-Site Request Forgery Explained http://www.threadstrong.com/courses/csrf/

6. CsFire, Protects Against Malicious Cross-Domain Requests In Firefox http://www.ghacks.net/2010/10/22/csfire-protects-against-malicious-cross-domain-requests-in-firefox/

31

OWASP

Diskusija

32