Researcher bypass email filter – XSS in Gmail’s AMP For Email

Reading Time: 3 Minutes

A cross-site scripting (XSS) vulnerability in AMP for Email, Gmail’s dynamic email feature, has netted a security researcher a $5,000 bug bounty payout.

AMP for Email brings AMP functionality to rich, interactive emails. AMP itself is an open source HTML framework used to optimize websites for web browsing on mobile.

Adi Cohen, who unearthed the security flaw, said he had no problem finding a vector that triggered an XSS within the AMP playground, but found bypassing Gmail’s XSS filter a much tougher assignment.

Rendering contexts

The “easiest way to circumvent an XSS filter is by tricking it into a different rendering context than what the browser will actually use to render a given piece of code”, observed Cohen in a blog post.

Since AMP for Email forbids the likes of templates, SVG, math, and CSS, he instead targeted stylesheets as a potential path to an XSS payload with multiple rendering contexts.

This required a discrepancy between how the stylesheet is rendered by the filter and browser, either by “tricking the filter into believing a fake style tag is real”, or “the exact opposite”.

Cohen’s initial vector worked in the sandbox because AMP “leaves the CSS context as soon as it encounters the string ‘</style’ even if it doesn’t have a closing bracket (>) or at least a whitespace after it”.

He was then able to “trick the filter into believing we’re back in HTML context, while the browser obviously ignores </styleX> entirely and stays well within the realm of CSS”.

</styl> over substance

But “what looked like a promising vector in AMP, seemed way less interesting after Gmail ran its magic on it,” said Cohen.

A breakthrough came when he harnessed a CSS selector, which ensured the payload was returned unchanged by Gmail – “no escaping or other mutations”.

However, the malicious payload prompted an error after the AMP sandbox encountered ‘</style’, so Cohen tried </styl>, but Gmail’s filter was wise to its resemblance to </style>.

What worked instead was testing a benign payload with an encoded selector – because Gmail decoded it, he could use the selector to inject a closing style tag.

Cohen reported the issue to Google on March 27, 2021, and noticed on July 7 that it had been fixed.

As previously reported by The Daily Swig, Google addressed an unrelated, notable XSS in AMP For Email back in 2019, after security researcher Michał Bentkowski leveraged id attributes in tags to enable ‘DOM clobbering’ attacks.

Are u a security researcher? Or a company that writes articles or write ups about Cyber Security, Offensive Security (related to information security in general) that match with our specific audience and is worth sharing?

If you want to express your idea in an article contact us here for a quote: [email protected]

Source: portswigger.net

Source Link