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
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
How do attackers “force” victims to
And how do the victims not know it’s
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
Result : Attacker’s form data is accepted by server since it was sent from
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
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
the victim a specially prepared link
• Victim sends attacker’s request to the webserver without knowing about it
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:
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
Protect forms against automated submission
Can by bypassed using automated tool
How to bypass captcha : http://shield4you.blogspot.in/2014/10/bypass-
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
Re-Authentication – Password based (Attacker must know victim
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
• 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
• 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
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
• Examples: Windows Integrated authentication
• Windows integrated authentication is very popular on intranets.