Researcher Gareth Heyes performs some cross-site scripting trickery at OWASP’s flagship European event
According to a 2017 State of Software report from Veracode, XSS was likely to be found in 40% of web applications – and this class of security flaw has remained a fixture on the OWASP Top 10 web security threats since the list’s inception.
While mitigations have been put forward, researchers continue to demonstrate how these protections can easily be broken.
Indeed, no browser is safe from exploitation, due to the fact that they allow the parsing of classes of content that leave vulnerable websites or apps open to XSS attacks.
Speaking at Global AppSec 2019 in Amsterdam yesterday, PortSwigger Web Security’s Gareth Heyes presented a roundup of tricks that can be used to creatively leverage XSS flaws, many of which highlight the inconsistencies in the web app security ecosystem.
Pwning the filter
One particular hotspot for injecting malicious JavaScript into an application is via cross-site scripting filters – code used in an application or browser to protect against potential XSS issues.
“Hacking filters is kind of like [playing] a mind trick with the filter,” Heyes said. “You try to convince it that your input is safe when, in actual fact, it’s been converted to something malicious.”
In order to trick a filter into accepting input that contains malicious code, Heyes turns to the use of consuming tags, such as title, noscript, and noframes.
“Consuming tags will consume an image, an attribute, until it finds a closing tag,” Heyes explained.
“Think of it like a monster that eats HTML.”
Noframes and fortune
An XSS filter will assume that everything within the consuming tag is fine, Heyes said. This provides a window of opportunity to inject malicious code that the filter thinks is safe.
He gives the example of the noframes tag.
“All browsers will ignore markup in the noframes tag because they support frames,” Heyes explained.
“If we inject an image tag, and end in a noframes tag, then this image tag is not rendered by a browser.
“Inside the alt attribute you can then inject a noframes tag and, suddenly, you break out of the alt attribute and can execute alert(1).
“That becomes a script, and this is a way to fool the filter into injecting malicious code.”
The use of XSS filters by browser developers has fallen out of fashion.
In July of this year, Google made the move to deprecate XSS Auditor for Chrome – a security feature that was known for various bypass exploits.
The deprecation of XSS Auditor followed the removal of XSS protection in Microsoft Edge a year earlier.
“We won’t be able to abuse the XSS Auditor behavior, but there will always be other non-browser-based filters to hack,” Heyes said.
Bypassing CSP
Researchers can also circumvent Content Security Policy (CSP), a technology used by browsers to block external resources and prevent XSS attacks.
“It’s a bit like a firewall for HTML,” Heyes explained.
“Imagine we’ve got a CSP policy with these directives, and what it’s basically saying is that you can’t load any resource on any tag.”
By injecting a base tag with the target attribute, an attacker could change the window name for every link on the page and then inject markup into the window name.
“It sets the target for every link on the page,” Heyes said. “All of the markup will then get stuffed in a window.name because the browser will allow you to place whatever you want there.”
RECOMMENDED OWASP reveals top 10 security threats facing API ecosystem
Heyes said that all browsers were susceptible to this issue. The researcher was able to come up with a mitigation – adding a base tag with target_self – which he later bypassed, partly due to the ongoing problem related to the use of window.name in browsers.
“Browsers are reluctant to lock down window.name because some sites use the behavior to send data cross domain,” Heyes said.
“And because some sites use window.name for legitimate use, it’s hard for browsers to patch it without breaking the web.”
Leaks are so hot right now
As web application developers have become more aware of XSS flaws, side-channel attacks have also appeared as a means to bypass certain security controls – a family of techniques appropriately called ‘XS-Leak’.
“It’s a way of getting some information from an external site in a way that doesn’t break the same-origin policy,” Heyes explained.
“But in a way gives you access to some information that you shouldn’t really have access to.”
RELATED New XS-Leak techniques reveal fresh ways to expose user information
“If anything privacy-sensitive is placed in an id attribute in iframes, inputs, textareas, audio, or video, it may be possible to brute-force the value provided the site can be framed,” he said.
By loading the target domain, Heyes was able to modify the hash in order to determine the value of an id attribute on input element from a site within a different domain. This works, Heyes explained, since the hash is not sent to the server.
“For example, let’s say we want to discover what id the following input element has on a site from a different domain using <input id=1337>,” Heyes said.
“We could load the URL containing the element, when the onload event fires we could change the hash and if the blurevent fires we have found the correct id. If not [we would] increment the value and check again.”
In line with his presentation, Heyes has published an XSS cheatsheet to make it easier for JavaScript developers and web security researchers to filter and find fresh XSS vectors.
YOU MIGHT ALSO LIKE An Inspector calls: New tool exposes hidden vulnerabilities in browser objects