Robust Defenses for Cross-Site Request Forgery Review

Transcription

1 Robust Defenses for Cross-Site Request Forgery Review Network Security Instructor:Dr. Shishir Nagaraja Submitted By: Jyoti Leeka October 16, Introduction to the topic and the reason for the topic being interesting In Cross-Site Request Forgery an attacker tricks the victim s browser to interact with a trustworthy site by impersonating the victim and breaking victim s session with the site. Login Cross Site Request Forgery is a form of Cross-Site Request Forgery attack, in which an attacker tricks the victims browser by logging the victim into an honest site as the attacker. This topic is interesting as it tries to protect a users privacy by safe guarding him against Cross-Site Request Forgery attacks. 2 Questions that the paper asks and how are those questions interesting This paper explores the ways of protecting a user against Cross-Site Request Forgery attacks. This question interesting as it tries to find methods to protect a users privacy by safe guarding him against Cross-Site Request Forgery attacks. 3 How does it answer the questions In Cross-Site Request Forgery an attacker breaks victim s session with the site by tricking the victim s browser to interact with a trustworthy site as the attacker. Thus by tricking the browser the attacker can access the following resources: 1. Network Connectivity: By carrying out the attack, the attacker gets access to any site behind the firewall. 2. By carrying out the attack, the attacker can read the users session cookies, thus breaching the privacy of the users. 3. By carrying out the attack, the attacker can set cookies in the browser, thus writing the browser state. The threat model which the authors propose is given below: 1. The threats which are taken into consideration by the author are given below: (a) Forum Poster: Many sites such as forums permit the users to add content to the site in the form of images or links. The attacker can take advantage of this, by writing into the source of the image the attackers malicious URL for carrying out the CSRF attack. (b) Web Attacker: A web attacker has an HTTPS certificate for his site and can carry out the CSRF attack by its web server. 1

2 (c) Network Attacker: A network attacker is capable of carrying out active CSRF attacks. 2. The threats which are not taken into consideration by the author are given below: (a) Cross Site Scripting: The attacker in this threat model does not try to inject malicious script into web pages viewed by other users. Hence this threat model rules out Cross Site Scripting Attack. (b) Malware: The threat model does not take into consideration the attack by which an attacker may inject malicious code into the users system, thus compromising the users session. (c) DNS Rebinding: Although DNS rebinding attacks are similar to CSRF attacks, but their defenses are different. The threat model does not take DNS rebinding attacks into consideration. (d) Certification Errors: This threat model assumes that users don t neglect the warning issued by the browser against certification errors. Hence this model assumes that the users do not visit the site with certification errors. (e) Phishing attacks: Phishing attacks occur when an attacker redirects a user to a fake website in order to collect users information, for example, passwords. One way in which an attacker may accomplish this redirection is by sending the user an containing the link of that website. This threat model does not take phishing attacks into consideration. (f) User Tracking: Some websites track the users browsing activities. This threat model does not take this into consideration. Login Cross Site Request Forgery is a form of Cross-Site Request Forgery attack, in which an attacker tricks the victims browser by logging the victim into an honest site as the attacker. The attacker s cookie which is stored in the users browser, collects information about the user, thus breaching the users privacy. Some of login CSRF attacks are mentioned below: 1. A login CSRF attack is depicted in the figure below: In the above figure an attacker gets to know the search history of the victim by first attracting the victim towards his site. Then the attacker entices the victim to click on a malicious link thus launching a CSRF attack and logging the victim as the attacker. This way the attacker 2

3 is able to track the victims search history and it gets stored into the victims accounts search history. 2. Paypal: As paypal lets its customers transfer money in each other accounts. Hence an advantage of this fact and perform a CSRF attack by first luring a victim to visit a malicious site and clicking on a malicious link in that site which takes him to PayPal s site, where the user logs in. But the attacker would log him into its account and when the user enters his credit card information, the attacker would transfer funds from the victim s credit card to its own account. Some of the present CSRF defenses along with the loopholes in these defenses are mentioned below: 1. Secret Validation Token: In order to figure out that the request has come from an honest sender secret validation tokens are used. Some of the techniques for creating secret tokens are mentioned below: (a) The users session identifier can be used as the secret validation token. The drawback of this technique is that sometimes users unknowingly post their web pages containing session identifiers on their forums or s, which an attacker can extract to carry out the attack. (b) A freshly generated random value can be used as the session identifier. When a request is generated by the browser the server matches this random value to the value stored in the cookie. (c) The server stores the users session value with the CSRF token. Every time a request is sent to the server it matches the request token with the value of the session identifier. The disadvantage of this approach is the requirement to store huge amount of data on the server. The author states that this approach has been adopted by CSRF, CSRFx and NoForge. (d) A server can store the HMAC value of the session identifier. And when a request is sent to the server it matches the value of the CSRF token containing the HMAC with the value of the HMAC of the session identifier. The disadvantage of the above approaches is that websites fail to implement the secret token defense correctly. Consider the example of NoForge which implements third type of secret token. NoForge attaches the secret token to all the hyperlinks and form submissions. The approach of NoForge has the following loopholes: (a) HTML pages created on the client side does not include the CSRF token. (b) NoForge allows a web application to create links to other sites, this site receives the CSRF token values of the user, when the user clicks on such links. (c) NoForge does not have any defense against log-in CSRF attacks, as the matching of the token is done when the user already has a session identifier. 2. Referrer Header: Referrer Header is used to identify the site which generated the request. If a website uses the Referrer header as a shield against CSRF attack, it has the following two options to choose from: (a) Lenient Referrer Validation: The site s server obstruct only those request which contain erroneous referrer header, rest of the requests including requests containing no referrer header are accepted. (b) Strict Referrer Validation: The site s server obstructs requests containing erroneous referrer header and no referrer header. The following experiment was conducted to find out the compatibility of the strict referrer header. Experiment: (Reference for the experiment: Robust Defenses for Cross-Site Request Forgery 3

4 by Adam Barth et.al.) The author bought 283,945 advertisement impressions by employing two advertisement networks. On Advertisement Network A the keywords were Firefox, Game, Internet Explorer, Video, You Tube. While on Advertisement Network B the keywords were Ballet, Finance, Flowers, Food and Gardening. When the advertisements were rendered they generated a random number for identifying them. One of the two server sends content over both HTTP and HTTPS. On getting request from the Client the server records the Referrer Header, the User-Agent header, the date, the clients network address, session identifier and document.referrer value. The results obtained by the authors were: (a) The referrer header was removed for a greater number of times for HTTP requests than for HTTPS. The reason for this being, the ability of the proxies to remove the header for HTTP but not the HTTPS. (b) The browsers remove both the referrer header and the value of document.referrer, whereas the network removes only the referrer header. But as referrer header was observed to be removed more often, hence its value must been removed by the network. The authors obtained the following two conclusions: (a) The server must adopt strict referrer validation for HTTPS and lenient referrer validation for HTTP. (b) In order to protect users privacy, Referrer header must not be used over HTTP. 3. Custom HTTP headers: In order to protect a user from CSRF, custom HTTP headers can be used. Custom HTTP headers cannot be send from one site to another site but can be send from one site to itself using XMLHttpRequest. In order to defend a site against CSRF, the authors propose that browsers must be altered to send Origin headers with post request. The origin header indicates the origin of the website which sent the request. The origin header maintains the users privacy in the following ways: 1. The origin header contains just the requisite amount of information which is required to identify the sender. 2. By just clicking hyperlinks the origin header is not sent to the server. To use the origin header the server should modify its policy as follows: 1. All the requests must be sent by the POST method. 2. Any request with erroneous origin header should be rejected. The following is the security examination of the origin header: 1. Since the supporting browsers would contain an Origin header in POST requests. Hence the attacker can not change the supporting browser to be non supporting. 2. To prevent an attacker from exploiting the vulnerability of cross site requests, all cross site HTTP requests should be made with trusted websites. The origin header imbibes the features from the following four proposals: 1. Cross-Site XMLHttpRequest uses Access-Control-Origin header to identify the origin of the sender. Cross-Site XMLHttpRequest s working group accepted the authors suggestion to rename this header as origin 2. XDomainRequest API in Internet Explorer 8 does not include the path and the query in its header. Microsoft accepted the authors suggestion to name the header to origin. 3. JSONRequest API s domain header contains the name of the sender. Whereas Origin also contains the senders scheme and port. JSONRequest s specification editor accepted the authors suggestion to adopt origin header. 4

5 4. Cross-Document Messaging API in HTML5 uses the origin header on the client side. The authors employed the origin header in an eight line patch to Webkit and in a 466 line extension to Firefox. Though after the session initialization security can be maintained by the server by verifying the session identifier. But while performing session initialization the below mentioned loopholes can be exploited by an attacker: 1. An attacker can obligate the site to use the attacker s session identifier. After authentication the attacker can access the site as an honest user. 2. An attacker can obligate the site to start the session in the users browser but with the attacker being logged in. One way perform this is to use login CSRF. The below mentioned are methods of performing an attack during session initialization. 1. HTTP Requests: The attacker may force the victim s browser to access a trustworthy site via HTTP and cause the site to start a session. Two case studies for this are shown below: (a) OpenID: OpenID does not have a method to associate a session to the users browser. Hence an attacker may exploit this flaw as follows: i. In one window of its machine, the attacker starts authenticating with a site and in the other window the attacker opens a relying site. ii. Upon authentication, the browser of the attacker then redirects it to return to URL of Relying party. iii. The attacker navigates the users browser to return to URL, instead of navigating himself. iv. Relying Site stores the attacker s cookie in the victim s browser. Thus the user interacts with the relying site as the attacker. In order to protect the user the relying site should store a freshly generated random number in the users browser as well as include it in the return to URL. (b) PHP cookieless authentication is performed by some sites to protect the users privacy by deleting the cookies. The attacker may take advantage of this in the following manner: i. The attacker first authenticates himself with the target site. ii. The attacker navigates the victim s browser to the URL appearing in its own location bar. iii. User is now logged on to the target site as the attacker. To protect the users the site must incorporate some method to associate the session identifier with the authenticator s browser. 2. Cookie Overwriting: An active attacker may send its cookie over HTTP and store it in the users browser. The browser may now send a request over HTTPS to the site, the site can not identify that the cookie has come from the attacker. In order to protect the users the authors propose that the browsers should include the integrity header in its HTTPS request.some of the design decision regarding cookie overwrite which have been proposed by the author are: (a) To conserve bandwidth only the index of the cookie is sent in the HTTP request. (b) By identifying the cookies with their index, the cookies can be uniquely identified by the server. (c) Cookie-Integrity header does not protect when cookies are set for.abc.in. Now if there is dishonest site as a.abc.in, then this site can also access the cookies of.abc.in 4 Methodology used to investigate the paper The methodology used to investigate the paper is a case study based approach. While testing the comparability of the Strict Referrer header the author adopted an empirical approach. 5

6 5 What I learned from the paper From this paper I leaned the ways to protect a site from Cross-site Script Request Forgery. 6 How the paper relates to previous work The paper relates to the follwoing work: 1. RequestRedeo: RequestRedeo protects the users from CRSF by providing defenses from the client site. It removes sensitive information like cookie headers from the HTTP request which are going to the other sites. The drawback of RequestRedeo is that it does not protect from login CSRF. 2. CAPTCHAs: A user can be protected from CSRF by solving CAPTCHAs. The only disadvantage of CAPTCHAs is that, if CAPTCHAs are not random, then an attacker can guess them. 7 Strengths of the paper I like the proposal of the author to send origin header with the POST request as this approach solves both the problems of protecting the privacy the user and protecting the user from CSRF. 8 Weaknesses of the paper I found the following weakness in the paper: The paper mentions that in order to use Origin header, state modifying GET requests must be blocked, but it is evident that if we use this policy in the present scenario then many users requests will be blocked. 9 Results The author proposes the following CSRF defenses for the below mentioned scenarios: 1. To protect from Login CSRF the authors propose that strict referrer validation should be used. 2. For sites which operate on HTTPS, the authors propose strict referrer validation. 3. For sites that embed third party content, secret token validation should be used. 4. For future purposes the author proposes origin header, which gives better protection From the paper it can be inferred that Fool Proof protection from CSRF can not be provided in the existing scenario. 6