Lieven

1
CsFire Browser-Enforced Mitigation Against CSRF

• Lieven Desmet and Philippe De Ryck
• Lieven.Desmet_at_cs.kuleuven.be

2
About myself

• Lieven Desmet
• Research manager of the DistriNet Research Group
  (K.U.Leuven, Belgium)
• Active participation in OWASP
• Board member of the OWASP Belgium Chapter
• Co-organizer of the academic track on past OWASP
  AppSec Europe Conferences

3
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

4
Cross-Site Request Forgery (CSRF)

• Synonyms one click attack, session riding,
  confused deputy, XSRF,
• Description
• External server (or HTML feed) is under control
  of the attacker
• Attacker triggers requests from the victims
  browser to targeted website
• Unauthorised by the victim
• Legitimate from the perspective of the server
• Victim typically has an account of the targeted
  server (and is logged in)

5
CSRF (XSS) example
HTTP request injecting a script into the
persistent storage of the vulnerable server
D
D
HTTP response
Attacker
Regular http request
Vulnerable server
Http response containing script as part of
executable content
Unauthorized HTTP request
Victim
HTTP response
Targeted server
6
Implicit authentication

• HTTP authentication basic, digest, NTLM,
• Cookies containing session identifiers
• Client-side SSL authentication
• IP-address based authentication
• Notice that some mechanisms are even completely
  transparent to the end user!
• NTLM, IP-address based,

7
Risk considerations

• Threat agent
• Any website or HTML feed that your users access
• Impact
• Sending unauthorized requests
• Login CSRF
• Attacking the Intranet

BJM08
8
CSRF in practice

• W. Zeller and W. Felten, Cross-site Request
  Forgeries Exploitation and Prevention, Technical
  Report 2008
• CSRF in the real world
• New York Times (nytimes.com)
• ING Direct (ingdirect.com)
• Metafilter (metafilter.com)
• YouTube (youtube.com)

ZF08
9
XSRF ING Direct

• XSRF attack scenario
• Attacker creates an account on behalf of the user
  with an initial transfer from the users savings
  account
• The attacker adds himself as a payee to the
  users account
• The attacker transfer funds from the users
  account to his own account
• Requirement
• Attacker creates a page that generate a sequence
  of GET and POST events

10
ING Direct request protocol
GET https//secure.ingdirect.com/myaccount/INGDire
ct.html?commandgotoOpenOCA POST
https//secure.ingdirect.com/myaccount/INGDirect.h
tml commandocaOpenInitialYES, I WANT TO
CONTINUE..x44YES, I WANT TO CONTINUE..y25 POST
https//secure.ingdirect.com/myaccount/INGDirect.h
tml commandocaValidateFundingPRIMARY
CARDtrueJOINTCARDtrueAccount
NicknameACCOUNT NAME FROMACCT
0TAMTINITIAL AMOUNTYES, I WANT TO
CONTINUE..x44YES, I WANT TO CONTINUE..y25 XTY
PE4000USD XBCRCDUSD POST https//secure.ingdire
ct.com/myaccount/INGDirect.html commandocaOpenAc
countAgreeElectronicDisclosureyesAgreeTermsCond
itionsyesYES, I WANT TO CONTINUE..x44 YES, I
WANT TO CONTINUE..y25YES GET
https//secure.ingdirect.com/myaccount/INGDirect.h
tml?commandgoToModifyPersonalPayeeModeAddfrom
displayEmailMoney POST https//secure.ingdirect.co
m/myaccount/INGDirect.html commandvalidateModify
PersonalPayeefromdisplayEmailMoneyPayeeNamePA
YEE NAMEPayeeNickname chkEmailonPayeeEmail
PAYEE EMAILPayeeIsEmailToOrangetruePayeeOrang
eAccountPAYEE ACCOUNT NUM YES, I WANT TO
CONTINUE..x44YES, I WANT TO CONTINUE..y25 POST
https//secure.ingdirect.com/myaccount/INGDirect.h
tml commandmodifyPersonalPayeefromdisplayEmail
MoneyYES, I WANT TO CONTINUE..x44 POST
https//secure.ingdirect.com/myaccount/INGDirect.h
tml commandvalidateEmailMoneyCNSPayID5000Amou
ntTRANSFER AMOUNTCommentsTRANSFER
MESSAGE YES, I WANT TO CONTINUE..x44 YES, I
WANT TO CONTINUE..y25show1buttonSendMoney POS
T https//secure.ingdirect.com/myaccount/INGDirect
.html commandemailMoneyAmountTRANSFER
AMOUNTCommentsTRANSFER MESSAGE YES, I WANT
TO CONTINUE..x44YES, I WANT TO CONTINUE..y25
11
ING Direct wrap up

• Static protocol
• No information needed about vulnerable client
• Can be encoded as a single sequence
• 2 GET requests
• 7 POST requests
• Can be transparent for the vulnerable client
• Single requirement vulnerable client is
  implicitly authenticated

12
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

13
Quantification of cross-domain traffic

• Need for better insights
• To identify the nature of nowadays web
  interactions
• To find an appropriate balance between usability
  and security
• Analysis of real-life traffic
• 50 grad students
• 10 week period
• Total 4.7M requests

14
Data collection

• Via custom-made browser extension
• Fully transparent for the end-user
• Extension installed as part of lab exercise
• Logs relevant information for each outgoing
  request
• Originator
• Domain, scheme, DOM element,
• Request
• Target domain, scheme, method, URL path, input
  parameter keys, cookie keys, HTTP auth?, user
  interaction?, redirect?,

15
Privacy considerations

• Only keys were recorded, no values or credentials
• Cookies
• Input parameters
• HTTP authentication
• Full URLs were not recorded
• Only filename extension
• No client information was recorded
• No browser information (except for logger
  version)
• No IP information
• No usernames

16
Quantification of cross-domain requests
GET POST Total
cross-domain requests (strict SOP) 1,985,052 (41.97) 59,415 (1.26) 2,044,756 (43.24)
cross-domain requests (relaxed SOP) 1,503,990 (31.80) 56,260 (1.19) 1,560,519 (33.00)
All requests 4,426,826 (93.61) 302,041 (6.39) 4,729,217 (100.00)
17
Cross-domain requests characteristics (under
relaxed SOP)
Input parameters User initiated Cookies HTTP auth Total
GET requests 533,612 (35.47) 6,837 (0.45) 528,940 (35.17) 1,357 (0.11) 1,503,990
POST requests 41 (0.07) 26,914 (47.84) 12,442 (24.36) 269 (0.01) 1,560,519
18
Interesting conclusions

• Large number of requests has
• Input parameters (-35)
• Cookies (-35)
• Use of HTTP authentication is very limited
• Additional information
• Total number of requests 4,729,217
• Total number of domains 23,592
• 3338 domains use redirects (14.15)
• 5606 domains use cookies(23.76)
• Only 2 domains use HTTP authentication

19
Need for more benchmarks and data sets

• Interesting data set to study and compare CSRF
  mitigation techniques
• It would be interesting to have more similar data
  sets available for web application security
• To understand nature of nowadays web applications
  and interactions
• To have benchmarks to compare different solutions

20
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

21
Mitigation against CSRF

• Same-Origin Policy
• No protection against CSRF ?
• Enabler for token-based approaches
• Token-based approaches
• Most promising techniques against CSRF ?
• Not widely adopted yet ?
• Client-side mitigation !?!

22
RequestRodeo (Martin Johns, 2006)

• Token-based approach, run as client-side proxy
• Intercepts requests and responses
• Adds and verifies tokens
• Strips cookies and HTTP authentication
  credentials
• Also protects the intranet via external proxy
• Works well on classical web applications
• Behaves badly in web 2.0 applications

23
Browser Add-ons

• Browser add-ons can use full context
• CSRF protector, BEAP (antiCSRF), RequestPolicy,
  NoScript, CsFire,
• Mitigation blocking or stripping request
• Hard to find right balance
• Security
• Usability

24
Requirements for client-side mitigation

• R1. Independent of user input
• Substantial fraction of cross-domain traffic
• Most users dont know necessary/safe interactions
• R2. Usable in a web 2.0 environment
• Mashups, AJAX, Single-Sign On,
• R3. Secure by default
• Minimal false positives in default operation mode

25
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

26
CsFire

• Client-side mitigation technique developed by
  DistriNet, K.U.Leuven
• Builds on RequestRodeos concept of stripping
• Main purpose
• Finding a better balance between security and
  usability
• Full paper available
• Ph. De Ryck, L. Desmet, T. Heyman, F.Piessens, W.
  Joosen. CsFire Transparent client-side
  mitigation of malicious cross-domain requests,
  LNCS volume 5965, pages 18-34, Pisa, Italy, 3-4
  February 2010

27
Client-side Policy Enforcement
Web Server
Browser
Browser Core
BrowsingContext
Policy Information Point
28
Client-side Protection

• Collect Information
• Origin and Destination
• HTTP Method
• Cookies or HTTP authentication present
• User initiated

29
Client-side Policy Enforcement
Web Server
Browser
Browser Core
BrowsingContext
Policy Decision Point
Policy Information Point
30
Client-side Protection

• Determine action using policy
• Accept
• Block
• Strip cookies
• Strip authentication headers
• ASK (mainly for debugging)

31
Client-side Policy Enforcement
Web Server
Browser
Browser Core
BrowsingContext
Policy Enforcement Point
Policy Decision Point
Policy Information Point
32
Cross-domain Client Policy
GET
User Initiated
ACCEPT
No Parameters
STRIP
Not User Initiated
Parameters
User Initiated
STRIP
Not User Initiated
STRIP
POST
User Initiated
STRIP
Not User Initiated
STRIP
33
Prototyped as CsFire

• http//distrinet.cs.kuleuven.be/software/CsFire

34
Comparison Request Policy
CsFire
GET
User Initiated
ACCEPT
No Parameters
ACCEPT
STRIP
Not User Initiated
BLOCK
Parameters
User Initiated
STRIP
ACCEPT
Not User Initiated
STRIP
BLOCK
POST
User Initiated
STRIP
ACCEPT
Not User Initiated
STRIP
BLOCK
35
Comparison BEAP (AntiCSRF)
CsFire
GET
HTTP
HTTP AUTH
COOKIES
ACCEPTSTRIP
HTTPS
STRIP
POST
STRIP
STRIP
36
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

37
Prototype Evaluation

• CSRF Scenarios
• 59 scenarios
• Test prevention capabilities
• Contains attacks launched from
• CSS Attributes
• HTML attributes
• JavaScript
• Redirects

38
Prototype Evaluation

• Real-life test users
• 60 test users, several weeks
• Detect issues in security usability balance
• Option to provide feedback
• Feedback via Mozilla Add-On users
• About 14000 downloads since release
• 4000 daily users
• Positive feedback
• Some suggestions for additional server policies

39
CsFire statistics
40
Evaluation Results

• CSRF scenarios passed successfully
• Test users very positive
• Only a few minor inconveniences detected
• Re-authentication after cross-domain request
• Works well with Web 2.0
• Works well popular SSO mechanisms
• Issues with sites spanning multiple domains
• Example Google, Microsoft (Live, MSN, )

41
Evaluation Results

• Sites spanning multiple domains
• Traffic resembles a CSRF attack
• Client cannot distinguish legitimate traffic
• Additional information needed
• Specify intended cross-domain requests
• Server policy identifies desired cross-domain
  requests
• In CsFire prototype
• Server policies via policy server
• Local policies

42
Some more technical issues

• Handling of redirect chains
• Obfuscated IPs
• Graceful protection of HTTP auth
• CORS Support

43
Redirect Chains Authentication

• Redirect to authentication service
• Submit authentication credentials
• Redirect to original site
• Include token in URL
• Redirect to requested page

1.
2.
3.
4.
x.com
auth.com
x.com
x.com
auth.com
44
Redirect Chains Policy Enforcement

• Default Firefox information
• Keeps first origin throughout chain
• Breaks same-origin redirect in chain

x.com
auth.com
x.com
x.com
auth.com
ACCEPT
STRIP
STRIP
Default Information
STRIP
45
Redirect Chains Policy Enforcement

• Modified CsFire information
• Uses last origin and new origin
• Fixes internal redirects in chains
• STRIP after auth still breaks some scenarios

x.com
auth.com
x.com
x.com
auth.com
ACCEPT
STRIP
STRIP
STRIP
Default Information
ACCEPT
STRIP
STRIP
Modified Information
ACCEPT
46
Redirect Chains Other Cases

• STRIP causes loss of session information ?
• Potential Fix remember redirects and allow
  reverse
• x.com ? pay.com so pay.com ? x.com is
  allowed
• Requires further investigation
• Security impact of open redirectors?

x.com
Pay.com
x.com
x.com
Pay.com
ACCEPT
STRIP
STRIP
ACCEPT
47
Obfuscated IPs

• Compensate for the forgiveness of browsers
• Decimal notation 10.0.0.1
• Octal dotted notation 0300.0000.0002.0353
• Hexadecimal dotted notation 0x42.0x66.0x0d.0x63
• Hexadecimal notation 0xC00002EB
• 32bit notation 1113984355
• More info?
• http//joshtime.com/random/cool-ip-address-obfusca
  tion/

48
Graceful protection of HTTP auth

• CsFire (in combination with Firefox 4.0)
• HTTP authentication is stripped (via privacy
  mode)
• User is requested to enter credentials again
• Needs gecko 1.9.3 (mozilla bugreport 537670)
• In contrast, earlier approaches do not allow
  cross-domain requests with HTTP authentication

49
CORS Support

• Currently no explicit support
• Same policy applies to CORS requests
• Future support 2 options
• Follow advice from server
• Protect user (current approach)
• Servers may be too permissive (e.g. flash policy)

50
Outline

• Introduction
• Quantification of cross-domain traffic
• Client-side mitigation against CSRF
• CsFire
• Evaluation
• Conclusion

51
Conclusion

• Traffic analysis reveals cross-domain traffic
  patterns
• Requirements for a client-side solution
• Security
• Usability
• Balanced client-side solution
• Secure by default
• User-independent
• Implementation as Firefox add-on
• Technical evaluation with CSRF scenarios
• Real-life evaluation with test users

52
References

• W. Zeller and W. Felten, Cross-site Request
  Forgeries Exploitation and Prevention, TR 2008
• M. Johns, J. Winter, RequestRodeo client side
  protection against session riding, OWASP AppSec
  2006
• Ph. De Ryck et al., CsFire Transparent
  client-side mitigation of malicious cross-domain
  requests, ESSoS 2010
• A. Barth, C. Jackson, and J. Mitchell, Robust
  Defenses for Cross-Site Request Forgery, CCS 2008

53
CsFire Available now!

• http//distrinet.cs.kuleuven.be/software/CsFire