What Gmail’s dynamic email XSS vulnerability can teach us about cross-site scripting

What’s XSS?

Cross-site scripting or better known as XSS is a type of injection attack. This is where malicious scripts are injected into otherwise legitimate and trusted websites. Attackers use XSS to trick unsuspecting users. These forms of attacks come through to the user as web browsers can fail to identify malicious scripts. Particularly if they are from a seemingly trusted source. Usually, these attacks could access cookies, session tokens, or other browser-related sensitive information.

There are two instances when XSS attacks happen,

1. Entering data to a web application via an untrusted source
2. Data included in dynamic content sent to end-user without validating for malicious content

Additionally, XSS attacks take on two forms – stored and reflected attacks. Stored XSS attacks are when the malicious script is permanently stored in the target servers. This can be on a database or even a comment field. Reflected XSS attacks reflect the injected script off the server such as through an error message. These attacks are usually delivered through emails or as a form on a website, tricking the user to access the malicious code by presenting it through legitimate means. As a result, the injected code goes through to the vulnerable web site, reflecting the attack back to the user’s browser. The browser executes the code.

Then there’s also DOM XSS attacks. This can be JavaScript frameworks, single-page applications or APIs that dynamically includes attacker-controlled data to a page.

Gmail’s XSS vulnerability

Gmail, everyone’s go-to email client recently had a serious XSS vulnerability patched. The vulnerability was discovered by Michal Bentkowski, the chief security researcher at Securitum. It was found in the Accelerated Mobile Pages for Email (AMP4Email) feature, otherwise known as the “Dynamic Mail”. Ironically, Dynamic Email is a new feature that came out of beta for Gmail that aimed to make webmail experience more dynamic.

Google’s Accelerated Mobile Pages project kicked off in 2015 with the aim of enhancing web performance on mobile platforms. According to Adobe, top publishers in the United States saw 7% of their total traffic, across all devices, delivered through Google AMP within the first year. About 3 years later, Google unveiled a developer preview for the AMP4Email feature. In it, Google states how “AMP started as an effort to help publishers, but as its capabilities have expanded over time, it’s now one of the best ways to build rich webpages. With this came the opportunity to modernize one of the most popular places where people spend their time: email.”

The idea of AMP4Email is to enable a wide range of functionality from responding to event invitations to managing hotel reservation details within Gmail itself. Unfortunately, this also presented a cross-site scripting attack opportunity for hackers. The vulnerability is a case of Document Object Model (DOM) Clobbering, a legacy feature in web browsers.

What’s DOM Clobbering?

Usually, you would use different functions when you want to reference an HTML element in JavaScript. If this is done in the legacy method, access is obtained via a property of the global ‘window’ object. In other words, using “window.username” instead of “document.getElementById(‘username’)”. This is essentially DOM Clobbering. As Michal puts it, DOM Clobbering “can lead to interesting vulnerabilities, if the application makes decisions based on the existence of certain global variables”. Thereby, attackers could potentially compromise Gmail users’ systems by injecting malicious codes into the dynamic Gmail message.

In his report, Michal mentions that “AMP4Email tries to load certain JS files and fails to do so because of 404. What is particularly eye-catching, however, is the fact that there’s undefined in the middle of the URL… AMP tries to get the property of AMP_MODE to put it in the URL. Because of DOM Clobbering, the expected property is missing, hence undefined”. Due to this undefined tag, the full URL can be controlled.

By the 15^th of August, Michal informed Google about his findings. By September, Google responded saying that the bug is “awesome”. A month later Google confirmed that the vulnerability has been patched.

How serious was the vulnerability?

This XSS vulnerability is obviously a concerning security threat from the user’s point of view. But the vulnerability may not raise the same level of concern compared to the recent Google Camera app security threat. In case you didn’t know, a company named Checkmarx recently reported a vulnerability in Google’s Camera app. According to the report, users in the hundreds of millions were affected.

To be fair, AMP4Email does employ some level of protection against DOM Clobbering as it prohibits certain values for the “id” attribute. However, the same restriction wasn’t implemented for the “AMP_MODE” attribute. Hence, the security loophole. Fortunately, Google has already patched the vulnerability.

Protecting yourself against XSS attacks

Cross-site scripting attacks remain one of the biggest security threats even today. OWASP’s 2017 list of top 10 list of security threats for 2017 includes cross-site scripting as one of them. When it comes to these types of attacks, there’s very little you can do when attacks originate as a result of a vulnerability from the vendor’s side. But that doesn’t mean you can’t protect yourself from XSS attacks. There are a few ways XSS attacks can be mitigated.

• Escape XSS by design. What this means is using frameworks such as the latest Ruby on Rails or React JS.
• Escape untrusted HTTP request data based on the HTML output’s context.
• Application of context-sensitive encoding when modifying browser document on the client side acts against DOM XSS.
• Facilitation of a Content Security Policy.

Additionally, mechanisms such as input validation could also enhance better security against cross-site scripting attacks. The OWASP XSS Prevention Cheat Sheet offers a more detailed approach towards safeguarding against these attacks.

Of course, while these methods reduce XSS risks to a great extent, these can be further mitigated from the development stage itself. Google’s Gmail XSS vulnerability is a testament to this fact. A combination of methodologies like code review and static testing during development would enable better preventive measures. Furthermore, following proper secure coding practices would not only mitigate cross-site scripting attacks. But it would prevent other forms of attacks as well. After all, security is a vital component in our ever-increasing digital lives.

• Tags:
• Vulnerability