1. Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License. The OWASP Foundation OWASP AppSec Europe May 2006 http://www.owasp.org/ RequestRodeo: Client Side Protection against Session Riding Martin Johns / Justus Winter University of Hamburg, SVS johns@informatik.uni-hamburg.de 0049-40-42883-2510

2. OWASP AppSec Europe 2006 2 Me, Myself, and I  Martin Johns  johns at informatik.uni-hamburg.de  Security researcher at the University of Hamburg  Member of the secologic project  Research project carried out by SAP, Commerzbank, Eurosec and the University of Hamburg  Goal: Improving software security  Visit us at http://www.secologic.org

3. OWASP AppSec Europe 2006 3 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Conclusion

4. OWASP AppSec Europe 2006 4 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Conclusion

5. OWASP AppSec Europe 2006 5 Agenda  Web Application Authentication  Explicit authentication  Implicit authentication  Session Riding  Client Side Protection  Conclusion

6. OWASP AppSec Europe 2006 6 Explicit Authentication  The authentication credentials are communicated by the web application  URL rewriting: Session token is included in every URL  Form based session tokens  Immune to Session Riding

7. OWASP AppSec Europe 2006 7 Agenda  Web Application Authentication  Explicit authentication  Implicit authentication  Session Riding  Client Side Protection  Conclusion

8. OWASP AppSec Europe 2006 8 Implicit Authentication  Automatically executed by the browser  Cookies  HTTP authentication (Basic, Digest, NTLM)  IP based schemes  Client side SSL  Potentially vulnerable to Session Riding

9. OWASP AppSec Europe 2006 9 Session management with cookies  After the authentication form the server sets a cookie on the client’s browser  As long as this cookie is valid, the client’s requests are treated as authorized

10. OWASP AppSec Europe 2006 10 HTTP authentication (Basic, Digest) ClientServer  The client requests a restricted resource  The server answers with a “401 Unauthorized” response  This causes the client’s browser to demand the credentials  The client resends the request  The user’s credentials are included via the “Authorization” header  Every further request to that authentication realm contains the credentials automatically GET index.html 401 Unauthorized GET index.html Authorization: h3m8dxjh 200 OK HTML data

11. OWASP AppSec Europe 2006 11 IP based authentication Firewall Intranet webserver

12. OWASP AppSec Europe 2006 12 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Conclusion

13. OWASP AppSec Europe 2006 13 Agenda  Web Application Authentication  Session Riding  The attack  Server side countermeasures  Client Side Protection  Conclusion

14. OWASP AppSec Europe 2006 14 Session Riding  Exploits implicit authentication mechanisms  Known since 2001  A.k.a. “Cross Site Request Forgery” (XSRF / CSRF)  Unknown/underestimated attack vector (compared to XSS or SQL injection)  The Attack  Attacker creates a hidden HTTP request inside the victim’s web browser  This request is executed in the victim’s authentication context

15. OWASP AppSec Europe 2006 15 www.bank.com Session Riding (II) Cookie: auth_ok

16. OWASP AppSec Europe 2006 16 www.bank.com Session Riding (II) Cookie: auth_ok www.attacker.org GET transfer.cgi?am=10000&an=3422421

17. OWASP AppSec Europe 2006 17 Session Riding (II)  Problem  Web application does not verify that state changing request was created “within” the web application  Methods  Image (GET)  Frame (POST)  Real World exploits  Deletion / fabrication of data  State alteration of network devices  JavaScript code inclusion  Execution of arbitrary PHP-code

18. OWASP AppSec Europe 2006 18 Session Riding: Attack origin  Reflected: Attacker has to manufacture a website that hosts the origin of the hidden request  Local / stored: Origin of the malicious HTTP request is hosted on the attacked website  Example: Users are allowed to post images with foreign URLs

19. OWASP AppSec Europe 2006 19 Session Riding: Classification  Attack origin  Reflected: Attacker has to manufacture a website that hosts the origin of the hidden request  Stored: Origin of the malicious HTTP request is hosted on the attacked website  Example: Users are allowed to post images with foreign URLs  Target  Broad: Every user of a certain web application is potentially affected by the same request  Explicit: The attack is tailored for one special victim

20. OWASP AppSec Europe 2006 20 Misconceptions  Only accept POST requests  Defends against local attacks  On foreign web pages hidden POST requests can be created with frames  Referrer checking  Some users prohibit referrers  referrerless requests have to be accepted  Techniques to selectively create HTTP request without referrers exist

21. OWASP AppSec Europe 2006 21 Agenda  Web Application Authentication  Session Riding  The attack  Server side countermeasures  Client Side Protection  Conclusion

22. OWASP AppSec Europe 2006 22 Server Side Countermeasures  Misconceptions (don’t)  Only accept POST requests  Referrer checking  Do:  Use one-time tokens for state changing requests  Mirror all foreign content / do not allow users to use arbitrary URLs  Alternative: Switch to explicit authentication

23. OWASP AppSec Europe 2006 23 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Conclusion

24. OWASP AppSec Europe 2006 24 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Concept  Identification of fraudulent requests  Removal of implicit authentication  Conclusion

25. OWASP AppSec Europe 2006 25 RequestRodeo: Concept  Client Side Proxy  Identification of potential fraudulent requests  Removal of implicit authentication

26. OWASP AppSec Europe 2006 26 Identification of suspicious requests  The origin determines the state  Definition: entitled  Only entitled requests are permitted to carry implicit authentication information An HTTP request is classified as entitled only if: – It was initiated because of the interaction with a web page (i.e. clicking on a link, submitting a form or through JavaScript) and – the URLs of the originating page and the requested page satisfy the “same origin policy”

27. OWASP AppSec Europe 2006 27 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Concept  Identification of fraudulent requests  Removal of implicit authentication  Conclusion

28. OWASP AppSec Europe 2006 28 Processing HTTP responses  Adding tokens to URLs  HTML code in HTTP responses is processed  Identification of elements that potentially cause HTTP requests  The target URLs of these elements are enhanced with a URL token  The tokens are kept together with the response’s URL in a table  This way the proxy is able determine a request’s origin  “a reliable referrer”

29. OWASP AppSec Europe 2006 29 Processing HTTP responses (II)  Example:    Augmenting JavaScript:  Impossible to find all URLs in JS  Instead: Altering the code that creates the requests: document.location = url;  document.location = __rrt_addToken(url);  Unreliable, therefore additional referrer checks

30. OWASP AppSec Europe 2006 30 Checking HTTP requests  Every HTTP request is checked for a URL token  If such a token exists, the originating URL is retrieved  If the domains of the request and its origin do not match, implicit authentication information gets removed

31. OWASP AppSec Europe 2006 31 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Concept  Identification of fraudulent requests  Removal of implicit authentication  Conclusion

32. OWASP AppSec Europe 2006 32 Removal of implicit authentication: Cookies  Cookies are communicated via the HTTP header field “Cookie”  If a not “entitled” request contains such a field, it is removed by the proxy before forwarding the request a

33. OWASP AppSec Europe 2006 33 Removal of implicit authentication: Cookies  Cookies are communicated via the HTTP header field “Cookie”  If a not “entitled” request contains such a field, it is removed by the proxy before forwarding the request a RequestRodeo Client GET index.html Cookie:SID=728gdshg7 Server GET index.html Implicit authentication

34. OWASP AppSec Europe 2006 34 Removal of implicit authentication: Cookies  Cookies are communicated via the HTTP header field “Cookie”  If a not “entitled” request contains such a field, it is removed by the proxy before forwarding the request  A cookie’s domain value should be respected  Example:  cookie’s domain value: “foo.org”  a request from “www.foo.org” to “order.foo.org” is allowed to carry the cookie

35. OWASP AppSec Europe 2006 35 Removal of implicit authentication: HTTP auth  Simply removing unentitled “Authorization” headers does not work

36. OWASP AppSec Europe 2006 36 RequestRodeo Client GET index.html Authorization: xx38476239846… Server 401 Unauthorized GET index.html Authorization: xx38476239846… GET index.html Implicit authentication 401 Unauthorized Still not “entitled”

37. OWASP AppSec Europe 2006 37 Removal of implicit authentication: HTTP auth  Simply removing unentitled “Authorization” headers does not work  In this case the browser re-requests the same URL  The URL is still not entitled  The proxy has to add a token to the request’s URL  This is done using a 302 “Temporarily moved” response

38. OWASP AppSec Europe 2006 38 RequestRodeo Client GET index.html Authorization: xx38476239846… Server 302 Moved Temporarily Location: index.html?__rrt=f4s7 GET index.html?__rrt=f4s7 Authorization: xx38476239846… 401 Unauthorized GET index.html?__rrt=f4s7 Authorization: xx38476239846… GET index.html?__rrt=f4s7 Authorization: xx38476239846… 200 OK HTML Data 200 OK HTML Data Implicit authentication Explicit authentication entitled: index.html?__rrt=f4s7

39. OWASP AppSec Europe 2006 39 IP-based authentication  Unentitled requests are only allowed if their target is worldreachable  For this reason a “reflection server” is employed  The reflection server is hosted offsite (i.e. on the other side of the corporate firewall)  Before allowing an unentitled request, the proxy verifies that the reflection server is able to access the request’s target  Caching of checked IPs to minimize the performance penalty

40. OWASP AppSec Europe 2006 40 IP based authentication Firewall Intranet webserver RequestRodeo Malicious site Reflection server HEAD ?OK

41. OWASP AppSec Europe 2006 41 IP based authentication Firewall Intranet webserver RequestRodeo Malicious site Reflection server ?DENY HEAD 

42. OWASP AppSec Europe 2006 42 Agenda  Web Application Authentication  Session Riding  Client Side Protection  Conclusion

43. OWASP AppSec Europe 2006 43 Implementation  Proof of concept  Implemented in Python  Using the “Twisted” framework  Released under the GPL

44. OWASP AppSec Europe 2006 44 Discussion  Conservative Approach  Connections are allowed  Only removal of implicit authentication  Request to public resources are uninhibited  Limitations  No protection against “local” attacks  NTLM / Client Side SSL not implemented  Future work  Browser integration  Addition of anti XSS techniques

45. OWASP AppSec Europe 2006 45 The End  Thank you for your attention  Questions?  Comments?