Reflected XSS not detected

Piyush Mittal's Avatar

Piyush Mittal

17 May, 2017 03:19 PM

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.

  1. Support Staff 1 Posted by Tasos Laskos on 17 May, 2017 03:44 PM

    Tasos Laskos's Avatar

    It's hard to tell without a test case, could I be allowed access to that site to see what's going on?

  2. 2 Posted by Piyush Mittal on 18 May, 2017 09:06 AM

    Piyush Mittal's Avatar

    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.

  3. Support Staff 3 Posted by Tasos Laskos on 18 May, 2017 01:17 PM

    Tasos Laskos's Avatar

    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. 4 Posted by Piyush on 23 May, 2017 02:18 AM

    Piyush's Avatar

    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.

  5. Support Staff 5 Posted by Tasos Laskos on 25 May, 2017 09:54 AM

    Tasos Laskos's Avatar

    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. 6 Posted by rgutie01 on 15 Jun, 2017 12:26 AM

    rgutie01's Avatar

    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. 7 Posted by Piyush Mittal on 15 Jun, 2017 05:09 AM

    Piyush Mittal's Avatar

    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.

  8. Support Staff 8 Posted by Tasos Laskos on 15 Jun, 2017 08:51 AM

    Tasos Laskos's Avatar

    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. 9 Posted by Piyush Mittal on 15 Jun, 2017 01:52 PM

    Piyush Mittal's Avatar

    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.

  10. Support Staff 10 Posted by Tasos Laskos on 15 Jun, 2017 02:28 PM

    Tasos Laskos's Avatar

    I replicated your request and response and it turns out that Arachni detects the issue just fine.

    POST / HTTP/1.1
    Host: zonster:4567
    Authorization: Basic Og==
    Accept-Encoding: gzip, deflate
    User-Agent: Arachni/v2.0dev
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.8,he;q=0.6
    X-Arachni-Scan-Seed: 67a6143fbaa23d582db14891567f5b87
    Content-Length: 51
    Content-Type: application/x-www-form-urlencoded
    
    vuln=1%3Cxss_67a6143fbaa23d582db14891567f5b87%2F%3E
    
    HTTP/1.1 200 OK
    Content-Type: text/html;charset=utf-8
    X-XSS-Protection: 1; mode=block
    X-Content-Type-Options: nosniff
    X-Frame-Options: SAMEORIGIN
    Content-Length: 86
    
    {
        "errorMsg":"Error when submitting 1<xss_67a6143fbaa23d582db14891567f5b87/>"
    }{}
    

    Like I said, I need a test-case to see what went wrong.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

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