CSRF vulnerability description
In general, three methods are widely used to defend against CSRF attacks: verifying tokens, verifying HTTP requests with Referer, and verifying custom headers in XMLHttpRequests. None of these approaches is perfect for a variety of reasons, and each has its pros and cons.
CSRF classification
In a cross-site request forgery (CSRF) attack, an attacker compromises the integrity of a website session by injecting additional web requests through a user’s browser. The browser’s security policy is to allow the current page to send requests to any address, which means that an attacker can control the content of the page to control the browser to send its carefully constructed requests while the user is browsing resources he or she has no control over.
1. Network connection. For example, if an attacker cannot directly access resources inside the firewall, he can use the browser of the user inside the firewall to indirectly send network requests to the resources he wants to access. There is even a case where an attacker uses a victim’s IP address to initiate a request in order to circumvent IP address-based authentication.
2. Know the browser status. When a browser sends a request, the network protocol usually contains the state of the browser. This includes many things, such as cookies, client-side certificates, or authentication-based headers. Therefore, when an attacker sends a browser request to a site that requires these cookies, certificates, and headers for authentication, the site cannot distinguish between the real user and the attacker.
3. Change the browser state. When an attacker makes a request with the browser, the browser also analyzes and responds to the server’s response. For example, if the server’s response contains a set-cookie header, the browser responds to the set-cookie and modifies the Cookie stored locally. These changes can lead to subtle attacks, which we will describe in Part 3.
Scope of action threat: We have divided this section into three different hazard models according to the magnitude of the harm generated.
1. Interactive place of the forum. Many sites, such as forums, allow users to customize a limited variety of content. For example, websites often allow users to submit passive content such as images or links. If the attacker directs the image URL to a malicious address, the network request is likely to result in a CSRF attack. Any of these places can make requests, but they cannot customize HTTP headers, and they must use the GET method. Although the HTTP protocol specification requires that requests be made without harm, many web sites do not meet this requirement.
2. Web attackers. In this context, a Web attacker is defined as a malicious proxy that has its own independent domain name, such as attacker.com, and owns attacker.com’s HTTPS certificate and Web server. All of this can be done for $10. Once a user accesses attacker.com, an attacker can initiate cross-site requests using both GET and POST methods, known as CSRF attacks.
3. Cyber attackers. A cyber attacker is a malicious agent that can control a user’s Internet connection. For example, an attacker could control a user’s network connection by taking control of a wireless router or DNS server. This type of attack requires more resources and preparation than a Web attack, but we consider it a threat to HTTPS sites as well. Because HTTPS sites can only protect active networks.
Out-of-scope threats: Below we also list some related hazard models that are beyond the scope of this paper. Defenses against these hazards can complement those of CSRF.
Cross-site scripting (XSS). If an attacker is able to inject scripts into the site, the attacker can compromise the integrity and confidentiality of the user sessions on that site. Some XSS attacks require making network requests, such as transferring money from a user’s bank account to an attacker’s account, but CSRF defenses generally do not take these cases into account. To be more secure, sites must implement both XSS and CSRF defenses.
2. Malware. If an attacker is able to run the malware on a user’s computer, the attacker can control the user’s browser to inject scripts into those trusted websites. Browser-based defense strategies are ineffective because an attacker can replace a user’s browser with a browser that contains a malicious plug-in.
3. DNS rebinding. Like CSRF, DNS rebinding can use the user’s IP address to connect to the attacker’s specified server. Servers that are protected by a firewall or those that are authenticated based on IP addresses need a defense against DNS rebinding. Although the intent of the DNS rebinding attack is very similar to that of the CSRF attack, they require different solutions. A simple solution to DNS rebinding attacks is to validate the host’s HTTP request headers to make sure they contain the expected values. Another alternative is to filter DNS traffic to prevent external DNS names from being resolved to internal private addresses.
4. The certificate is incorrect. Much of the security that HTTPS can provide is meaningless if a user is willing to click through even if an HTTPS certificate error occurs. Some security researchers have pointed out the dangers of this situation, but in this article, we assume that users will not click on access after an HTTPS certificate error occurs.
5. Fishing. Phishing attacks occur when users enter personal information during authentication while visiting phishing sites. Phishing attacks are very common and effective these days because users can sometimes have a hard time telling the difference between a phishing site and the real thing.
6. User tracking. Some partner sites use cross-site requests to build a library of associated behavior about a user’s browsing habits. Most browsers prevent similar tracing by organizing third-party cookie sending, but this feature of browsers can be circumvented with hang requests.
Three login CSRF
Most discussions of CSRF focus on requests that can change the state of the server, whether it is using the browser’s network connection or state. Although CSRF attacks can compromise users’ access to trusted websites by altering the state of the browser, they have not received much attention. In the CSRF attack, the attacker uses a user’s username and password from a trusted site to make a fake request to the site. Once the request is successful, the server will respond to a set-cookie header, and the browser will establish a session Cookie after receiving it, and record the login status of the user. This session cookie is used to bind subsequent requests and thus can also be used by an attacker for authentication. Depending on the site, CSRF attacks can also cause serious consequences.
Search history: Many search engines, including Google and Yahoo, allow their users to opt out of keeping their search history and provide users with an interface to view their own private search history. Search requests contain sensitive details about users’ habits and interests, which attackers can use to trick users, steal their identities or spy on them. When an attacker logs into the engine as a user, the user’s search history can be seen. In this way, the user’s search query record is stored in the attacker’s search record, and the attacker can log in his own account to query the user’s search record at will.
Figure 1. Tracing diagram of login CSRF attack events. The victim visits the attacker’s website, and the attacker makes a fake login box for a cross-site request to Google, causing the victim to be logged into Google by the attacker. Later, when the victim uses the search, the search history is recorded by the attacker.
PayPal: PayPal allows its users to transfer money to and from each other. To transfer funds, users sign up for a credit card or bank account. Attackers can use login CSRF to launch the following attacks:
1. The victim visited the malicious merchant’s website and chose to pay with PayPal.
2. The victim is redirected to PayPal and asked to log in to his/her account.
3. The site waits for the user to log in to his/her PayPal account.
4. When making the payment, the victim first registered his credit card, but the credit card had actually been added to the PayPal account of the malicious merchant.
IGoogle: Users can customize their Google home page using iGoogle, including some plugins. For ease of use, these plug-ins are “embedded into iGoogle,” which means they affect iGoogle security. Typically, iGoogle asks users to make a trust decision when adding a new plug-in. But attackers can help users make decisions by logging in to CSRF attacks to install arbitrary plug-ins.
1. The attacker installs an iGoogle plug-in (containing malicious scripts) through the user’s browser authorization and adds the plug-in to the user’s customized iGoogle home page.
2. The attacker logged the user into Google and opened a framework to iGoogle.
3. Google believes that the victim is the attacker, and pushes the attacker’s plug-in to the victim, and allows the attacker to run the script in the https://www.google.com field.
4. An attacker can now :(a) construct a login box on the correct URL page, (b) steal the user’s auto-filled password, and (c) wait in another window for the user to log in and read document.cookie.
We have informed Google of the vulnerability, and they have worked to mitigate the damage in two ways. For one thing, Google has abandoned embedded plugins and banned developers from creating similar ones, allowing only a small number of popular embedded plugins. Second, Google has developed a private token policy to defend against login CSRF(discussed below), but this policy only works for users who are logged in. We expect Google to deny their login CSRF vulnerability once they have fully tested their defenses and feel they work.
Existing CSRF defense schemes
Generally, websites have three ways to defend against CSRF attacks. (1) Verify the token value. (2) Verify the HTTP header Referer. Append to the header with XMLHttpRequest. All three methods are widely used, but their results are not satisfactory.
4.2 Token authentication
Attaching a piece of information to each HTTP request is a good way to defend against CSRF attacks because it can determine whether the request is authorized or not. This “authentication token” should not be easily guessed by unlogged users. If the request does not contain the authentication token or the token does not match, the server should reject the request.
Token authentication can be used to defend against login CSRF, but developers tend to forget authentication because without login, CSRF tokens cannot be bound through session. If a website wants to use token authentication to defend against login CSRF attacks, it must first create a “pre-session” so that the CSRF defense scheme can be deployed. After the authentication is passed, a real session can be created.
Token design. There are many techniques for generating validation tokens.
• Session identifier. Browsers store cookies in a way that prevents different domains from accessing cookies from each other. A common approach is to use the user’s session identifier directly as the authentication token. The server matches the user’s token with the session identifier on each request. If an attacker can guess the user’s token, he can log into the user’s account. The downside of this is that occasionally what the user is viewing can be sent to a third party, such as via email directly to the browser vendor’s bug-tracking database. If the page happens to contain the user’s session identifier, anyone with access to the page can impersonate the user’s login to the site until the session expires.
• Independent session random number. Instead of using the user’s session identifier directly, the server generates a random number and stores it in the user’s cookie when the user logs in for the first time. For each request, the server matches the token with the value stored in the cookie. For example, the widely used Trac problem tracking system uses this technique. However, this method cannot defend against active network attacks, even if the entire Web application uses HTTPS. Because an attacker can override this independent session random number with his own CSRF token, he can use a matching token to fake a cross-site request.
• Depends on session random number. An improved way to generate random numbers is to store the user’s session identifier on the server after mapping it to the CSRF token. When processing a request, the server verifies that the token in the request matches the session identifier. The downside of this approach is that the server must maintain a large mapping table (hash table).
• HMAC of session identifier. There is a method that does not require the server to maintain the hash table. It is possible to encrypt the user’s session token and use it as a CSRF token. For example, Ruby on Rails web applications typically use this approach, and they use the HMAC of the session identifier as a CSRF token. As long as all web servers share the HMAC key, each server can verify that the CSRF token in the request matches the session identifier. HMAC features ensure that even if an attacker knows the user’s CSRF token, it cannot infer the user’s session identifier.
Given the abundance of resources available, web sites can use the HMAC approach to defend against CSRF attacks. However, many sites and some CSRF defense frameworks (such as NoForge, CSRFx, and CSRFGuard) do not properly implement crypto token defense. A common mistake is exposing the CSRF token when handling cross-site requests. For example, if a trusted site adds a CSRF token to a request to another site, that site can fake a cross-site request to that trusted site.
Case study: NoForge.NoForge authenticates a user’s CSRF token by saving a hash table on the server. It appends a CSRF token to all links and form submissions, which is not perfect for three reasons:
HTML is created dynamically in the browser without the CSRF token being added. Some web sites create HTML on the client side. Gmail, Flickr, and Digg, for example, use JavaScript to create forms that require CSRF defense.
2. NoForge does not distinguish between hyperlinks to this site and external sites. If there is a hyperlink to the outbound site, then the outbound site can use the request to obtain the user’s CSRF token. For example, if phpBB has NoForge deployed, once a user clicks on a connection, the connected site can obtain the user’s CSRF token, even if NoForge makes a distinction between local and external links, because Referer still exposes the user’s CSRF token.
3. NoForge has no effect on logging in to CSRF because it only validates the CSRF token if the user already has a session identifier. Although this defect can be fixed, it also shows that it is not easy to implement the token authentication strategy correctly.
While all three of these causes can be fixed, these flaws illustrate the complexity of properly implementing token authentication policies. CSRFx and CSRFGuard, as well as a number of websites, illustrate this.
4.2 Referer
In most cases, when a browser makes an HTTP request, the Referer identifies where the request came from. If the HTTP header contains the Referer, we can distinguish whether the request is local or cross-site, because the Referer indicates the URL from which the request was originated. Sites can also defend against CSRF attacks by determining whether the request in question originated in the same domain.
Unfortunately, referers often contain sensitive information that may violate users’ privacy. Referer, for example, can display searches and queries for a private site. Although the content is good for owners of private sites because they can use it to optimize search engine rankings, some users feel it violates their privacy. In addition, many organizations are concerned that Referer may leak confidential information on their networks.
Holes. Historically, browser bugs have made it worthwhile for malicious sites to spoof Referer, especially when using proxy servers. Many discussions of Referer spoofing indicate that browsers allow Referer to be forged. Mozilla has fixed the Referer spoofing bug in Fire-Fox 1.0.7. Current IE still has this vulnerability, but it only affects XMLHttpRequest and can only be used to fake referers to the attacker’s own site.
Scale. If a site chooses to use Referer to defend against CSRF attacks, the developer of the site needs to decide whether to use a looser or stricter Referer authentication policy. If a loose Referer validation policy is used, sites should block requests with incorrect Referer values. If there is no Referer in the request, the request is accepted. Although this method is commonly used, it can easily be bypassed. Because an attacker can remove the Referer from the header. For example, REQUESTS made by FTP and data urls do not contain Referer. If a strict Referer validation policy is used, the site also blocks requests without Referer. This is mainly to prevent malicious sites from actively hiding Referer, but it can also cause compatibility problems, such as killing legitimate requests because some browsers and networks don’t have Referer by default. So this degree must be mastered, a lot of times depends on experience. We’ll discuss this again in 4.2.1.
Case study: Facebook. Throughout Facebook, most websites use token authentication to defend against CSRF attacks. However, Facebook uses a looser Referer validation policy in its login box. This approach is of little use in the face of an attack on CSRF. For example, an attacker can tell users redirected from http://attacker.com/ to ftp://attacker.com/index.html, and then to landing Facebook launched a cross-site request. Because the request comes from an FTP URL, most browsers don’t include the Referer in the request.
Experiment 2
To assess the compatibility of a strict Referer validation strategy, we conducted an experiment to measure the probability and circumstances in which a legitimate request does not contain Referer.
Design. Advertising is an easy way to measure browser and web characteristics, so we can use advertising as a platform for experimentation. Between April 5 and April 8, 2008, we purchased 283,945 ads from 163,767 individual IPS across two different advertising channels. In Channel A, we bought banner ads for “Firefox”, “game”, “IE”, “Video”, “YouTube” at A price of $0.50 per thousand displays. In channel B, we ran interlude ads for $5 per thousand displays with keywords “ballet”, “finance”, “flowers”, “food” and “gardening”. We spent $100 per AD channel and channel A had 241,483 clicks (146,310 unique ips) and channel B had 42,406 clicks (18,314 unique ips).
The advertising service is provided by two hosts in our lab, two separate domain names purchased from different registrars. Each time an AD is displayed, the AD generates a specific identifier for each subsequent request and randomly selects a host as the primary server. The master server sends the client HTML to our server via HTTP or HTTPS, which can make a GET or POST request. Requests include submit forms, image requests, and XMLHttpRequests. The order of requests is random and independent of the user’s actions. When the AD passes the browser’s security policy, a local request is made to the primary server and a cross-domain request is made to the secondary server. The cost per server is $400, the domain name is $7, and a 90-day authenticated HTTPS certificate from a legitimate certificate authority is free. The server records the request parameters according to the received network request, including the Referer, user-agent header, date, class C network of the client, and session identifier. The server also logs the document.referrer value through the DOM API, but not the CLIENT IP address. To count individual IP addresses, the server uses a randomly generated KEY instead of logging the HMAC, which is discarded. The information recorded by the server is not enough to independently determine how many viewers an AD has.
Ethics. The experiment was designed to follow the rules of both advertising channels. The behavior in the experiment was basically everyday behavior of Web ads, so it was normal to request additional resources from advertisers, such as images, audio and video. Although our AD generated a much larger number of HTTP requests than a normal AD, we required significantly less bandwidth than a video AD. Our servers, like advertisers, only record what they record. In fact, our servers record significantly less information than commercial advertisers, because we don’t record client IP addresses.
The results. We have summarized the results in Figures 2 and 3, and we also found that the following results are only 95% reliable.
• In HTTP, cross-domain requests without Referer headers are more common than in-domain requests, while in POST (Chi-square coefficient = 2130, P <0.001) and GET (Chi-square coefficient = 2175, P <0.001), The former without the Referer header is more common.
• HTTP is more common than HTTPS in statistics excluding the Referer header, including cross-domain POST(Chi-square coefficient = 6754, P <0.001) requests, cross-domain GET(Chi-square coefficient = 6940, P <0.001) requests, Local POST(Chi-square coefficient = 2286, P <0.001) requests and local GET (Chi-square coefficient = 2377, P <0.001) requests.
• In statistics excluding the Referer header, all forms of requests from AD channel B are more common than requests from CHANNEL A. These requests include: HTTP cross-domain POST(Chi-square coefficient = 3060, P <0.001), HTTP in-domain POST(Chi-square coefficient = 6537, P <0.001), HTTPS cross-domain POST(Chi-square coefficient = 49.13, P <0.001) and HTTPS co-domain POST(Chi-square coefficient = 44.52, P <0.001) requests.
• We also counted custom header x-requested-by (see Section 4.3) and Origin (see Chapter 5), x-requested-by is about 0.029% to 0.047% of HTTP POST requests, Referer headers are not included in 0.084% to 0.112% HTTP GET requests, 0.008% to 0.018% HTTPS POST requests, and 0.009% to 0.020% HTTPS GET requests. Origin does not include the Referer header in the same request.
Figure 2. Requests with no Referer and incorrect Referer (283,945 results). X and y indicate the domain names of the primary and secondary servers respectively
The discussion. There are two strong points to suggest that requests that do not contain Referer often come from the web rather than the browser.
HTTP requests that do not include Referer are more common than HTTPS requests because a web proxy can delete the header in an HTTP request, but not in an HTTPS request. Of course, in some enterprise networks, some HTTPS terminals are network proxies, in which case the proxy can modify HTTPS requests, but this is rare.
2. When the browser removes the Referer, it also removes the document.referrer value, but if the Referer is removed from the network, the document.referrer is still there. However, we find that Referer removal is more common than document.referrer removal.
In fact, in the experiment, the document.referrer value was removed mainly because of two special browsers: The PlayStation 3 browser does not support document.referrer, and Opera removed the document.referrer (but did not remove the Referer) for cross-site HTTPS requests. The high percentage of referers removed from XMLHttpRequest is due to bugs in Firefox 1.0 and 1.5. All of these results suggest that very few browsers are configured not to send Referer.
There is also evidence that the Referer was removed because of privacy issues. When the browser sends the Referer from Site A to site B, users’ privacy is also exposed, because site B can collect users’ browsing behavior on site A through the Referer. In contrast, sending Referer in a co-domain does not raise privacy issues, since it is entirely possible for a site to collect users’ privacy through cookies (i.e., there is no need to collect through Referer at all). We also found that cross-site requests were more likely to block referers than same-site requests, indicating that the Referer was artificially blocked due to privacy concerns.
From this, we draw two main conclusions:
1. Use HTTPS to defend against CSRF. Referer can be used to defend against CSRF in HTTPS requests. In order to implement a policy of using referers to defend against CSRF, sites must reject requests without referers because an attacker can control the browser to remove referers. In HTTP, sites cannot simply reject requests without Referer, because a significant portion of users (around 3-11%) may not be able to access the site for compatibility reasons. The difference is that in HTTPS, a strict Referer validation policy can be enforced because only a small percentage (0.05-0.22%) of browsers remove the Referer. In particular, a strict Referer authentication policy is a good defense against login CSRF, since login requests are typically initiated over HTTPS.
2. Privacy. A strict Referer policy is a good defense against CSRF because it is easy to implement. Unfortunately, privacy policies may prevent this from becoming popular. Therefore, both the browser’s new security features and the new CSRF defense mechanism must be addressed before they can be deployed on a large scale.
Figure 3. Advertising channel A contains no referers and incorrect Referer requests (241,483 results). Opera prevents cross-site HTTPS document.referrer. Firefox 1.0 and 1.5 do not send referers to XMLHttpRequest due to a bug. The PlayStation 3 does not support document.referrer.
4.3 Customizing HTTP Headers
We can also defend against CSRF attacks by using custom HTTP headers, because browsers prevent sending custom HTTP headers to outbound sites, but allow sending custom HTTP headers to this site using XMLHttpRequest. For example, the prototype.js JavaScript library uses this approach and adds the X-requested-by header to XMLHttpRequest. Google Web Toolkit also recommends that developers protect against CSRF attacks by adding an X-XSRF-cookie header to XMLHttpRequest. XMLHttpRequest contains Cookie values. Of course, cookies in XMLHttpRequets do not need to be used to defend against CSRF, because only the header part is sufficient.
To use this approach to defend against CSRF attacks, websites must use XMLHttpRequest on all requests with a custom header (such as X-requested-by) attached, and reject all requests that do not have a custom header. For example, to defend against CSRF login attacks, a web site must send user authentication information to the server using XMLHttpRequest. In our experiment, about 99.90-99.99% of the requests received By the server contain x-requested-by headers, indicating that this method is suitable for the vast majority of users.
Five suggestion: The Origin field
In order to prevent CSRF attacks, we recommend modifying the browser to add an Origin field when sending POST requests. The Origin field is mainly used to identify the Origin of the original request. If the browser cannot determine where the source is, the Origin field is null in the sent request.
Privacy: This Origin method is more human than Referer because it respects the privacy of users.
1. The Origin field contains only who made the request and no other information (usually the scheme, host, and port of the active document URL). In particular, unlike Referer, the Origin field does not contain URL paths or requests that could be considered private.
The Origin field only exists for POST requests, while the Referer field exists for all types of requests.
Clicking on a random hyperlink (such as from a search list or a corporate Intranet) does not send the Origin field, which prevents sensitive information from leaking out.
In terms of dealing with privacy concerns, the Origin field’s approach may be more palatable to users.
Server to do: Using the Origin field method to defend against CSRF attacks, websites need to do the following:
The POST method must be used for all status change requests, including login requests. Certain status-changing GET requests must be rejected to counter the type of harm posted on forums mentioned above.
The server should reject all requests that have the Origin field but the value is not what we want (including null value). For example, the server can reject any request that the Origin field is an outstation.
Security analysis: Although the Design of the Origin field is very simple, it works well to defend against CSRF attacks.
1. Remove the Origin field. Since browsers that support this approach carry the source header with each POST request, websites can determine if the request was initiated by a browser that supports this approach by looking for the presence of the Origin field. This prevents an attacker from changing a browser that supports this method to one that does not, because even if you change the browser to remove the Origin field, the Origin field still exists, but with its value empty. This is very different from Referer, because as long as Referer is removed from the request, the server cannot detect it.
2. DNS is bound again. In existing browsers, the Origin field can be faked for co-existing XMLHttpRequests. Sites that rely solely on network connections for authentication should use the DNS rebinding methods mentioned in Chapter 2, such as validating the Host field in the header. DNS rebinding is also required when using the Origin field to defend against CSRF attacks. They complement each other. Of course, for the CSRF defense method mentioned in Chapter 4, DNS rebinding method is also needed.
3. Plug-ins. If a website is prepared to accept a cross-site HTTP request based on crossdomain.xml, an attacker can use Flash Player to set the Origin field in the request. Token authentication does not handle well when handling cross-site requests because tokens are exposed. To counter these attacks, websites should not accept cross-site requests from untrusted sources.
4. Application. The Origin field is very similar to the following four suggestions for determining the source of a request. The following four recommendations are consolidated and improved upon, and several organizations have adopted the Origin method recommendations.
• Cross-site XMLHttp Request. The cross-site XMLHttp Request method specifies an Access-Control-Origin field that is used to determine the source of the Request. This field exists in all HTTP methods, but it is only included in XMLHttpRequests requests. Our idea for the Origin field came from this suggestion, and the Cross-site XMLHttp Request working group has accepted our suggestion to name the field Origin.
• XDomainRequest. There is an XDomainRequest API in Internet Explorer 8 Beta 1 that removes the path and request content in the Referer when sending an HTTP request. The reduced Referer field identifies the source of the request. Our results show that Referer, which is truncated, is often rejected, while our Origin field is not. Microsoft has announced that they will adopt our suggestion to change the Referer in XDomainRequest to Origin.
• JSONRequest. In the JSONRequest design, there is a Domain field that identifies the host name that initiates the request. In contrast, our Origin field method contains not only the host, but also the requested scheme and port. The designers of the JSONRequest specification have accepted our suggestion to change the Domain field to the Origin field to prevent network attacks.
• Cross – Document Messaging. One suggestion in the HTML5 specification is to create a new browser API that validates clients linking between HTML files. This design contains an Origin property that cannot be overridden. If not on the client side, the process of validating the Origin property on the server is the same as that of validating the Origin field.
Implementation: We have implemented the method of using origin field to prevent CSRF attack on both the server and the browser. The way we implement the Origin field on the browser side is by adding an 8-line patch to WebKit, our open source component in Safari, and a 466 line plug-in in Firefox. The way we implement the Origin field on the server side is by adding an application firewall language in Apache with just 3 lines of code in ModSecurity application firewall (see Figure 4). These rules can verify the Host field and origin field with a valid value in a POST request. No site changes are required to implement these rules to defend against CSRF attacks, and they ensure that GET requests are non-offensive (provided the origin field method is implemented on the browser side).
Figure 4. Implementing the Origin field method in ModSecurity to defend against CSRF attacks
Six Session initialization
Logging in to CSRF is just one of the most common vulnerabilities during session initialization. After a session is initialized, the Web server typically binds the user’s identity to the session identifier. Therefore, there are two types of session initialization vulnerabilities: one is when the server binds the identity of the trusted user to the newly initialized session, and the other is when the server binds the identity of the attacker to the session.
• Authentication as a trusted user. Under certain circumstances, an attacker can force a website to open a new session using a predictable session identifier. This type of vulnerability is commonly referred to as session location vulnerability. When users provide their identity information to a trusted site for verification, the site binds the user’s identity to a predictable session identifier. The attacker can then use this session identifier to log in as the user.
• Verification as an attacker. An attacker can also force the site to start a new session through the user’s browser, and force the session to be bound to the attacker’s identity (chapter 3 explains how this is done). The login CSRF attack is only the simplest vulnerability of this type, but there are other ways an attacker can force sessions to be bound to itself via the user’s browser.
6.1 the HTTP request
OpenID: A lot of websites like LiveJournal, Movable Type and WordPress use the OpenID protocol. It is recommended that these websites use self-signed random numbers to defend against reply attacks, but don’t tie OpenID session to the user’s browser. Because an attacker can force a user’s browser to initialize a session and then bind the session to itself. The specification states that the REturn_to URL may be used by the proxy to establish a connection between the user’s authentication request and the authentication reply. But LiveJournal, Movable Type and WordPress don’t think this is necessary and don’t implement it. To counter this attack, the client should generate a new random number during protocol initialization and store it along with the browser cookie, including it in the return_to parameter. The client will match the random number in the cookie with the random number in the return_to parameter. This approach is similar to token authentication and ensures that the OpenID protocol session can be completed in the same browser from the beginning.
PHP cookieless authentication: This method is used by sites like Hushmail to prevent users from keeping cookies on their computers. The Cookieless authentication method stores the user’s session identifier in the request parameters. However, this method cannot bind a session to the user’s browser, so an attacker can force the user’s browser to initialize a session to bind to the attacker. To prevent this attack, a web site must use another way to bind the session identifier to the user’s browser. For example, a web site can construct a long-running frame that contains the Session identifier. This approach binds the user’s browser to the session by storing the session identifier in memory. Sites using PHP Cookieless authentication also typically have session initialization vulnerabilities, which allow an attacker to impersonate a trusted user. Of course, there are many standard defenses against such session location vulnerabilities. For example, when a user logs in, the site can generate a session identifier again.
6.2 the Cookie to rewrite
Holes. The server can use a Secure flag in the set-cookie field to tell the browser that the Cookie can only be sent over HTTPS. This feature is supported by all browsers and is often used to protect sessions on security-sensitive sites. However, this Secure Flag does not guarantee integrity. An attacker can imitate a website to send a set-cookie field to the same host over HTTP and Set up a Cookie on the host. When a browser sends a cookie to a site over HTTPS, the site has no mechanism to determine if the cookie has been overwritten by an attacker. If the cookie contains the user’s session identifier, an attacker can easily override the user’s cookie to launch a session initialization attack. Almost no web site can defend against this attack because they require a cookie from the client for integrity verification. However, it has been suggested to use a browser feature, such as localStorage, which can make up for this deficiency. In other words, if a site claims that its application-layer session authentication is completely independent of the cookie-based HTTP layer session authentication, an attacker can rewrite the user’s cookie before authentication and then log in as the user. Although security officials have known for years that attackers can override cookies, browser manufacturers have few good ways to combat them. Vendors consider rejecting HTTP requests as a way to counter cookie rewriting attacks, but this is obviously not reasonable. Worse, this approach does not provide cookie integrity because the cookie field itself does not differentiate between cookies containing Secure Flags.
Defense methods. In order to protect the Integrity of the cookie without changing the existing cookie field, we recommend that browsers add a new cookie-integrity field to HTTPS requests specifically to check the Integrity of the cookie. This is also considered compatible with previous strategies. For example,
Cookie: SID = DQAAAHQA… ; Pref = ac81a9… ; TM = 1203…
Cookie-Integrity: 0, 2
The cookie-integrity field can be used in requests to describe the index of the cookie field when cookies are set to be sent using HTTPS. If none of the cookies in the request are set to HTTPS, the cookie-integrity field is null. Protecting the Integrity of cookie-integrity fields goes hand in hand with the confidentiality that Secure Flag can provide, and it is also compatible because the server will ignore requests with unrecognized headers. Here are a few design suggestions:
Bandwidth. Adding content to each HTTP request inevitably increases latency for all networks, so to save bandwidth, we only add the index value of cookie in the cookie field. Another suggestion is to add a copy of the cookie-like field called Cookie2.
Diversity. When a host intends to create a cookie with the same name as an existing cookie, the cookie can contain two cookies with the same name. Because in this case, the cookie-integrity field may not be able to distinguish cookies by their names, but we can distinguish them by their index values within the Cookie field.
The Rollback. Adding cookie-integrity to HTTPS requests can effectively prevent rollback attacks. If there is no cookie-integrity field and Cookie Integrity cannot be guaranteed, the server cannot determine whether the Cookie in the request is complete (assuming the request is from a lower version host that does not support the cookie-integrity field).
Compatriots domain. Consider a situation where example.com contains a trusted and an untrusted subdomain, www.example.com and users.example.com, respectively. When cookies are set for example.com, untrusted subdomains can inject the cookie fields of trusted subdomains. Cookie-integrity fields do not protect against such attacks, but you can add a field to identify the source of each Cookie (depending on bandwidth and complexity considerations, of course).
In Firefox, we added a cookie-integrity field with 202 lines of JavaScript code and added an Integrity flag to the Cookie, which is mainly used to record whether the Cookie is set to use HTTPS for transmission.
Summary and suggestions
CSRF is a very widely exploited vulnerability today. Many sites have fixed their CSRF vulnerabilities, including the login CSRF vulnerability. Based on the experiments and analysis mentioned in this article, we recommend that websites use different CSRF defense strategies in different situations.
• Log in to CSRF. We recommend using a strict Referer authentication policy to defend against login CSRF, since login forms are usually sent over HTTPS and referers are reliable in legitimate requests. If a login request is made without the Referer field, the site should reject it outright to prevent malicious modification.
• HTTPS. For sites that use HTTPS exclusively, such as banks, we also recommend using a strict Referer authentication policy to defend against CSRF attacks. For those requests that have specific cross-site requirements, the site should create a whitelist, such as the home page, etc.
• Third party content. If the site incorporates third party content such as image links and hyperlinks, the site should use a proper token verification framework such as Ruby-on-Rails. If such a framework does not work, the site should take the time to design a better token authentication strategy, which can be used to bind users’ sessions to tokens using the HMAC method.
For further suggestions, we would like to use the Origin field instead of the Referer, as this preserves the existing effect and respects the user’s privacy. Ultimately, the use of tokens to defend against CSRF should be abolished, because then websites can better protect HTTP and HTTPS requests without worrying about whether tokens are compromised.
Future work. If you use the Origin field method to defend against CSRF attacks, sites should be careful not to have any side effects when processing GET requests. Despite this requirement in the HTTP specification, many sites do not comply with this requirement. Getting websites to implement this requirement is what we will focus on in the future.
A variant of CSRF attacks has emerged, in which an attacker embeds a frame on a trusted website and entices users to click (clickjacking). Although this is not a CSRF attack by our definition, they are very similar in that the attacker uses a user’s browser to make a request to a trusted site. The traditional way to defend against this attack is frame busting, but the problem with this method is that it relies on JavaScript, which can be disabled by the user or the attacker. One suggestion here is to add something in the Origin field that describes the source of the frame, i.e. the hyperlinks within the frame, so that trusted websites can decide whether to reject or accept the request based on the source of the frame.
Reference:
http://seclab.stanford.edu/websec/
By the network security attack and defense research office (www.91ri.org) information security team collection and collation, reproduced please note source!