1. Cross-Site Request Forgery
Vladimir Polumirac
e-mail: v.polumirac@sbb.rs
blog: d0is.wordpress.com
FB: facebook.com/vpolumirac
OWASP Twitter twitter.com/d0is
23/07/2012
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. Content
1) INTRODUCTION
2) WEB APPLICATION SECURITY
3) CSRF ATTACKS
4) DEFENSES
5) CONCLUSION
OWASP 2

3. 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)
OWASP 3

4. 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
OWASP 4

5. WEB APPLICATION SECURITY
OWASP 5

6. 2.1 CSRF Demonstration
OWASP 6

7. 2.1 CSRF Demonstration
OWASP 7

8. 2.2 Attack characteristics
 Conditions:
I. page that the attack does not check the source of
messages, or HTTP referrer header or
II. Web browser allows users faking the header
III.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.
OWASP 8

9. 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.
OWASP 9

10. 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.
OWASP 10

11. 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).
OWASP 11

12. 3.1 Attacks HTML objects
 By HTTP GET methods
<img src=”picture.gif" alt=”Picture" title=" Picture " />
input fake code in attribute ”src” request to another web
location
<img src="http://server/false_request"/>
input fake code in attribute ”src” in SCRIPT and FRAME
object request to another web location
<iframe src=" http://server/false_request"/>
<script src=“http://server/false_request"/>
OWASP 12

13. 3.2 Attacks scripting code
 Example abusing by object Image()
<script>
var picture = new Image();
picture = http://server/false_request“;
<script>
 By object ActiveXObject in Microsoft JScript
<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 13

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

15. 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.
OWASP 15

16. 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.
OWASP 16

17. 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
OWASP 17

18. 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("");
}
OWASP 18

19. 3.4.1 Demonstrating CSRF with AJAX
innocent looking popup
Step 3 – The user clicks "yes" and the following request is
generated (intercepted with a proxy) OWASP 19

20. 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.
OWASP 20

21. 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.
OWASP 21

22. 4. DEFENSES
 Secret Validation Token
<input type=hidden value=23a3af01b>
 Referer Validation
Referer: http://www.facebook.com/home.php
 Custom HTTP Header
X-Requested-By: XMLHttpRequest
OWASP 22

23. 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
OWASP 23

24. 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
OWASP 24

25. 4.1 Client-side defenses
private searching history in FireFox secure possibilities in FireFox
OWASP 25

26. 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.
OWASP 26

27. 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.
OWASP 27

28. 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.
OWASP 28

29. 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.
OWASP 29

30. 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.
OWASP 30

31. 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_ap
ps2.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/
OWASP 31

32. Diskusija
OWASP 32