Twitter Inc. disclosed that it is learning to defend against a new cyber attack technique, Silhouette, that discovers the identity of logged-in twitter users.
This issue was reported to Twitter first in December 2017 through their vulnerability rewards program by a group of researchers from Waseda University and NTT. The researchers submitted a draft of their paper for the IEEE European Symposium on Security and Privacy in April 2018.
Following this, Twitter’s security team prioritized the issue and routed it to several relevant teams and also contacted several other at-risk sites and browser companies to urgently address the problem. The researchers too recognized the significance of the problem and formed a cross-functional squad to address it.
The Silhouette attack
This attack exploits variability during the time taken by web pages to load. This threat is established by exploiting a function called ‘user blocking’ that is widely adopted in (Social Web Services) SWSs. Here the malicious user can also control the visibility of pages from legitimate users.
As a preliminary step, the malicious third party creates personal accounts within the target SWS (referred to below as “signaling accounts”) and uses these accounts to systematically block some users on the same service thereby constructing a combination of non-blocked/blocked users. This pattern can be used as information for uniquely identifying user accounts.
At the time of identification execution, that is, when a user visits a website on which a script for identifying account names has been installed, that user will be forced to communicate with pages of each of those signaling accounts. This communication, however, is protected by the Same-Origin Policy*5, so the third party will not be able to directly obtain the content of a response from such a communication.
The action taken against Silhouette attack
The Waseda University and NTT researchers provided various ideas for mitigating the issue in their research paper. The ideal solution was to use the SameSite attribute for the twitter login cookies.
This would mean that requests to Twitter from other sites would not be considered logged-in requests. If the requests aren’t logged-in requests, identity can’t be detected.
However, this feature was an expired draft specification and it had only been implemented by Chrome. Although Chrome is one of biggest browser clients by usage, Twitter needed to cover other browsers as well. Hence, they decided to look into other options to mitigate this issue.
Twitter decided to reduce the response size differences by loading a page shell and then loading all content with JavaScript using AJAX. Page-to-page navigation for the website already works this way. However, the server processing differences were still significant for the page shell, because the shell still needed to provide header information and those queries made a noticeable impact on response times.
Twitter’s CSRF protection mechanism for POST requests checks if the origin and referer headers of the request are sourced from Twitter. This proved effective in addressing the vulnerability, but it prevented this initial load of the website.
Users might load Twitter from a Google search result or by typing the URL into the browser. To address this case, Twitter created a blank page on their site which did nothing but reload itself. Upon reload, the referer would be set to twitter.com, and so it would load correctly. There is no way for non-Twitter sites to follow that reload. The blank page is super-small, so while a roundtrip load is incurred, it doesn’t impact load times too much.
With this solution, Twitter was able to apply it to various high-level web stacks. There were a bunch of other considerations twitter had to make. Some of them include:
- They supported a legacy version of Twitter (known internally as M2) that operates without the need for JavaScript. They also made sure that the reloading solution didn’t require JavaScript.
- They made use of CSP for security to make sure that their blank reloading page followed Twitter’s own CSP rules, which can vary from service to service.
- Twitter needed to pass through the original HTTP referrer to make sure metrics were still accurately attributing search engine referrals.
- They had to make sure the page wasn’t cached by the browser, or the blank page would reload itself indefinitely. Thus, they used cookies to detect those loops, showing a short friendly message and a manual link if the page appeared to be reloading more than once.
Implementing the SameSite cookie on major browsers
Although Twitter has implemented the mitigation, they have discussed this issue with other major browser vendors regarding the SameSite cookie attribute. All major browsers have now implemented SameSite cookie support. This includes Chrome, Firefox, Edge, Internet Explorer 11, and Safari.
Rather than adding the attribute to Twitter’s existing login cookie, they added two new cookies for SameSite, to reduce the risk of logout should a browser or network issue corrupt the cookie when it encounters the SameSite attribute.
Adding the SameSite attribute to a cookie is not at all time-consuming. One just needs to add “SameSite=lax” to the set-cookie HTTP header. However, Twitter’s servers depend on Finagle, which is a wrapper around Netty, which does not support extensions to the Cookie object.
As per a Twitter post, “When investigating, we were surprised to find a feature request from one of our own developers the year before! But because SameSite was not an approved part of the spec, there was no commitment from the Netty team to implement. Ultimately we managed to add an override into our implementation of Finagle to support the new cookie attribute.”
Read more about this in detail on Twitter’s blog post.
Read Next
Building a Twitter news bot using Twitter API [Tutorial]
Facebook, Twitter open up at Senate Intelligence hearing, the committee does ‘homework’ this time
