Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian

1. Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian

2. Gmail hacked !!! In late 2007 Gmail had CSRF vulnerability. While being logged into Gmail, if the user visited a malicious site, the site could generate a request to Gmail that Gmail treated as part of its on going session with the victim. A web attacker exploited this CSRF vulnerability to inject an email filter into David Airey's Gmail account, by causing the malicious page to perform a multipart/form-data POST to oneof the Gmail interfaces. This filter would forward all the e-mails to attackers email. Unfortunately the attacker gained access to davidairey.com as Airey's domain registrar used email authentication, leading to significant inconvenience and financial loss.

3. Overview Cross-Site Request Forgery (CSRF) In CSRF attack, a malicious site instructs a victims browser to send a request to an honest site, as if the request were part of the victim’s interaction with the honest site, leveraging the victim’s network connectivity and the browser’s state, to disrupt the integrity of the victim’s session Login Cross-Site Request Forgery In this variation of CSRF attack, the attacker forges a cross-site request to the login form with attacker's credentials, logging the victim into the honest website as the attacker.

4. Overview – Defense Techniques Validating a secret token Include a secret token with each request and to validate that the recieved token is correctly bound to the user's session. Validating the HTTP Referer header Accept requests only from trusted sources by verifying the referer header. Validating custom header Set a custom header via XMLHttpRequest and validating that header before state modifying requests.

5. CSRF Defined CSRF exploits the trust that a site has in a user's browser unlike the trust a user has for a particular site. Browser's security policy allows web sites to send HTTP requests to any network address. This vulnerabiliy would allow the attacker to control content rendered by the browser. The attacker could send requests to other machines behind the firewall using the user's browser. Requests sent via the browser's network stack typically include browser state such as cookies, client certificates or basic authentication headers.

6. CSRF Defined – Threat Models Forum Poster Websites such as forums let users to submit passive contents such as images or hyperlinks. Eg: The attacker could craft a HTML image element that references victim's bank site (instead of image element). <img src = "http://bank.example.com/withdraw?account=bob&amount= 1000000&for=Fred">

7. CSRF Defined – Threat Models Web Attacker The attacker owns a domain name e.g attacker.com, has a valid HTTPS certificate and operates a web server. If a user visits this website, the attacker could mount a CSRF attack by instructing the browser to issue cross-site requests using both the GET and POST methods. Network Attacker The attacker controls the user's network connection. A compromised DNS server can be exploited by the attacker to control the user's network.

8. Login CSRF- User perspective User visits the honestwebsite and logs in. The user thenloads the attackerwebsite or encounter’sattackeriframe on another site. Attackersends HTTP request to the honest site Victim site assumes the requestoriginatefromitself

9. Login CSRF- What really happened The attacker forges a login request to an honest site using the attacker’s user name and password at the honest site. If forgery succeeds the server responds with a set cookie header that instructs the user's browser to mutate its state by storing a session cookie. Now the user is logged into the honest site as the attacker.

10. Login CSRF- What really happened

11. Existing CSRF Defense Secret Validation token We use a validation token to determine whether the request came from an authorized source. Validation token must be hard to guess by the attacker If the request is missing a validation token or the token does not match the expected value the server should reject the request.

12. Techniques for generating and validating tokens Session Identifier The user's session identifier is used as the secret validation token. On every request the server validates if the token matches the session identifier. Disadvantage is that anyone who reads the contents of the page, which contains the user's session identifier in the form of CSRF token, can impersonate the user till the session expires Existing CSRF Defense

13. Techniques for generating and validating tokens Session Independent Nonce Instead of using the user’s session identifier, the server stores a random nonce as a cookie when the user first visits the site. On every request the server validates that the token matches the value stored in the cookie. Disadvantage is that an active network attacker can overwrite the session independent nonce with his or her own CSRF token, even if the web application is hosted on the HTTPS. Existing CSRF Defense

14. Techniques for generating and validating tokens Session-Dependent Nonce As a refinement of nonce technique, the server stores the state that binds the user's CSRF to the user's session identifier. On every request the server validates that the supplied CSRF token is associated with the user's session identifier. Disadvantage is that the server needs to maintain a large state table to validate the tokens. Existing CSRF Defense

15. Techniques for generating and validating tokens HMAC of Session Identifier Instead of using the server side state to bind the CSRF token to the session identifier we use cryptography to bind the two values. As long as the site's server share the HMAC key each server can validate the CSRF token. HMAC ensures that an attacker who learns the user's CSRF token cannot infer the user's session identifier. Existing CSRF Defense

16. Where the Secret validation token fails Many websites and CSRF frameworks fail to implement secret token defense correctly. One common mistake is to leak the CSRF token during cross site request. Eg. If the honest site appends the CSRF token to the hyperlinks to another website then that website gains the ability to forge cross-site requests against the honest site. Existing CSRF Defense

17. The Referer Header When the browser issues an HTTP request, it includes a referer header that indicates which URL initiated the request. This information in the Referer header could be used to distinguish between same site request and cross site request. CSRF Defense

18. Privacy Issues with Referer header The referer contains senstive information that impinges on the privacy The referer header reveals contents of the search query that lead to visit a website. Some organizations are concerned that confidential information about their corporate intranet might leak to external websites via Referer header CSRF Defense

19. Referer header Implementation Lenient Referer Validation The site blocks request whose referer header has incorrect value If the request lacks the header then the site accepts the request. Disadvantage is that the attacker can cause the web browser to suppress the referer header. Eg. Request issued from ftp and data URLs do not carry Referer headers. CSRF Defense

20. Referer header Implementation Strict Referer Validation The site blocks the request whose referer header has incorrect value and also blocks request that lack a referer header. Disadvantage is that some browsers and network configurations suppress referer header for legitimate requests. CSRF Defense

21. Feasibility of Referer Header implementation Strict referer validation is feasible over HTTPS because only a tiny percentage (0.05 to 0.22%) of browsers suppress the header and most login requests are typically issued over HTTPS. Over HTTP, sites cannot afford to block requests for lack of a referer header because they would cease to be compatible with sizable percentage of users (3 – 11%). CSRF Defense

22. Custom HTTP Headers Browsers prevent sites from sending custom HTTP headers to another site but allow sites to send custom HTTP headers to themselves. Cookie value is not actually required to prevent CSRF attacks, the mere presence of the header is sufficient. To use this scheme as a CSRF Defense, a site must issue all state modifying requests using XMLHttpRequest, attach the header and reject all requests that do not accompany the header . CSRF Defense

23. Origin Header. Modify the browsers to send a Origin Header with POST request that identifies the origin that initiated the request. Origin header improves on the referer header by respecting the user's privacy. Origin header includes the information only needed to identify the party that initiated the request (scheme, host and port of the active document) It does not contain path or query portion of the URL. Origin header is sent only for POST requests while Refer header is sent for all request. PROPOSAL

24. Origin Header. To use origin header the sites should behave as follows: All state modifying requests, including login requests must be sent using the POST method. All state modifying GET requests must be blocked If origin header is present, the server must reject any requests whose Origin header contains an undesired value. For eg, a site could reject all requests whose origin indicated the request was initiated from another site. PROPOSAL

25. Impementation Origin header was implemented in browser side in eight-line patch to WebKit, open source safari component and in a 466 line extension to firefox. On the server side origin header was used to implement a web application firewall for CSRF in three lines of ModSecurity, a firewall language for apache. PROPOSAL

26. Different CSRF defenses for different use cases Strict referer validation to protect against login CSRF because login forms typically submit over HTTPS. Sites that incorporate third party content such as images and hyperlink should use a framework that implements secret token validation, eg. Ruby-on-Rails . In the long term, the propose origin header that improves on privacy issues of Referer validation and eliminates the need for secret token defenses, allowing sites to protect both HTTPS and non HTTPS requests could be implemented as a CSRF defense. Conclusion

27. Questions