Reflected XSS not detected
Hello,
I had a normal (form based) POST request and the response is a json object. Content-type in response is set to text/html. One parameter in request is vulnerable to reflected XSS. Although arachni did right XSS testing and input was reflected back in response but it didn't report any issue. I believe this is due to the fact that pop-up is not generated in the browser. Can you confirm if this is indeed the case.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Tasos Laskos on 17 May, 2017 03:44 PM
It's hard to tell without a test case, could I be allowed access to that site to see what's going on?
2 Posted by Piyush Mittal on 18 May, 2017 09:06 AM
Unfortunately, I can't give you access. However, I will try to provide as much info as possible. Attached is a redacted request and response as sent by Arachni scanner. XSS is not reported.
Support Staff 3 Posted by Tasos Laskos on 18 May, 2017 01:17 PM
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.
4 Posted by Piyush on 23 May, 2017 02:18 AM
Can't Arachni report such cases as input reflected back in response if not XSS. Currently, this all is going unnoticed.
I don't think this could have been identified via DOM XSS. I captured request using Burp, enter payload. It was reflected back; however, payload didn't execute.
The way I see it getting exploited is via HTML form. If you create a HTML form & because the response is text/HTML; XSS is executed.
Support Staff 5 Posted by Tasos Laskos on 25 May, 2017 09:54 AM
I don't think it works like that, the JSON needs to be parsed and its data placed in the DOM via JS, just being returned as HTML doesn't do anything.
This would be a DOM XSS case but without a test case I can't see what went wrong.
As for simply identifying sinks for taints, that could be useful, I'll keep it in mind for a future check of maybe plugin.
6 Posted by rgutie01 on 15 Jun, 2017 12:26 AM
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.
7 Posted by Piyush Mittal 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.
Support Staff 8 Posted by Tasos Laskos on 15 Jun, 2017 08:51 AM
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.
It's not that simple.
9 Posted by Piyush Mittal 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.
Support Staff 10 Posted by Tasos Laskos on 15 Jun, 2017 02:28 PM
I replicated your request and response and it turns out that Arachni detects the issue just fine.
Like I said, I need a test-case to see what went wrong.