Cross-Site Request Forgery Vulnerability: “A Sleeping Giant”

with you

Cross-Site Request Forgery Vulnerability “A Sleeping Giant”

Gopal Padinjaruveetil CISA, CISM,CRISC, CGEIT, TOGAF9

Chief Application Security and Compliance Architect

2 Copyright © 2014 Capgemini. All Rights Reserved

Cross-Site Request Forgery Vulnerability

Agenda

!  WHY is Cross Site Request Forgery a Concern !  WHAT is Cross Site Request Forgery !  HOW to Test for Cross Site Request Forgery !  HOW to Remediate Cross Site Request Forgery !  Questions and Answers



accelerating with you

Anatomy of CSRF



Secure by Design and Not Chance: Optimizing Security and Risk for Business Resilience requires design as a "way of thinking”

“A fever is a symptom. There's an underlying disease that causes it. Giving you a fever (sitting in a sauna) doesn't make you sick, and getting rid of the fever (in a cold bath, for example) doesn't always get rid of the illness…

Spending time and money gaming symptoms and effects is common and urgent, but it's often true that you'd be better off focusing on the disease (the cause) instead. ”

– Seth Godin

Security vulnerability is a symptom, The root cause is always something else



The seed for CSRF vulnerability goes back 25 years ago.. To the birth of Internet and world wide web

Source: Shodan

An open stateless and a neutral Web is leading the way to “singularity” * and Java is right in center of this

“CSRF: Yeah, it still works… We’ve identified an endless stream of applications, platforms, critical infrastructure devices, and even wormable hybrid attacks, many of which require little or no JavaScript (XSS) “ -Mike Bailey , Russ McRee – DefCon 2009



Security is all about TRUST ..

The Bad people have all the time in the world, and they need to be successful only once, but the enforcement teams have to be successful 100% of the time. The risk tolerance for security breaches is very low



Cross Site Request Forgery - Defined

" Cross-site request forgery vulnerabilities exploit the trust that a Web Application has on the Client Browser

!  Exploits a users privileges and Trust to a particular Website. !  Exploits the trust that applications have on authenticated sessions. !  It is a Client Side(Browser) attack.

•  In essence, the attacker forces your browser to do something on his behalf by you without your knowledge. (Scary ! identifying the attacker is even more difficult as the attack occurs in the context of the authenticated user- you ! !)

" “ Definition: Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF ("sea-surf") or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. ...” http://en.wikipedia.org/wiki/CSRF

OWASP Top 10 2013-A8-Cross-Site Request Forgery (CSRF)



Characteristic of a CSRF Vulnerability

!  The key characteristic of a CSRF vulnerability are that the application accepts a request that makes something occur on the server and the attacker can determine all the parameter of that request for another user.

!  Not to be confused with Cross Site Scripting!

!  CSRF Involves two key components to be successful: •  A willing victim (this we have no control) •  A vulnerable website (this we have control)

Which websites are vulnerable ?



WHY: Because Industry Experts consider this a big concern in Web Applications

!  "In fact, if you have not taken specific steps to mitigate the risks of CSRF attacks your applications are most like vulnerable," - Chris Schiflett http://shiflett.org/articles/cross-site-request-forgeries

!  “No statistics, but the general consensus is just about every piece of sensitive website functionality is vulnerable” - Jeremiah Grossman and TC Nieldzialkowski http://www.whitehatsec.com/home/resources/presentations/files/javascript_malware.pdf

!  “Cross Site request forgery is a dangerous vulnerability present in just about every website” - Jeremiah Grossman http://jeremiahgrossman.blogspot.com/2006/09/csrf-sleeping-giant.html.

!  “Cross Site request forgery is not a new attack, but is simple and devastating.." This vulnerability is extremely widespread.." " all web application frameworks are vulnerable to CSRF” - OWASP



Web Application Architecture Basics I – Authenticated Session

!  HTTP is a Stateless Protocol, Web Applications maintains state through SessionID (in Cookies or URL Parameters, Hidden variables)

!  The Server Trusts the SessionID coming from the browser. !  For authenticated sessions , the browser does not resend a NEW SessionID to the application

as a proof that each HTTP request is authenticated !  This allow for “riding the session” with an interleaved malicious HTTP request. !  If an attacker (phish) a victim forcing him to select a web page (via web mail for example) that

has a malicious HTML tag such as iframe with an embedded GET request and if such request is issued (by the victim web page selection) when an authenticated session with the same application is still valid, then such malicious request will processed by the application.

!  So if the ONLY check that an target web application checks for on the server side is the existence of a valid sessionid (sent by the victim’s browser) before submitting a transaction to the database – the victim is toast!!



CSRF Root Cause I : Social Engineering + Session Riding of Authenticated Session

The Web application (server) implicitly assumes that any request that comes in expresses the will of the user, as it comes from the users browser. The Application does not take into account that the request may as well have been foisted on the user by a third party. Is this the web application’s fault? – (TSA example) .. Though most users have good intention – the server side application has the responsibility to check for the one in a million bad user/request The attacker abuses an existing session in the victims browser, he "rides" on it. This is known as Session Riding .. a.k.a CSRF. Session Merging: All Browsers shares cookies between multiple tabs that are open to the same web application. In fact it’s worse than that … it also shares those cookies between tabs in multiple instances of the browser! -

Implicit assumptions are bad for security !



Web Application Architecture Basics II –Same Origin Policy

! Same Origin Policy is an important security concept for a number of browser-side programming languages, such as JavaScript.

! SOP prevent two different documents loaded on the browser and one potentially being malicious to access each other via JavaScript, the same origin policy will check that such JavaScript invocation comes from two different sources and it will deny it.

! SOP is enforced by the client Browsers



CSRF Root Cause II : Bypassing Same-Origin Policy

The main root causes of CSRF on the client is the lack of enforcement of the Same Origin Policy. Browser control prevents a document or script loaded from one site of origin from manipulating properties with a document loaded from another site of origin

But, applies only to: # Manipulating browser windows # URLs requested via the XmlHttpRequest (XHR) # Manipulating frames (including inline frames) # manipulating documents (included using the OBJ tag) # Manipulating cookies

But, SOP does not apply to these HTML TAGS! (<img> ,<iframe>, <script>… 13 tags) The same origin policy can also be bypassed with a Adobe Flash to issue XHR, since cross domain is permitted depending on a rule set in “crossdomain.xml” file present in the root of the target domain. Access-Control-Allow-Origin: * vs Access-Control-Allow-Origin: https://mybank.com



The Browser “Same Origin” Policy

bank.com

blog.net

XHR

XHR

document, cookies

TAG

TAG

JS



How Does CSRF Work?

!  Tags <img src=“https://bank.com/fn?param=1”>

<iframe src=“https://bank.com/fn?param=1”> <script src=“https://bank.com/fn?param=1”>

!  Auto posting Forms <body onload="document.forms[0].submit()"> <form method="POST" action=“https://bank.com/fn”> <input type="hidden" name="sp" value="8109"/> </form>

!  Bypassing XmlHttpRequest- Subject to same origin policy Flash/ Silverlight/ Web Gadgets !  <script> function put()

{ var x = new XMLHttpRequest(); x.open("PUT","http://bank.com/transfer.do",true); x.setRequestHeader("Content-Type", "application/json"); x.send(JSON.stringify('{"acct":"BOB", "amount":100}')); }

</script> <body onload="put()"> Cross Origin Resource Sharing (CORS) – New Browsers are getting smarter..But



How to Test for CSRF All commercial Scanners test for CSRF.

HP WebInspect

Manual Pen Test

OWASP CSRF Tester http://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project

IBM Rational Appscan



innovating with you

Demo of OWASP CSRF Tester



collaborating with you

Option to address CSRF



CSRF Mitigation Best Practices: For the End User

!  Logoff immediately after using a critical web application !  Do not save username/passwords (browser capability), auto complete !  Don’t Use “remember me” your login (uses persistent cookies) !  Do not use the same browser to access sensitive applications and to surf freely the

Internet; if you have to do both things at the same machine, do them with separate browsers (IE and FF or IE and Chrome, or FF- Chrome).

!  Using HTML enabled mail pose additional risks since simply viewing a mail message might lead to the execution of an attack.

!  Check your computer for malwares frequently.

Caution: Application has no control over end user behavior



CSRF Mitigation Best Practices: For Applications

!  Insert custom random tokens into every form and URL - (Synchronizer Token Design Pattern) !  Make sure there a no XSS/HTML Tag Injection, Link Injection, Phishing vulnerabilities in your

application !  Re-authenticate when performing high risk transactions !  Do not use GET requests for sensitive data or to perform high risk transactions. !  Do not allow POST variables as GET when submitting forms !  When using Flash always have restricted crossdomain.xml file (on the server) !  When redirecting out of domain requests– implement a white list approach. !  Disable all Unsafe HTTP methods (all except GET and POST)



The Key Takeaway

" Bad News !  CSRF is nasty, it's everywhere, and you can't stop it on the client side

" Good News !  It can do neat things $ $ $

!  A vulnerability that is so easily prevented can lead to absolute mayhem, particularly when bundled with other attacks.

!  Worse still, identifying the attacker is even more difficult as the attack occurs in the context of the authenticated user



Misconceptions about CSRF– Defenses That Don’t Work

!  Only accept POST

•  Stops simple link-based attacks (IMG, frames, etc.) •  But hidden POST requests can be created with iframes, scripts, etc…

!  Referrer checking

•  Some users prohibit referrers, so you can’t just require referrer headers •  Techniques to selectively create HTTP request without referrers exist

!  Requiring multi-step transactions

•  CSRF attack can perform each step in order !  URL Rewriting

None of these approaches will sufficiently protect against CSRF!



!  Myth: CSRF is a special case of XSS Fact: Different vulnerability, root causes and countermeasures. XSS can facilitate CSRF

!  Myth: POSTs are not vulnerable to CSRF !  Fact: It is more difficult to exploit but they can lead to automatic submission !  Myth: CSRF is low risk vulnerability !  Fact: Can perform any un-authorized business transaction such as change passwords, force logouts,

transfer money, disclose information,

CSRF Myths and Reality



growing with you

How do we address CSRF in Java Applications



In Legacy Web Application: Custom Servlet Filter Key Concepts of Filter Approach

! A Plug-in like a handler or a Filter or a Servlet can be introduced with minimal changes to the configuration and the final package.

! The Plugin can also be configured with something as simple as a property file or even XML.

! Extensions to Frameworks are also possible because the Framework has several hooks to insert code.

! If its written well enough, future enhancements can simply be inserted without fear of regression.

! Use of Encryption code: MD5 or AES (preferred) for generation and validation of CSRF tokens

! Examples of Anti CSRF implementations for Java OWASP CSRFGuard, OWASP CSRF Protector, ESAPI ,HDIV



New Applications using Spring Security :Filter Chain

Browser

Java Run Time Container

XSS Filter

CSRF Filter

Data Tamper Filter

Application Code

Safe Request

YES

Error Message

The CSRF Filter will do the following. !  Inserts a hidden field inside every

form. This is an encrypted value , and can be based on a random value such as the session or a pre-determined combination.

!  Validate the request, check for the token and throw an exception if tampered or missing.

Most New Web frameworks have built-in CSRF support such as Spring, Struts, JSP, Ruby on Rails, Joomla and others

innovating with you

Demo for Addressing Legacy CSRF



Thank You

Russia

Danke Germany

Grazie Italy

Gracias Spain

Dank u Belgium

Bedankt Netherlands

Dankschen Austria

Arigato Japan

Takk Norway

Tak Denmark

Jag tackar Finland

Dziekuje Poland

Tack Sweden

Toda Israel

Engraziel Switzerland

Tesekkür ederim Turkey

Dakujem Slovakia

Obrigado Portugal

Thank You United Kingdom

Merci France

Thanks United States

Hindi

Tamil Malayalam



Presenter contact information

Gopal Padinjaruveetil CISA, CISM, CRISC, CGEIT, TOGAF9 Chief Application Security and Compliance Architect [email protected]

Insert contact picture



accelerating with you

Back up Slides



CSRF Black Box Testing

1.  Assume URL being tested ishttp://www.example.com/action 2.  Build a html page containing the http request referencing the URL embedded in an image tag 3.  Log into the application; 4.  Assume social engineering attack, craft an email with a reference to the URL (it can be HTML

email with the URL embedded in an tag) 5.  Select the link and observe the result 6.  Check if the web server executed the request.



OWASP CSRF Tester

Test your applications for CSRF using the CSRF Tester #  Record and replay transactions

#  Tune the recorded test case #  Run test case with exported HTML document

Test case alternatives #  Auto-Posting Forms #  Evil iFrame

#  IMG Tag #  XMLHTTPRequest

#  Link



CSRF Tester Installation\Configuration

1) Set the variables in the .bat file C:\CSRFTester\CSRFTester-1.0\run.bat

2) Run the batch file: 2) Configure browser to proxy through CSRFTester

Lunch n Learn In Collaboration with



CSRF Tester Recording




OWASP CSRF Tester: Creating the Test Case

1) The report type determines how we want the victims browser to submit the previously recorded requests #  Forms: using auto-posting forms

#  iFrame: using auto-submitting iframetag. #  IMG: using the <imgsrc="..."/> tag

#  XHR: using XMLHttpRequest. (Note that this is subject to the same origin policy_ #  Link: when the user clicks a link

2) Select a request from the recorded one that does a critical business transaction and Generate a HTML File.

3) Edit the HTML File to the business data (hidden field) you want to forge, save the HTML file.




OWASP CSRF Tester: Running the Test

1.  Open a new browser instance 2.  Authenticate with access to the same business function (URL) 3.  Have that user/browser launch the newly created HTML report file. (File-> Open->Browse-Select

HTML->OK)

% If the action was carried out after viewing the file in the same browser window that was used to authenticate then the tested URL is vulnerable to CSRF.



*Singularity

!  According to Ray Kurzweil, by the year 2045, “human intelligence will enhance a billion-fold thanks to high-tech brain extensions.”

!  He refers to this phenomenon as the “singularity,” a point at which humans and computers will merge. This sort of “one in two” will create serious challenges for security and in the allocation of moral accountability between the two…

!  Singularity !  http://www.youtube.com/watch?v=-wqaEsEApSE

!  How does the Future look like.. !  http://www.youtube.com/watch?v=H4axEZwLdno

The information contained in this presentation is proprietary. Copyright © 2014 Capgemini. All rights reserved.

Rightshore® is a trademark belonging to Capgemini.

www.capgemini.com

About Capgemini

With almost 140,000 people in over 40 countries, Capgemini is one of the world's foremost providers of consulting, technology and outsourcing services. The Group reported 2013 global revenues of EUR 10.1 billion.

Together with its clients, Capgemini creates and delivers business and technology solutions that fit their needs and drive the results they want. A deeply multicultural organizat ion, Capgemini has developed i ts own way of working, the Collaborative Business Experience™, and draws on Rightshore®, its worldwide delivery model.

Learn more about us at www.capgemini.com.

Technology

Cross-Site Request Forgery Vulnerability: “A Sleeping Giant”