5. 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
9. Basics | 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.”
11. Basics | 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. Basics | 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.”
13. Basics | 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.”
14. Basics | Description
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?
15. 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.
Basics | Description
19. 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.
Basics | Trust Abuse
21. 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
22. Validation | Criteria
If your CSRF vulnerability doesn’t change
something sensitive, then you might not have
one.
Note: sensitivity is a…sensitive matter. Who is it
sensitive to? Could it be sensitive to some and
not others?
Many changes are insignificant
Remember that if the business understands the technical
risk then they automatically win the “what matters”
argument
23. Validation | Criteria
If requests for your CSRF vulnerability are
unique, you might not have one.
Things to check for uniqueness:
- Nonces
- CAPTCHA
- Multiple authentication levels
24. 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
25. Validation | WebInspect
How WebInspect identifies CSRF:
1. Log in to the site
2. Complete a form and generate post request with current session
cookies
3. If response is 30X, follow the redirection (with current session
cookies) until the non-30x response is reached. This is response #1
(R1)
4. Log out and log in the site with different credentials (note session
cookies should be changed here)
5. Resend the same POST request as in step 2, but with the new
cookies
6. If necessary, follow redirects per step 3
7. Note the response as R2
8. If R1==R2, then it’s a non-unique request and therefore is CSRF-able
26. 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
9. Remember that the issue must also satisfy the state change and
sensitivity requirements. Non-uniqueness is not enough.
27. Validation | Caution with Automation
Don’t trust the claims from tools. They’re often
right, but they’re only guessing at sensitivity:
Validation of non-uniqueness doesn’t mean the
action is sensitive, i.e. it could be a “business”
false positive even if it’s valid technically
CSRF is a high-false-positive vulnerability when
automation is used
Tools make educated guesses that require
validation of all three criteria
29. Defense | Overview
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
30. Digging In | Nonces
<%
function session_initiate(first_name, last_name /* etc */) {
session.fisrt_name = first_name
session.last_name = last_name
/* etc */
session.form_token = generate_form_token()
}
%>
Then, in the page code:
<%
<form>
<input name=”field1”><br>
<input name=”field2”><br>
<input type=”submit”>
<input name=”form_token” type=”hidden” value=”<%= session.form_token %>”>
</form>
When the form is submitted, the following is executed:
if (post.form_token != session.form_token) {
log_CSRF_attack()
error_and_exit()
}
// normal form handling here
31. Defense | Nonces
Nonces make it so that generic requests to
sensitive resources don’t get executed
This works by providing a one-time-secret
when a legitimate client arrives at a given
location, and then that token (nonce) must be
submitted along with a request to prove that’s
legitimate
34. Attack Vectors | Leveraging XSS
The key to CSRF defense is that the attacker doesn’t
have access to a valid nonce
But with XSS present the attacker could force the victim
to make a request to the site, consume the nonce, and
add it to the CSRF request
This is what the Samy Worm did; he pulled the token first
and used it to submit the (now valid) friend addition
35. Attack Vectors | SAMY
Step #9 from Samy’s technical description
of his attack:
http://namb.la/popular/tech.html
36. Digging In | Clarification
Forcing the victim to execute the action (POST):
37. Attack Vectors | Options
Take control of a legitimate, well-trafficked but
low priority internal site and post a form that
submits the attack
Use persistent XSS to inject code on a
vulnerable site, e.g. a forum
Create a new site internally and entice users
to visit the site via email, etc. (phishing-ish)
39. CSRF Tester | Overview
• CSRF Tester is an
OWASP tool for creating
CSRF PoC code
• It works by capturing you
doing something
sensitive, and then
generating PoC code for
you try in another user
context
• You must set your
JAVA_HOME environment
variable to launch it
• Listens on port 8008
40. CSRF Tester | Usage
• Send traffic through CSRF
Tester like any other proxy
• Record the execution of a
sensitive action on the site
• You then create a “report”
of a certain
type, Form, iFrame, IMG,
XHR, Link
• That code is now the PoC
for testing to see if it’s a
CSRF issue
• The test is whether or not
it executes from other
42. Takeaways | Overview
1. CSRF is # 8 on the OWASP Top 10
2. Abuses server’s trust of client
3. Forces user to perform sensitive function
4. Validate by: State-change, Sensitivity, Non-uniqueness
5. Nonces are a common defense
6. XSS can assist CSRF by getting code onto a page and by
bypassing nonce defenses by having the user request a
valid nonce before submitting
7. Single sign-on can magnify CSRF issues
8. Remember that customers are deeply confused by CSRF
and will require constant reinforcement
9. Repetition: State(change)/Sensitivity/Uniqueness (SSU)
My name is [Name]. I work at HP as a [Title] in the Enterprise Security Products group.Today, we’ll talk about application security; what it is, why its needed, how to do it and what benefits you will see.
Why is there a problem, and why do you need application security?Like all organizations, you’ve undoubtedly, invested a lot of time and money attempting to insulate and protect your assets. Your networks are protected – firewalls are in nearly every devices that connects to a network. Your servers are protected, thanks to advances in intrusion prevention systems. But your software applications are still largely unprotected and vulnerable.Companies believed that if you protect the perimeter (network and server), the software will be unreachable and therefore not breachable. However, that has not proven to be the case: software is the New Entry Point.Let’s take a look at how…
Why is there a problem, and why do you need application security?Like all organizations, you’ve undoubtedly, invested a lot of time and money attempting to insulate and protect your assets. Your networks are protected – firewalls are in nearly every devices that connects to a network. Your servers are protected, thanks to advances in intrusion prevention systems. But your software applications are still largely unprotected and vulnerable.Companies believed that if you protect the perimeter (network and server), the software will be unreachable and therefore not breachable. However, that has not proven to be the case: software is the New Entry Point.Let’s take a look at how…