OP 27 November, 2020 - 12:11 AM
(This post was last modified: 27 November, 2020 - 12:12 AM by MeSvAk.)
While doing some shit bug hunting on a website, I entered a XSS payload as a subdirectory in the URL, in order to see if and how it was reflected on the source code. It’s one of the first things I do when I manual test a site for XSS. For this I always use a payload with common characters used in XSS payloads that are filtered under the fear of inserting js code. After entering the
I got a custom 404 response page. Looking at the source code, the URL was reflected in 3 places. In the two of them the payload was sanitized, but on the third one everything were getting reflected as they were. The source code for the third reflection looked something like this:
So by entering the payload
an XSS was triggered.
Everything was really simple. I browsed the website a little bit just to see how it was structured and then I went back to retest the XSS, just to be sure. Only this time… it didn’t work.
I tried to think of what could have changed between now and the time I triggered the XSS. I was changing parameters, payloads, user agents, basically everything. Still nothing.
Then, after some tries, I thought of re-entering the URL on a private session. That’s where the XSS got triggered again!
This happened because on the private session I didn’t click the “Accept Cookies” option on the pop-up that now every website is forced to provide. But I did it while browsing the website after finding the XSS. To be honest, I could have probably noticed that earlier in the DismissCookieNotice name in the source code.
To recall:
The vulnerability was inside the code for the pop-up (after accepting the cookies, the page refreshed and the pop-up source code was missing from the new page). So the XSS could be reproduced only by ignoring the Cookie pop-up (not dismissing it, just by ignoring it). that's why I never close pop ups and don't use addblockers if u wanna fuck sites and ur dads
The logic behind this pop-up was that after accepting the cookies, the website would redirect the user to the URL he already was. That’s why the URL was reflected in the “redirected” hidden input. But they forgot to filter the user input.
Next time you test for a reflected XSS, make sure to test it before you accept the cookies. You never know what u will get suckers just try and then bloxor ma sun is dick head don't forget that
Code:
https://cracked.to/"></>{}()vict0ni
Code:
<input
type="hidden"
name="DismissCookieNotice"
value="true"
/>
<input
type="hidden"
name="redirected"
value="https://www.website.com/"></>{}()vict0ni"
/>
<input
type="hidden"
name="csrf"
value=[something]
/>
So by entering the payload
Code:
https://cracked.to/"/><svg onload=alert(document.cookie)>
an XSS was triggered.
Everything was really simple. I browsed the website a little bit just to see how it was structured and then I went back to retest the XSS, just to be sure. Only this time… it didn’t work.
I tried to think of what could have changed between now and the time I triggered the XSS. I was changing parameters, payloads, user agents, basically everything. Still nothing.
Then, after some tries, I thought of re-entering the URL on a private session. That’s where the XSS got triggered again!
This happened because on the private session I didn’t click the “Accept Cookies” option on the pop-up that now every website is forced to provide. But I did it while browsing the website after finding the XSS. To be honest, I could have probably noticed that earlier in the DismissCookieNotice name in the source code.
To recall:
Code:
... <input type="hidden" name="DismissCookieNotice" value="true" /> ...
The vulnerability was inside the code for the pop-up (after accepting the cookies, the page refreshed and the pop-up source code was missing from the new page). So the XSS could be reproduced only by ignoring the Cookie pop-up (not dismissing it, just by ignoring it). that's why I never close pop ups and don't use addblockers if u wanna fuck sites and ur dads
The logic behind this pop-up was that after accepting the cookies, the website would redirect the user to the URL he already was. That’s why the URL was reflected in the “redirected” hidden input. But they forgot to filter the user input.
Next time you test for a reflected XSS, make sure to test it before you accept the cookies. You never know what u will get suckers just try and then bloxor ma sun is dick head don't forget that