Web pages are composed of a variety of different types of content. HTML is the skeleton of the webpage, defining the text and the page’s overall structure. CSS acts as the skin, allowing the web developer to control how the web page looks. Finally, a web page can include scripts, which enable animation and user interaction. While it is possible to exploit the other parts of web pages, the script contained within a web page is the most dangerous. Since the script is executable code, legitimate scripts may contain exploitable vulnerabilities, and attacker-generated scripts can allow malicious code to be run within a user’s browser.
One threat to website security associated with the inclusion of scripts within web pages is cross-site scripting (XSS). A cross-site scripting attack occurs when an attacker manages to get their malicious code embedded in a web page and executed within a user’s browser.
Google recently fixed an XSS vulnerability in Gmail, reported to them by an ethical hacker, that the internal security team described as “awesome”. This vulnerability was in AMP4Email, which enables dynamic email and has since been patched, enabling the discoverer to publish the details.
Table of Contents
A Quick Introduction to XSS
The rules governing how web pages are put together give developers a few options regarding how they organize the code that creates their page. One option is to have separate files for each type of code or even multiple files per type. In this case, the main HTML page will import the content of associated CSS and script files. This is a great choice when the same style sheet (CSS) file may be applied across the organization’s web presence.
The other option is to embed all of the page’s content in the same file. This is possible because the HTML standard includes tags for indicating that a chunk of content should be interpreted as CSS or as code in one of the available scripting languages. Cross-site scripting attacks take advantage of the ability to mix different types of content within a webpage. It is not uncommon for pages to print user-provided content to a page, whether in a “Hello Name” header near the top of the page or in user comments.
This user-controlled data is embedded within the HTML code of the webpage, which creates an opportunity for an attacker. If they can have part of their input interpreted as script code within the proper HTML tags, the page will run their code when loading.
Cybercriminals take advantage of XSS attacks in a variety of different ways. Many payment card skimmers (like Magecart) are implemented as XSS attacks, where the attacker gets their code embedded on a legitimate page in some way. Other attacks may use phishing emails with URLs containing script code that a vulnerable site will embed in the page before presenting it to the user.
The Gmail XSS Vulnerability
Google recently fixed an XSS vulnerability in Gmail. The vulnerability was in AMP4Email, which is designed to enable dynamic content in the email. The most recognizable form of this in Gmail is the ability to send an RSVP to a meeting request directly within an email in Gmail.
AMP4Email is structured like a web page, using the same HTML tags. This can make it vulnerable to XSS attacks, as demonstrated by the bug bounty writeup for the Gmail vulnerability. Using a technique called DOM Clobbering, the ethical hacker who discovered the Gmail vulnerability was able to identify a way to bypass some of Gmail’s anti-XSS protections.
The fact that AMP4Email could be vulnerable to XSS attacks was not a surprise to Google. In fact, the AMP4Email feature in Gmail has many of the tags that could be used to implement an XSS attack locked down for that reason. However, the bug hunter discovered that the <id> tag was not properly blocked in AMP4Email. By using this tag, they were able to write code in an AMP email that could have run an external script code.
In practice, the attack was not successful since Gmail also has a Content-Security-Policy (CSP) deployed in AMP that blocked it. However, an attacker who could bypass the CSP could exploit the vulnerability. The internal Gmail team said that the vulnerability was “awesome” and gave the full bug bounty payment (since bypassing a CSP was outside the expectations of the bug bounty program).
Protecting Against XSS Attacks
Cross-site scripting attacks are one of the most well-known threats against web pages and consistently feature on the OWASP Top Ten list of web application vulnerabilities. A cross-site scripting vulnerability allows an attacker to run malicious code within the user’s browser. Several different types of XSS attacks exist, mainly differentiated by their level of persistence (i.e. using a malicious link vs. embedding code in a comment thread on a webpage).
The fact that Google recently patched an XSS vulnerability in Gmail demonstrates the importance of deploying strong security protection on web content. While Google had several protections in place to prevent XSS attacks, the ethical hacker who discovered the vulnerability was able to bypass many of them, using loopholes to build a workable XSS exploit. The Gmail vulnerability was only not exploitable due to a built-in Content-Security-Policy in the affected software. A failure to have a similar system, like a web application firewall (WAF), scanning for malicious content could leave an organization’s website and its users open to attacks.