The JSON by itself is useless, you don't know where it'll end up, so auditing the POST vector itself doesn't do much good.
The way this should have been identified would be as a DOM XSS, by inputing the payload in some page input (or textarea etc.) and then triggering a submission of the payload by some DOM event (clicking a button or something) and then, if via whatever way (AJAX for example), the payload ends up in the DOM tree the issue should have been logged.
If the XSS is in a pop-up that could be why it's missed, I'll try some tests and let you know.
Looking at Piyush's HTTP request example.. should be an executable XSS as is without needing to be read by the DOM due to the text/html response content type. This is something that arachni should be flagging.. its a pretty generic xss.
on 15 Jun, 2017 05:09 AM
Exactly, my point. I would say to flag even if content type is not html with low risk. I have seen XSS in case of application/json content-type too whereby client side JS did parsing in insecure manner.
And what happens when the client gets the response, encodes it in JS and then places it in the DOM? Or if it truncates the response and uses only part of it? Or it performs some other computation and ignores it? etc.
on 15 Jun, 2017 01:52 PM
attacker can simple use HTML form for exploitation. You are looking more from developer perspective. It is very easy to exploit XSS for an attacker. Why not flag XSS if input is reflected back as it is.