ROBUST DEFENSES FOR CROSS-SITE REQUEST FORGERY

ADAM BARTH | COLLIN JACKSON | JOHN C. MITCHELL
ROBUST DEFENSES FOR CROSS-SITE REQUEST FORGERY
(Summary by CHINMAYA TRIPATHI)

RESEARCH AT A GLANCE:

This paper points to a new method in CSRF attack: Login CSRF, which would redirect users to an honest webpage but as an attacker. It has put in a decent amount of attention to the use of the ORIGIN flag in HTTPS header, which works effectively to defend against such CSRF attacks as it eliminates the security issues by browser as well as provides a good reference from where the request is coming.

INTRODUCTION (Problem statement): Cross-Site Request Forgery (CSRF) is an attack which forces an end user to do unwanted actions on a web application in which they’re currently authenticated.

CSRF in-depth: The paper divides the CSRF threat model in two parts -
1) In-Scope Threats which include - Forum posters where an attacker can post malicious data on the website with the help of a post (an image, hyperlink etc.), Web attacker where an attacker owning a domain instructs the user’s browser to issue a cross-site request using GET/POST methods. And, Network attacker where the DNS server is compromised and attacker controls over the user's network.
2) Out-Scope Threats which include - XSS where an attacker inject a malicious script into site’s vulnerable/critical section, Malware where the attacker run’s a malicious software on user machine, DNS Rebounding where an attacker obtains network connectivity by binding an IP address to a server of attacker, Certificate Errors, where false certificates are provided to bypass browser security and Phishing where an attacker steals user’s credential using a fake login page or similar.

Until now, the discussions on CSRF focus more on server-side state mutation rather than focusing on browser-side state. And here comes in the Login CSRF vulnerability which takes advantage of this scope of exploit and disrupts the scope of user’s session integrity. The paper presents all the critical points associated with this vulnerability by giving a detailed explanation of how it could be dangerous with examples of some widely used online platforms like PayPal and iGoogle.

Are there any defense mechanisms?
There are three widely used defense mechanisms against CSRF attacks: Validating a secret token which includes validating a secret token which is secretly received by users’ sessions. HTTP Referer header, which includes accepting the requests only from trusted sources. And, XMLHttpRequest, which includes setting a custom header via XMLHttpRequest and validating that the header is present before processing state-modifying requests.

Although all three mechanisms have their own pros and cons, the HTTP Referer validation is a good CSRF defense, but is hampered by the suppression of the Referer header. To evaluate this defense, an experiment was conducted which concluded that although the Referer header is suppressed often over HTTP, it is rarely suppressed over HTTPS, letting current sites prevent CSRF by using HTTPS and strict Referer validation. And later, it was proposed, that to create a robust CSRF defense, browsers should include an “Origin” header with POST requests which let sites defend against CSRF by deploying a few simple web application firewall rules which provides security benefits of the Referer header while addressing the privacy concerns which lead to the widespread suppression of the Referer header.

RESEARCH (experiment):
The objective of this research experiment was to conduct how often and under what circumstances the referrer field is blocked or suppressed by the browser. There were two machines in the lab serving advertisements on numerous channels. Randomly selecting the server when clicking on ads, it generated GET and POST requests and hit the two servers respectively. When permitted by the browser’s security policy, the advertisement generates same-domain requests to the primary server and cross-domain requests to the secondary server. The incoming request was logged by the server along with monitoring header fields like referer and user-agent, HMAC, etc which were sufficient to distinguish the request made by which user.

Observations: When observed, the referer field was suppressed by the HTTP more often than HTTPS. Examining both the type of requests that is same domain and cross-site domain, it drew to a conclusion that referer field was suppressed by the HTTP more often than HTTPS because network proxies are able to remove the header from HTTP traffic but unable to do so from HTTPS traffic. It was also observed that document.referer is suppressed by the browser as referer is suppressed by the network. This could be due to its not being supported in many of the tested browsers.

It was noticed that the referer field was suppressed by the browser due to privacy concerts because when a browser sends referer in header, it shows all the information about the website the request is coming from. There is more evidence of field suppressing for a cross-site request as compared to same site request. This shows the same request when done from two different ways have different impacts.

Conclusion: The researchers drew two conclusions based on their experiment. The CSRF attacks can be defended when using a referer in the header along with HTTPS requests. HTTP requests cannot omit to block requests that do not have a referer header in their request, so use HTTPS instead.

The privacy of each user surfing the web is important, hence all the modern web browsers should implement strict referer validation in incoming requests. Usage of custom HTTP headers can also be an effective way to prevent CSRF attacks because the browser prevents sites from sending custom HTTP headers to another site, but allows sites to send custom HTTP headers to themselves using XMLHttpRequest.

PROPOSAL: Following these experiments, evolved a new proposal where a different attribute was proposed to be added into the header that is “ORIGIN”. While making a POST request, the ORIGIN header respects the privacy concerns of browsers, hence not widely suppressed. It includes limited information required by browsers to verify whether the request is genuine or not, eliminating extra fields like path or query portions of the URL. This request is only sent for POST requests not other (GET) requests which result in saving a lot of information getting leaked while making any request. This approach comes with certain conditions which include elimination of all requests whose ORIGIN flag is null or have an undesired value, hence an attacker can’t make a supporting browser a non-supporting browser.

In addition to this, a browser should implement DNS rebinding and shouldn't opt into cross-site scripting requests from untrusted origins.

CONCLUSION: Concluding the research, it was brought into the attention that CSRF is a widely exploited vulnerability and all the browsers should implement a defense mechanism against this attack. The implementation was categorized in three major categories -
Login CSRF: Requesting to implement strict referer validation while performing any request over HTTPs requests. The site should reject a request if it doesn't have any referer header to defend against any malicious request.
HTTPS: Crucial sites like banking should limit cross-site requests only till their landing pages, and strictly follow the referer header validation to prevent CSRF attacks.
Third-Party content: Site’s including hyperlinks or video players should implement token validation correctly with the help of secure frameworks and bind the token with a user's session, if the framework lacks, they should not accept the request and block them.

REFERENCES:
https://owasp.org/www-community/attacks/csrf
https://seclab.stanford.edu/websec/csrf/csrf.pdf