Serious security flaws found in Chrome ‘portal’ element

Security considerations next to none

A new HTML element available in a developer version of Chrome has put seamless usability ahead of security considerations, a researcher has found.

The security risks lie with <portal> – an HTML element to embed content from different domains in Chrome Canary, the experimental version of Chrome that’s aimed at developers. The feature is yet to appear in mainstream version of the Google browser.

Michal Bentkowski, chief security researcher at Securitum, discovered that the element specification lacked any security controls, so that an attacker could bypass the Same Origin Policy to read data from other domains.

An attacker would also be able to read local files on a target’s machine due to the Uniform Resource Identifier (URI) schemes implemented by the <portal> element.

URI schemes are the component of a URL that determines the directed protocol such as http, https, file, chrome, and data.

Browser security rules dictate that websites cannot redirect to users to the file scheme from another scheme, such as http, for example, because this would allow local files to be read.

“When doing my first tests, it turned out that the same restriction doesn’t apply to <portal> and I could open any page I wanted, including file: or even chrome: schemes,” Bentkowski said in a blog post.

“While it is obvious that browsers should not allow to open arbitrary URI schemes, the above example doesn’t constitute a direct security vulnerability,” he added.

“However, when you realize that you can also assign javascript: scheme to the URL (as you do in bookmarklets), this changes drastically!”

Bentkowski gives an example of a vulnerability in Chrome Canary that made the execution of arbitrary JavaScript possible, allowing him to siphon off data from two different domains.

The researcher reported the issue to Google on May 13, and the problem was fixed less than two weeks later. He was awarded a $10,000 bug bounty for his findings.

Bentkowski outlines this and other security concerns with the <portal> element – including clickjacking, potential XSSearch / XSLeaks issues and more – in a detailed technical blog post.