1. Its All about CSRF
Nilesh Sapariya
Security Analyst | CEH v8 | Blogger

2. Who Am I ?
 Nilesh Sapariya
 Security Analyst
 3years of Experience in information security
 http://shield4you.blogspot.in/
 @nilesh_loganx

3. Agenda
What is CSRF ?
Problem
Basics
Validation
Defenses
 News
Demo

4. What is CSRF ?
• Wiki Says :-
http://en.wikipedia.org/wiki/Cross-site_request_forgery

5. CSRF | Other names of CSRF
• CSRF (Sea Surf)
• XSRF
• Session Riding

6. Problem

7. Problem | Overview
CSRF is an OWASP Top 10 vulnerability but it’s not as well understood
as many others
Many struggle with how to validate it
Customers have difficulty explaining to management why it’s
important to fix
We need to be well-versed in the main points to help the customer
with their narrative to management

8. Problem | Overview
 Undetectable by automated scanners
 The attack is silent
 Easily mountable
 Combines with XSS or HTML injection(stored)

10. Basics | OWASP

11. Basic | Description
“Cross-site Request Forgery is a vulnerability in a
website that allows attackers to force victims to
perform security-sensitive actions on that site
without their knowledge.”

12. What do we mean by “sensitive
actions”?
How do attackers “force” victims to
perform them?
And how do the victims not know it’s
happening?
Basic | Questions

13. Basic | Description
1. The target is a sensitive operation in the application, e.g.
UpdateSalary.aspx, that’s able to be tricked into executing.
2. Victims can be forced to execute this action through any method
that gets them to load a resource automatically, e.g. img tag, script
tag, onload form submit, etc. Note: credentials go with all requests!
3. These happen unknowingly because the actions are performed by
the victim’s browser, not by the victim explicitly.

14. Basic | Description

15. Basic | Description

16. Anatomy of CSRF Attack
• Step 1: Attacker hosts web pages with pre-populated HTML form data.
• Step 2: Victim browses to attacker’s HTML form.
• Step 3: Page automatically submits pre-populated form data to a site
where victim has access (No verification done by server as browser is
performing request by checking cookies)
• Step 4: Site Authenticates request (with attacker’s form data) as coming
from victim
Result : Attacker’s form data is accepted by server since it was sent from
legitimate user.

17. Validation

18. Validation | Criteria
• If you can’t change something using your CSRF vulnerability, then
you don’t have one.
• Examples of state changes:
- Updating an account (new password?)
- Transferring funds
- Changing the role of a user
- Ordering an item
- Adding an administrator to a system

19. Validation | Criteria
• The three components again…
1. Can you change state using it?
2. Is the function sensitive?
3. Is the request non-unique?
 This is the core of the validation process
 Any customer asking you to validate a CSRF vulnerability
should hear and learn these same concepts

20. Validation | Manual Validation
• How to manually verify CSRF:
1. Configure a proxy to observe traffic
2. Log in to the site with the issue in question
3. Perform the target functionality normally, through the browser
4. Observe the request, looking for state change, sensitivity, and uniqueness
5. Look for any additional controls that could stop CSRF, such as CAPTCHA or
additional authentication
6. Log out and log in with a different set of credentials
7. Submit the initial request from the new context, and see if it is successful
8. If the action is performed without issue, it is most likely CSRF

21. Misconception

22. Misconception | #1 CSRF = XSS ?
• CSRF = XSS ?
• Fact : CSRF and XSS are completely different attack vector
XSS
• Attacker insert text (for example JavaScript code) onto website by sending
the victim a specially prepared link
• <script>alert(‘nilesh’)</script>
CSRF
• Victim sends attacker’s request to the webserver without knowing about it
• http://www.example.com/admin/deleteuser.php?id=xxx

23. Misconception | #2 Preventing XSS stops CSRF ?
• Preventing XSS stops CSRF ?
• XSS makes CSRF easier, but it isn’t required

24. Basics | Trust Abuse
• Both XSS and CSRF are possible due to abused trust relationships:
In XSS the browser will run malicious JavaScript because it
was served from a site (origin) it trusts.
In CSRF the server will perform a sensitive action because it
was sent by a client that it trusts.

25. Defense

26. Defense | That Don’t Work
 Requiring multi-step transactions
- CSRF attack can perform each step in order
 CAPTCHAs
Protect forms against automated submission
Can by bypassed using automated tool
How to bypass captcha : http://shield4you.blogspot.in/2014/10/bypass-
captcha-verification-in-chrome.html
Provides security, but doesn't solve the problem

27. Defense | That Work
 Only use POST to initiate the request
Checking HTTP Referer Header (Accept requests only from trusted
sources by verifying the referer header)
Use random server generated user-specific token in all form
submission
Re-Authentication – Password based (Attacker must know victim
password)

28. Defense | TOKENS
• Approach #4 : Tokens
• Tokens are random string of character
• Insert a random string into hidden field in EVERY form
• Make sure tokens is random
• Make sure there are no XSS vulnerability on your page! This is utmost
importance! (If attacker find XSS in your page then he/she can easily
have access to your tokens)

29. Defense | Approach #4
 Session Tokens
• Attacker only need one token
and can access entire site while
user is logged in
• Easy to implement
 Session Tokens stored in database
• A bit more difficult to implement
• Stores unique id, random token,
current time, user id
• Attacker can only access the
form the token was assigned to
(higher security!)
• Definitely recommended

30. CSRF | Defenses
• Secret Validation Token
• Referer Validation
• Custom HTTP Header
<input type=hidden value=23a3af01b>
Referrer: http://www.facebook.com/home.php
X-Requested-By: XMLHttpRequest

31. CSRF | Defenses | Example : LinkedIn

32. Defense | Overview
• Beware of State-modifying GET Request
• The primary defense for Cross-site Request Forgery is creating unique
requests that cannot be easily generated by attackers.
• This is usually accomplished via a nonce (a number used once).
• CAPTCHAs can also be used, as well as authentication prompts

33. How To bypass | Defenses
 Clickjacking
Bypassing the captcha
Checking Token Validation
Checking header Validation
Converting POST based requests to GET based requests.

34. Obstacles for Attacker
Need to know victim’s server
• Knowing victim’s server is not hard in a targeted attack or a commonly used
server. Example: Famous banks, famous site etc.
Need to get victim to browser to attacker’s site (pre-populated form)
• Getting victim to load the attacker’s form isn’t hard. (Phishing is often successful.)
Needs victim to log into server
• Victim might already be logged into a site or might have automatic log-in
enabled.
• Examples: Windows Integrated authentication
• Windows integrated authentication is very popular on intranets.

35. Highlights |News

36. Latest | News
• Pay pal Defaced by CSRF

37. Latest | News
• Facebook Hacked #CSRF
Link: http://pyx.io/blog/facebook-csrf-leading-to-full-account-takeover

38. Latest | News Blogger haced # CSRF
• Blogger hacked # CSRF

39. Latest | News
• W3 Total Cache's W3TotalFail Vulnerability That Leads to Full Deface
by CSRF

40. Latest | News
• Google Account Recovery Vulnerability + CSRF
• http://www.orenh.com/2013/11/google-account-recovery-
vulnerability.html?showComment=1420318818311#c5894478871478
949015

41. Demo |Video

43. Demo | Setup
bWAPP – VM machine
Burp suite-pro
Download link:-
http://sourceforge.net/projects/bwapp/

45. Questions ?

46. Thank You 
Comments | Feedback | Suggestions
• @Twitter : @nilesh_loganx
• Email: nilesh.s.sapariya@gmail.com
• Blog: http://shield4you.blogspot.in/
• LinkedIn: https://www.linkedin.com/pub/nilesh-sapariya/39/33/735
• Slideshare: http://www.slideshare.net/Nilesh_logan