I got an invite from a private program on hackerone and started searching for some vulnerabilites. After a while of searching, i found an url that had some interesting parameters. One of my inputs were reflecting inside of an hidden input tag.
<input type="hidden" name="SourceName" id="SourceName" value="hey">
So i tried to espace the value attribute by adding a quote, and i was able escape it succesfully. Now the catch is, after i escaped the attribute; i tried to close the input tag and open up another tag, but the app was giving error 500 when i entered < > characters. So i tried to execute xss inside of another attribute. I thought " onfocus="alert(1)" autofocus="
would do the job, but i was wrong. Even if i was able to succesfully inject the attribute; it wasn’t firing.
<input type="hidden" name="SourceName" id="SourceName" value="hey" onfocus="alert(1)" autofocus="">
So after i made a quick googling, i learned that because the input type is hidden it would never gain the focus and therefore the onfocus handler would never fire.
So i started searching for an alternate solution, at this point; i was looking this as an xss challenge, i had to solve this. After searching for a while i came across an article published on portswigger.net
So, to summarize the article: onclick events could be called on the hidden input when it activated via acces keys but only in firefox. So, after learning this my final payload was this:
<input type="hidden" accesskey="X" onclick="alert(1)">
With this payload, the user has to press ALT+SHIFT+X on his keyboard for this to fire. As i said earlier, this was like a challenge for me; as a result i learned a lot of new things. I would still be happy if this bug wasn’t accepted, since it needs a lot of user interaction.
As i said one of my write-ups: contexts are really important when it comes to searching for xss vulnerabilities.
I hope you guys learned something new by reading this write-up, if you have any questions; you can reach out to me via: My Twitter