SlideShare a Scribd company logo
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
Content

1)   INTRODUCTION
2)   WEB APPLICATION SECURITY
3)   CSRF ATTACKS
4)   DEFENSES
5)   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. 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
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 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
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 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
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
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 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
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
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 test
III.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 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
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
4.1 Client-side defenses




private 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 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
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 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
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
Diskusija




            OWASP   32

More Related Content

OWASP Serbia - A5 cross-site request forgery

  • 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
  • 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