Among the popular online threats, cross-site scripting is one of the classic Web application security vulnerabilities, which is majorly used to gain unauthorised access. Cross-site scripting – also known as “XSS” – allows attackers to compromise the interactions of a user with a target vulnerable application.
Though it is one of the common threats, it can allow cyber criminals to wreak havoc on their victims. Under Google's Vulnerability Reward Programs (VRP), a security researcher named Shachar found an XSS bug in Google Maps, which reportedly landed him a total reward of US$10 000. Using the bug, an attacker could have gained access to a user’s interactions with Google Maps – one’s travel history and searches if not the access to one’s Google account. Thankfully, many companies are working to minimise online threats, and Google and Mozilla are the prime organisations aiming for a more secure Web experience for all.
What is cross-site scripting (XSS)?
In a cross-site scripting attack, an attacker usually masks himself as a victim user to access the user’s data or carry out unauthorised actions on the user’s behalf. For example, if the victim user has admin privileges within an application, the attacker might gain complete control over the application, including its data. Or, if the target application is a banking or financial application and the victim user has some funds, the attacker might transfer funds to his account. That is, a cross-site scripting attack allows attackers to perform as much damage as the functionality of the target application and the privileges of the victim user.
In a nutshell, a cross-site scripting attack is mostly executed by manipulating a vulnerable Web site into returning malicious or malformed code to the victim user. When this malicious code runs inside the victim’s Web browser, the attacker gets full control of the victim user’s interactions with the target application. This malicious code can come from multiple sources, thus there are three types of cross-site scripting attacks. The first type is called Reflected XSS, wherein the code comes from the current request. The second type is called Stored XSS, wherein the code comes from the Web site’s database. The third and last type is called DOM-based XSS, wherein the attacker compromises the client-side code of the application. These types of cross-site scripting attacks only differ in their execution, but they all perform the same level of damage.
How Google and Mozilla are helping
Google and Mozilla are the creators of Blink and Gecko respectively – the Web browser engines responsible for driving your experience on Google Chrome and Mozilla Firefox. That is not all, they power a lot more browsers and applications. For instance, Blink is the underlying engine in all Chromium-based browsers like the new Microsoft Edge, Brave, Opera and Vivaldi. Similarly, Gecko lives under the hood of Tor Browser, SeaMonkey and Waterfox, along with Thunderbird – the popular e-mail client. That means Blink and Gecko are responsible for more than half of the Web browsers on the planet. And that makes Google and Mozilla driving forces for developing better feature sets to combat online threats.
That said, Google and Mozilla are working towards a “post-XSS world” by introducing a number of security features in their browsers. According to a blog post on Google Online Security Blog: “Over the past two years, browser makers and security engineers from Google and other companies have collaborated on the design and implementation of several major security features to defend against common web flaws. These mechanisms, which we focus on in this post, protect against injections and offer isolation capabilities, addressing two major, long-standing sources of insecurity on the web.”
The new security mechanisms include Content Security Policy based on script nonces, Cross-Origin Opener Policy, Fetch Metadata Request Headers, Trusted Types, and some more. These improvements are the hard work of many people over the course of several years, which are being implemented in Google Chrome 83 and Mozilla Firefox 79.
For instance, nonce-based Content Security Policy works by setting a random token for every page load. So, if some part of the Web page is injected by an attacker, the browser will refuse to execute the injected script since it will not present the correct nonce token. This will mitigate any server-side injection like Reflected XSS and Stored XSS. According to Google, nonce-based Content Security Policy helps mitigate exploitation of 30+ high-risk XSS vulnerabilities. And, fortunately, nonce-based Content Security Policy is supported in Google Chrome, Mozilla Firefox and all browsers based on these two browsers. Safari has partial support for nonce-based Content Security Policy, unfortunately.
When nonce-based Content Security Policy is combined with Trusted Types, they prove as battle-tested mitigation against a majority of DOM-based XSS. However, Google Chrome supports both at the time of publication while Mozilla is working towards bringing support for Trusted Types in the Firefox browser. But, unfortunately, Safari supports neither nonce-based Content Security Policy (only partially) nor Trusted Types, neglecting the need of improved security.
Similarly, the other security mechanisms listed above help mitigate many other common Web security threats, including but not limited to cross-site request forgery (CSRF) and XS-leaks – a new family of Web privacy-leaking techniques. Of course, that is not all, the works done by Google and Mozilla are going to introduce stricter security for everyone browsing on the supported browsers.
Share