CSRF
Cross Site Request Forgery
Cross SIte Request Forgery
Making a request on behalf of a user without their consent or knowledge
CROSS SITE REQUEST FORGERY
Requires some degree of social engineering.
But you already know that, don't you?
Cookies
Alice authenticates with http://example.com
Server sends back a cookie:
ASPSESSID = akj32uad980wa4rlmaf9034
This is sent up with every request to example.com
Server looks at cookie, and uses that session
Cookies
The referer [sic] doesn't matter!
Where the request is going to is the important thing
Cookies
Cookies are NOT the problem
Trusting automatic behaviour is!
NTLM
Alice goes to http://example.com
Server sends a CHALLENGE_MESSAGE
Client responds with an AUTHENTICATE_MESSAGE
Server uses this to authenticate the request
NTLM
This is automatic, using the current windows session
The request is important, not the referer
Exploit
Simply make a request to a site that the user has an authenticated session with!
Example
<see example>
Possibilities
Add or elevate users to admin roles
Delete stuff
Create malicious resources
(eg. Rich Text Objects with scripts)
imPossibilities
Read bank statement information
Screen scrape
Limitations - write only
Requests can be GET or POST
If request uses GET, the data cannot be read programatically cross-domain
<img src="http://mybank.com/balance.png" />
Limitations - no XHR
Same limitations as always
No cross-domain XHRs
unless specifically allowed by server
limitations - no timing
Queuing requests is a guessing game
Eg.
Adding a user
Making them admin
Protection
A separate authentication token for write requests
Protection
Alice authenticates with http://example.com
Server responds with cookie
ASPSESSID=l23j45093ifdpm34r0
CSRF=klj45983uf0934nocn834
Server sends key down
<input type="hidden" name="CSRF" value="klj45983uf0934nocn834" />
Protection
Alice creates a user
Request is constructed:
URL: http://example.com/add-user
Data: user=jane&CSRF=klj45983uf0934nocn834
Data: user=jane&CSRF=klj45983uf0934nocn834
Cookie: ASPSESSID=l23j45093ifdpm34r0
Server opens the session, compares the CSRF token, sees it's good and does its thing
Protection
Bob tells Alice to go to http://dr-nefarious.com
Malicious site sends a request to
URL: http://example.com/add-user
Data: user=jane
Data: user=jane
Cookie: ASPSESSID=l23j45093ifdpm34r0
Server rejects the request
Hardening
Regenerate session every login
Avoid long-lasting logins
Regenerate CSRF tokens frequently
How do we fare - safe bits
Anything using StatePocketKey
Anything relying on the PageKey
Actions marked with POST that use View States
(specifically, view state keys)
How do we fare - UNsafe bits
Webforms
Actions that don't require Viewstate
SOAP Web Services (possibly)
deck
By xwipeoutx
deck
- 736
