Facebook

Last August, security researchers published details about a general attack on HTTPS traffic called “BREACH.” It interacts in interesting ways with the technology that traditionally protects against a different attack called “cross-site request forgery” (CSRF). We would like to share how we're currently defending against BREACH and CSRF so that the community can see how Facebook accounts are protected.

CSRF is a well-known technique used against websites with user accounts. The attacker convinces the victim's browser to send plausible web requests to the target website. The browser is easily fooled because cross-domain requests are commonplace and have many legitimate uses. If the trick works, the attacker can impersonate their victim and send spam or steal information from one of the websites where the victim has an account.

Platforms like Facebook prevent CSRF attacks by issuing the user a secret “CSRF token.” No web request may take an action on behalf of someone unless it also presents that person's token. Since attackers cannot easily discover the CSRF token, they generally aren't able to impersonate the intended victim.

However, the BREACH attack has challenged these traditional countermeasures. Under certain circumstances, attackers could figure out a victim's secret token even when the communication was encrypted. Specifically, the attacker could discover information about the token because of the way that a web page gets compressed.

Compression is a powerful way to speed up communication because repeated sections of text only need to get transmitted once. For example, if the word “Beetlejuice” is repeated three times in a web page, the second and third instances get compressed into tiny shortcuts that refer to the first word. Similarly—and unfortunately—if any letters in the web page match some of the letters in the CSRF token, compression makes the web page smaller. This size difference is still present after the web page is encrypted, and this effect could be used to reveal information about the CSRF token to any attackers that can see the size of the compressed web page. A smart attacker could use a few hundred carefully crafted web requests to figure out the entire token from the size alone.

Facebook protects people against this threat with an extra layer of security inside the CSRF token. Before BREACH was invented, the token was rotated once daily. The CSRF token contained a truncated SHA-2 hash that incorporated the account ID and current date. A person with three Facebook sessions within a single day would have received an identical CSRF token each time, (e.g., AQAOQ2sf, AQAOQ2sf, and AQAOQ2sf). Now our system replaces the token with a new one every time it is requested. Three different sessions use three different CSRF tokens, (e.g., AQGSRmYTeFnr, AQFkqN92V78v, and AQHouyYa35iv). These new tokens are generated by introducing a random 24-bit salt. The salt is the last 4 letters at the end of the token and is also included within the hash, which eliminates all repetition anywhere in the token. After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.

Previously, if attackers could trigger requests for a few hundred web pages with the same repeated CSRF token and see the compressed size, hypothetically that would be sufficient to take over an account. Now, even if attackers coerced the victim's browser into submitting ten thousand requests per second, they would rarely encounter the same token twice. BREACH takes advantage of repetition, so the introduction of randomness foils the attempts.

Even before these protections were released, we don't believe any BREACH attacks have ever been successful against Facebook. BREACH relies on the ability to eavesdrop on the victim's encrypted traffic, convince the victim to visit a malicious website, and find a compressed web page that contains both the CSRF token and user input.

Facebook's defense in depth keeps the CSRF token under wraps even in the most hostile circumstances. Many other proposed solutions, such as adding random padding to payloads, would merely delay an exploit rather than prevent it. Turning off compression would slow Facebook down dramatically, especially for mobile clients. Some websites could get away with watching the referrer and only enabling compression for trusted referrers. Facebook has a significant presence on third-party websites, so this would again hurt browsing speed on a huge number of websites where Facebook components are embedded.

Unfortunately, there is currently no silver bullet that can prevent this attack everywhere. As a result, each website owner—especially those managing user accounts—should evaluate their defense against BREACH and CSRF attacks to make sure they are taking sufficient precautions.

Chad Parry works in London on the Security Infrastructure team. Christophe Van Gysel contributed as an intern to the mitigation of BREACH at Facebook.