This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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/