This presentation was used in OWASP Taiwan Week 2017 at Taipei & Kaohsiung. It talks about what Cross Site Request Forgery is, what are different ways to prevent it. And how it can be mitigated with OWASP CSRF Protector with just two lines of codes.
6. CSRF: What
OWASP says?
Source: https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)
Cross-Site Request Forgery (CSRF) is an
attack that forces an end user to
execute unwanted actions on a web
application in which they're currently
authenticated. CSRF attacks specifically
target state-changing requests, not theft
of data, since the attacker has no way to
see the response to the forged request.
8. CSRF: What
OWASP says?
Cross-Site Request Forgery (CSRF) is an
attack that forces an end user to execute
unwanted actions on a web application in
which they're currently authenticated. CSRF
attacks specifically target state-changing
requests, not theft of data, since the
attacker has no way to see the response to
the forged request.
9. CSRF: What
OWASP says?
Cross-Site Request Forgery (CSRF) is an
attack that forces an end user to
execute unwanted actions on a
web application in which they're
currently authenticated. CSRF attacks
specifically target state-changing requests, not
theft of data, since the attacker has no way to
see the response to the forged request.
10. CSRF: What
OWASP says?
Cross-Site Request Forgery (CSRF) is an
attack that forces an end user to
execute unwanted actions on a
web application in which they're
currently authenticated. CSRF attacks
specifically target state-changing requests, not
theft of data, since the attacker has no way to
see the response to the forged request.
11. How do attackers “force” victims to
perform them?
And how do the victims not know it’s
happening?
And what kind of actions?
12.
13. Some facts
fact#0: HTTP is stateless
protocol, so we generally
use cookies for maintaining
states, and
authenticating/validating
users.
1
fact#1: Whenever a request
originates from a browser
(client) to server, all cookies
associated with the server
are sent along with the
request, irrespective of the
origin of request.
2
So if the attacker can
somehow send a request
with cookies to server and
tend to perform something,
that usually needs
authentication, attacker
will succeed. This is bad!!
3
14. Money transferred
to attacker
$12,000
POST /login HTTP/1.1
Host: bank.com
username=bob&password=pwd123
200 Success
Content-type: text/html
set-cookie: token=abcd;
expires=..
…
…
POST /addUser HTTP/1.1
Host: bank.com
Cookie: token=abcd
200 Success
Content-type: text/html
<html>
…
</html>
GET / HTTP/1.1
Host: evil.com
POST /transefer HTTP/1.1
Host: bank.com
Cookie: token=abcd
To=1234&Amount=12000&type=Instant
16. Other possibilities:
If there is CSRF vulnerability in admin panel of a website,
whole website can be compromised!
Hijacking primary DNS server setting of your router! ->
phishing, Man in the Middle attacks etc.!
…Add more!
Want to see it work? Visit superlogout.com
Read More at OWASP CSRF Cheat Sheets, Just Google it!
17. Other possibilities:
If there is CSRF vulnerability in admin panel of a website,
whole website can be compromised!
Hijacking primary DNS server setting of your router! ->
phishing, Man in the Middle attacks etc.!
…Add more!
Want to see it work? Visit superlogout.com
Read More at OWASP CSRF Cheat Sheets, Just Google it!
18.
19. Other possibilities:
If there is CSRF vulnerability in admin panel of a website,
whole website can be compromised!
Hijacking primary DNS server setting of your router! ->
phishing, Man in the Middle attacks etc.!
…Add more!
Want to see it work? Visit superlogout.com
Read More at OWASP CSRF Cheat Sheets, Just Google it!
20. There are some cool ways!
There are some JUST WRONG
WAYS!
How do we
generally
protect
ourselves
21. ✗ Secret cookies
✗ Accepting only POST requests
✗ Multi-Step transactions
✗ URL rewriting
✗ HTTPS
Prevention Methods that SUCKS
27. CSRF Protector ? Why ? What
I’ll start with
WHY!
As an engineer, and while I
should, I don’t really want to
know about what CSRF is and
what are cool and uncool
ways to mitigate it;
Of course I can use
frameworks, but there are
just so many forms and I
tend to forget stuff; And to
be frank I don’t always run
static analysis tools to
remind me of issues;
On the top of it, I don’t want
to deal with all these I just
want to build an awesome
app; and release it to
customers as soon as
possible;
28. Taking a step back:
How it’s done in popular
frameworks
33. CSRF Protector ? Why ? What
I’ll start with
WHY!
As an engineer, and while I
should, I don’t really want to
know about what CSRF is and
what are cool and uncool
ways to mitigate it;
Of course I can use
frameworks, but there are
just so many forms and I
tend to forget stuff; And to
be frank I don’t always run
static analysis tools to
remind me of issues;
On the top of it, I don’t
want to deal with all these I
just want to build an
awesome app; and release
it to customers as soon as
possible;
37. Incoming
request
(POST,
GET*)
Picked up by CSRFP
Validated for CSRF
Token
Business logic of
application
generated HTML
output
Failed Validation
Actions - configurable
(403, redirect)
Output buffered,
scripts injected
On Server Side
38. On Client Side
We need to ensure all requests, that needs validation:
- All POST request & Selected GET requests
Need to send the token along with the request: either as a query
parameter in the request itself of in request header in case of POST
requests;
So JS code is called as soon as DOM is loaded; And it adds wrapper
to:
- All AJAX calls, All Form submissions, All dynamic form
submissions, and link clicks (if those GET requests need CSRF
validations)
39. • The token is needed in request header or request query for the request to
be successfully validated;
• The token cannot be guessed (a pseudo random token of configured
length is used);
• The token cannot be retrieved by the attacker as it’s transferred via
cookies (keeping MITM aside), as cookies can be accessed by scripts
running on that site only;
AJI9ngIEwcnYbqiMfAvn
qU4OU2FwJSGHyEJS9L7w
R0Ymq0FkyqbtsXYKZCV2
mTFsdWiLlmGnj8DcWbAr
4gMZLsxQyhF7Ls8TujeM
8OeTx4UGuqZKb7axwzFf
41. Can be used with existing apps or while creating a
new one;
Support GET request
Per request token, MITM + CSRF difficult
No dependencies (both PHP & JS side)
Supports AJAX & Dynamic Forms, Supports
ActiveObject (IE) as well;
Has been implemented as PHP library and apache 2.2
module; But design can be extended to other
languages as well; ( It’s a roadmap)
42. • Whitelisting of URLs for cross origin request not
supported as of now;
• There is overhead associated with attaching script
reference to HTML
43. • Porting the design for node.js, python (flask & Django)
• Support for legitimate cross origin requests
• Apache 2.4.x module, windows support
• Shorter time to fix issues & faster releases
44. CSRF Protector Project is based on paper: automatic CSRF protection for Web 2.0 applications by R. Sekar & Riccardo Pelizzi.
The initial implementation was a result of support from awesome mentors like: Kevin W. Wall, Abbas Naderi & Jim Manico
Special thanks to them!
谢谢! Questions??