owasp serbia - a5 cross-site request forgery
TRANSCRIPT
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: [email protected]: 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