Demystifying an XSS Payload: Part 3 — BruteLogic special
Let’s demystify an amazing XSS payload shared by XSS expert Brute Logic!
XSS is an amazing injection issue that I have been in love with! So much that I am deeply learning all the nuances of it and all the techniques there are on the subject!
Lately I came across the an amazing XSS payload shared by BruteLogic, which I wanted to demystify in this post.
The Payload
So yesterday, BruteLogic shared an interesting XSS payload:
`/alert?.(1)’”><Svg/OnLoad=’`
Let’s break it down and see what it does and why it does what it does :)
The vulnerable page can be found here: https://brutelogic.com.br/multi/double-html.php
Tinkering Around
Let’s first explore this page and see what’s the issue and if we can leverage it via any simple XSS payload — reason being that we can appreciate the shared payload only when we understand what’s the utility of the payload!
So let’s tinker around and see how things behave first:
If a parameter `p` is passed to this URL, the parameter value is placed inside the href attribute: https://brutelogic.com.br/multi/double-html.php?p=testing123
So as you can see the value of parameter `p` is reflected in the page — inside the href attribute.
So let’s see if we can exploit it using some XSS payload we already know of? Think of it as a challenge for yourself — and don’t use the payload BruteLogic shared! Otherwise there’s no point of this little exercise right!!
A few payloads:
Try this payload:
Payload: ”><script>alert(1337)</script>
URL (with payload): https://brutelogic.com.br/multi/double-html.php?p=testing123%22%3E%3Cscript%3Ealert(1337)%3C/script%3E
And that simply works and gives you a double XSS — 1 per link!
So this payload simple escapes the href attribute context, closes the <a> tag and adds the script — simple enough right!
But if there was a WAF it would easily detect this attempt!
Hmm, let my try another payload:
” id=x onfocus=“eval(8680439..toString(30)+‘(1337)’)”>
URL (with payload): https://brutelogic.com.br/multi/double-html.php?p=testing123%22%20id=x%20onfocus=%22eval(8680439..toString(30)%2b%27(1337)%27)%22%3E#x
So this one is another XSS using onfocus event handler where I am running using eval to popup the alert!
You can read more on this specific payload and how it works here:
So this payload is comparatively more neat and maybe it might bypass some WAFs — there’s no direct script tag or alert. But eval is there which might be a red flag!!! But still this payload looks interesting enough.
Finding the Answer
Since we know how we can perform XSS in this scenario, let’s get back to BruteLogic’s payload:
`/alert?.(1)’”><Svg/OnLoad=’`
So what’s this payload about?
If you use it in-place of the other payloads, in the `p` parameter, you would notice what it really does:
URL (with payload): https://brutelogic.com.br/multi/double-html.php?p=%60/alert?.(1)%27%22%3E%3CSvg/OnLoad=%27%60
As you can see in the page source, the attribute context was escaped (using a double quote `”`)
Then an SVG element is introduced to the DOM. It contains an onload event handler.
I modified the payload a bit and added id=x to the SVG element just so that I can see all of its attributes.
Now let’s head over to the console (press CTRL+SHIFT+I):
We can notice that the SVG element has 3 attributes: id, onload and an attribute named “ (a double quote).
The onload attribute is the one where the XSS magic happens. Let’s get into it for understanding how it works!
The payload is simple in the sense that all it does is — when an SVG loads, when run this javascript code which is present in the onload event handler.
And that string might be looking weird, but it’s very simple. Allow me to explain :)
“`\”>link one</a>\n<div name=\”div\”></div>\n<a href=\”`/alert?.(1)”
Let’s try to run it in the console first. And if you do, you would notice an alert pop up!
So what does it do?
All it does is divides the value of the first template string with the alert(1).
And in order to compute the result of the division, both — numerator and denominator have to be computed right. And that’s why when alert(1) is computed, alert shows up! Nothing fancy there…
You could have used ‘-’ (subtraction) and that would have worked equally well!
Payload using subtraction:
`\”>link one</a>\n<div name=\”div\”></div>\n<a href=\”`-alert?.(1)
Awesome, I get it all now! But what is this ?. thingy?!
Brilliant question :)
?. is the Optional Chaining operator in Javascript.
Let’s say you want to reference some property bar within an object foo:
So you would do the following right — foo.bar
But if foo doesn’t exists you will get an exception right!
But when you use the optional chaining operator (?.), you won’t get an exception, but undefined instead :)
Sweet right!
So now you don’t have to decorate your JS code with ugly if-else statements and can get away with using the ?. operator!
Great! Back to the payload now…
alert?.(1234) is just a fancy way of writing alert(1234)
And this can be helpful if for instance alert is not available in a sandbox for instance, in those cases you can try to write your payload using this operator so that there are no exceptions (because exceptions might get reported back to the developers ;).
Payload Utility
BruteLogic mentioned in the tweet that:
This might help to bypass some filter/WAF if it checks only for regular chars after event handler in multi reflection scenarios.
As you could see this scenario was of a multi reflection — our payload was reflected at 2 places.
And the payload leveraged the position of those 2 consequent locations to construct this XSS vector. And therefore if a filter/WAF was checking only for regular characters after event handlers, it would miss out this construct right, because the event handler itself contains the XSS payload sneaked inside!
Key Takeaways
I hope you understood the utility of this payload and if you are on the defending side, maybe it gives you more insights on why you should also check the event handlers and not just the stuff around it because the main stuff is in the event handlers.
Although one things that I and maybe many of you might argue is that basic keywords like alert and eval should already be detected by WAFs right?! So why are we talking about this payload?
And I would say its a good question but the answer lies in the construct, not the payload used! alert just shows you a PoC, and its just a placeholder. So get creative and add whatever you wish there :)
The main takeaway should be that how the attribute context was bypassed and the sneaked in payload added the XSS payload.
If you now look at the payload, after reading this post, you would notice that there’s nothing special about it :) But earlier it looked too freaking mysterious… Hahaha!
But nonetheless, it was an amazing payload and we reverse engineered it to understand its mechanics!
Closing Thoughts
I hope you enjoyed this post and learnt something interesting. Or maybe it was a payload you already knew about, but hopefully I gave to an important point to always dig deeper and understand what the payload actually is all about! This will take you much ahead and give you an edge over your peers and maybe personal satisfaction :)
Let me know your feedback in the comments below and feel free to connect on twitter: @_SecurityGOAT
Lastly, if you have been enjoying my work and would love to support me, consider checking my Patreon page or you can even Buy Me a Coffee :)
See ya!
Until next time, keep learning and happy hacking.
