OWASP Serbia - A5 cross-site request forgery

Cross-Site Request Forgery Vladimir Polumirac e-mail: v.polumirac@sbb.rs blog: d0is.wordpress.com FB: facebook.com/vpolumiracOWASP Twitter twitter.com/d0is23/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

Content1) INTRODUCTION2) WEB APPLICATION SECURITY3) CSRF ATTACKS4) DEFENSES5) CONCLUSION OWASP 2

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

1. INTRODUCTIONExploits 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

WEB APPLICATION SECURITY OWASP 5

2.1 CSRF Demonstration OWASP 6

2.1 CSRF Demonstration OWASP 7

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

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

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

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 abuseIII.Automatic generation of application in a web browser (XMLHttpRequest). OWASP 11

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

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

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

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

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

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

3.4.1 Demonstrating CSRF with AJAXfunction 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

3.4.1 Demonstrating CSRF with AJAX innocent looking popupStep 3 – The user clicks "yes" and the following request isgenerated (intercepted with a proxy) OWASP 19

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

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 testIII.test the program. OWASP is helping by publishing application and documentation related to web protection, discovering vunerability and security maintaince. OWASP 21

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

4.1 Client-side defensesCan 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

4.1 Client-side defensesCan 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

4.1 Client-side defensesprivate searching history in FireFox secure possibilities in FireFox OWASP 25

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

4.2 Web-browser defensesa) 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

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

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

5. CONCLUSIONS AND ADVICE• Login CSRF. Strict Referer validation to protect against loginCSRF because login forms typically submit over HTTPS, where theReferer header is reliably present for legitimate requests. If a loginrequest lacks a Referer header, the site should reject the requestto defend against malicious suppression.• HTTPS. For sites exclusively served over HTTPS, such asbanking sites, we recommend strict Referer validation to protectagainst CSRF. Sites should whitelist specific “landing” pages, suchas 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 asRuby-on-Rails, that implements secret token validation correctly. Ifsuch a framework is unavailable, sites should spend theengineering effort to implement secret token validation and useHMAC to bind the token to the user’s session. OWASP 30

Resources1. 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.pdf4. Robert Auger - CSRF/XSRF FAQ http://www.cgisecurity.com/articles/csrf-faq.shtml5. 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

Diskusija OWASP 32

OWASP Serbia - A5 cross-site request forgery

by Nikola Milosevic on Aug 09, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 221

Statistics

OWASP Serbia - A5 cross-site request forgery Presentation Transcript