Google advances frameworks and tools against cross-site scripting
Tue 27 Sep 2016
Google has launched online tools to help web developers authenticate – and effectively ‘sign’ – scripts which are allowed to run on their domains, in an effort to improve one of the greatest security attack vectors on the internet.
Cross-site scripting (XSS) gives hackers the opportunity to run code on a domain that was not intended for it, and has been one of the main methods of attack over the last 15 years, facilitating drive-by infections, malware dispersal and complete site take-overs, most often via SQL injection.
If it were not for the necessity to run network advertising and analytics tools on websites in order to maintain their commercial viability, most believe that XSS would never have gained the foothold it has among hackers, because the basic configuration of domain-browsing is set up against it. For instance, by default, cookies cannot be read across domains, but since advertising entities are eager to build up a complete picture of a user’s habits, techniques such as canvas fingerprinting, supercookies and even browser hashing have been developed to take down this ring-fencing.
But Google has now launched evaluative online tools which can determine whether a domain is correctly using Content Security Policy (CSP), which can impede the execution of unauthorised scripts, and notes that a great deal of false comfort has been derived from toothless CSP in recent years:
‘In a recent Internet-wide study we analyzed over 1 billion domains and found that 95% of deployed CSP policies are ineffective as a protection against XSS. One of the underlying reasons is that out of the 15 domains most commonly whitelisted by developers for loading external scripts as many as 14 expose patterns which allow attackers to bypass CSP protections. We believe it’s important to improve this, and help the web ecosystem make full use of the potential of CSP.’
CSP can be effectively deployed with the use of a nonce, or unique hash; generating a nonce for a domain and the scripts which can be allowed to run on it provides a handshake that establishes the trustworthiness of the script being run, without deploying a novel framework that might otherwise break backward-compatibility with existing CSPs.
Google’s CSP Evaluator can determine whether a policy is misconfigured or even set at all, and represents a framework that Google’s own engineers have been using for some time in order to verify the efficacy of CSPs. The company has been using this evaluation method for its own products, including Maps Timeline, Cloud Console, Photos, History and the Google Cultural Institute.
Additionally Google has launched a new Chrome extension called CSP Mitigator, capable of identifying programming patterns that need revision in order to support Content Secure Policy.
But the commercial impetus which has made cross-site scripting such a liability for so long is also likely to undermine such efforts to strengthen its effectiveness, since ad networks would need to invest time and money in ensuring that their daisy-chained scripts, often running across multiple domains with little or no human supervision, co-operate with the scheme.