What happens when your business model disables critical security protections for your users? Last week, software developer Vijith Assar wrote an editorial on The Verge discussing his research into the Genius web annotation platform and their questionable practices. Genius is a Brooklyn-based startup that allows users to create annotations on any webpage on the internet, effectively adding a comment section anywhere and everywhere. For an example of Genius annotations, check out the About Us page on Genius.com.
Genius proxies web content through their own servers to add annotation-enabling JavaScript. Instead of browsing to website.com, a Genius user instead browses to genius.it/website.com. In the background, Genius’s servers grab the original content from website.com, inject their own JavaScript into the page source, and then forward that content onto the client browser. In the browser, the injected JavaScript rewrites all links on the page to continue directing requests through Genius’s proxy and then provides the functionality to add and view the annotations themselves.
Genius’s modus operandi runs into an issue though, with websites that use Content Security Policy (CSP) to protect their users against Cross-Site Scripting (XSS) attacks. With CSP, a webserver uses an HTTP Header to tell a compliant web browser where content can load from. For example, a web server can use CSP to tell a web browser that it should only retrieve images from cdn.website.com, JavaScript from api.google.com, and Cascading Style Sheets (CSS) from css.othersite.com. Any content that originates from a site not specified in the Content Security Policy header will be denied by the browser. Additionally, the mere presence of the Content Security Policy header tells a browser that it should not allow any inline JavaScript or CSS to load unless explicitly allowed within the header.
To protect against cross-cite scripting attacks, many websites use Content Security Policy to block inline JavaScript by default and instead load their own JavaScript using external sources. This way, if an attacker somehow injects JavaScript into the website, perhaps through the comment section or some other input, web browsers will prevent the malicious script from executing thanks to the Content Security Policy header.
Content Security Policy poses a problem for Genius. In order for their JavaScript to run and rewrite all links in a webpage, the script cannot be loaded externally and must be injected directly into the page’s source. If Genius were to retain the original Content Security Policy for a website, that policy may deny Genius’s JavaScript from executing. To counter this, Genius would strip out the original Content Security Policy header, leaving visitors of proxied websites wide open to cross-site scripting attacks that could have been blocked on the original site.
When Assar originally disclosed the security impact of disabling Content Security Policy, Genius noted that the risk of a cross-site scripting attack was minimal because their annotator does not store any personal information about its users between page loads. Assar went on to explain that while Genius was correct in their statement, users would still be vulnerable to arguably more serious security risks such as drive-by malware downloads and key loggers. Luckily, after Assar provided proof-of-concept examples to Genius, their developers made changes to re-enable the original Content Security Policy for proxied websites, with a few modifications to allow the Genius scripts to run.
Genius now includes extensions from Content Security Policy Level 2, a revised version of the original Content Security Policy specification. Specifically, Genius now uses a cryptographic nonce (a randomly generated, single-use string of letters and numbers), to validate inline JavaScript. Before website content is forwarded from Genius’s proxy servers to the client web browser, the proxy server generates a random string of letters and numbers to use as a validation key. The nonce is included in the new Content Security Policy header and all inline JavaScript. Even if an attacker injects JavaScript into the webpage, the malicious JavaScript won’t include the nonce key and will be denied by the Content Security Policy.
The latest version of Google Chrome fully supports the Content Security Policy Level 2 specification while the latest version of Firefox supports all but one directive, unrelated to this particular security issue. Internet Explorer, Edge and Safari currently support the original Content Security Policy specification but not the Level 2 revision. Luckily, if a user browses to a website through the Genius service with a browser that does not support the CSP Level 2 spec, the default browser behavior is to disallow the content for security purposes. This also means that the Genius JavaScript used to rewrite links to use the Genius proxy will fail to run in certain browsers.
I’m impressed that Genius has taken steps to increase their users’ security at the expense of containing them in their service’s ecosystem. Content Security Policy is an important mechanism for defending against cross-site scripting attacks. I would recommend all users choose web browsers that support the latest specifications and be mindful of services they use that might compromise that protection. — Marc Laliberte