Improving the impact of a mouse-related XSS with styling and CSS-gadgets
I will write more about how I make PoCs in the future. But with special care, I work out scenarios for vulnerabilities that need user interaction.
For example, if I find XSS via the onmousemove or onmouseclick event, I always try to style the vulnerable element in such a way as to stretch that element to the maximum possible area of the page.
I usually use something like
{position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5}
Then in the report, instead of “the user enters the page, scrolls it down, finds such and such an image and points the pointer at it”, you can write “the user enters the page, and moves the mouse anywhere on the page”. This shows that the attack can be implemented in real life, and not only if you think like an attacker:
CSS-gadgets
But what if the style attribute is blocked by WAF, and the vulnerable element is in such a non-obvious place that there is a chance to get informative?
For example, some tiny link in the footer of a view page
<a href=”INJECTION”>
turned out to be vulnerable and we were able to turn it into
<a href=”” onclick=alert() a=””>
but we cannot make a beautiful PoC through the style attribute.
In this case, I’m using the so-called (by me) CSS-Gadgets. Maybe someone else uses them, but I have not heard.
The bottom line is that you can “craft” the desired style using the application’s native styles. For example, it’s a good idea to add the properties width: 100% and top: 0 to the affected element.
We open the developer tools on the vulnerable page and look through all the styles. It is convenient to do this in Firefox, where they are all collected in one tab.
We find, for example
.test {display:block; color: blue; width: 100%}
and
#someid {top: 0; font-family: Tahoma;}
Now we can modify our link and bring it to the form
<a href=”” id=someid class=test onclick=alert() a=””>
Thus, without using the forbidden style attribute, we will give it the properties necessary for a normal payout.
And even if the WAF is completely evil, and it didn’t work out at all to execute the JS, but there is still an injection into the element, you can try to perform something like a deface in this way. If this element is important for the functioning of the application, you can hide it by applying a class to it with the property display: none or something like that.
Not an impact of the year, but there is a chance for at least Availability Impact: Low.
If you love my posts you can subscribe me on Patreon (from $1 per month): https://www.patreon.com/skavans
All my posts (including this one) are first published in my Telegram channel. Beyond, there is a lot of exclusive content about being a full-time Bug Bounty Hunter. Subscribe:
