Client-side security flaw earned modest bug bounty reward

Subtle Gmail XSS vulnerability placed under the microscope

UPDATED A security researcher this week published more details about a subtle cross-site scripting (XSS) vulnerability that affected Gmail.

Security researcher Enguerran Gillier uncovered the DOM-based XSS vulnerability in Google’s popular email service after looking at the postMessage API, rather than the more conventional routes of exploring URL parameters or the emails themselves for web security flaws.

The vulnerability, resolved in December 2018, still offers lessons for both web developers and white hat hackers.

Behind the iframe

A Gmail inbox may look like a simple webpage, but it’s actually a composite dozen of different webpages (or iframes), all communicating between each other.

The postMessage logger extension made it possible for Gillier to view frame-to-frame messages.

“Each message has a target (the frame which receives the message), a source (the frame which sent the message), an origin (the domain of the source) and the data, which can be a string or a JSON object (or any kind of object that will be cloned in the process),” Gillier explains in a blog post detailing his findings.

“Messages can be sent by any frame to another, even from different domain and even from different tab if the source has a reference to the target, with window.opener,, and window.frames.”

After examining an array of these messages in the console, one in particular stood out to Gillier as been worthy of further scrutiny.

A message sent by to not only featured a URL in the message data, but the URL contains the word ‘frame’.

On the CuSP of a discovery

Further examination allowed Gillier to determine how the message is received and how this process might be manipulated.

Sending a message to the frame from the console with the same data but with javascript:alert(1) instead of the URL generated a Content Security Policy (CSP) error message.

“Thankfully, this CSP rule wasn’t enforced by Internet Explorer 11 and Edge (at the time) so I was able to trigger the alert box on those browsers,” Gillier explains. “There was no check on the origin of the message.”

Evil tab pwnage potential

The finding revealed a potential method to attack Gmail users.

“A simple attack scenario is to start from the attacker webpage, open a new tab to Gmail and inject the payload in the Gmail tab using postMessage,” according to Gillier.

“The Gmail tab loads the JavaScript iframe and the attacker has arbitrary code execution on the victim’s Gmail page, which means it can read and send emails [or] change [the] password of accounts registered to this email.”

A potential attacker would still have to work out the channel name in order to run an XSS attack, but this obstacle can be overcome.

Read more of the latest security vulnerability news

By loading an iframe controlled by the attacker in the hierarchy of frames in the Gmail tab it is possible to be possible to intercept the channel name and execute the XSS, Gillier discovered.

Gillier was unable to discover an easy way to load an iframe inside Gmail – a finding that pointed towards a potential stumbling block for any attacker.

The researcher nonetheless reporting his findings to Google, who agreed he’d hit upon a genuine security flaw and paid him a bounty under its Vulnerability Reward Program.

The flaw – resolved in December 2018 – earned Gillier $5,000, the standard reward for an XSS in Gmail.

Asked what lessons might be drawn from his research, Gillier told The Daily Swig that the current time is a "golden age for DOM XSS".

"Frontend frameworks can level up their security by using TrustedTypes and checking postMessage origin by default for example," he explained. "For bug hunters, There are lots of DOM XSS waiting to be discovered. @phwd even found a DOM based CSRF in Facebook."

Google is yet to respond to our request for comment.

This story was updated to add comment from Enguerran Gillier.

RELATED Google fixes XSS bug in Gmail’s dynamic email feature