Its all about CSRF - null Mumbai Meet 10 January 2015 Null/OWASP Chapter
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
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)
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.
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.
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
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.
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
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.