zaproxy: False Positive: Backup File Disclosure

Describe the bug An active scan request to access: https://TARGETSITE/logincontext.jar receives this response:

HTTP/1.1 400 Bad Request
Server: nginx/1.17.6
Date: Tue, 28 Jan 2020 17:40:13 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 825
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Set-Cookie: JSESSIONID=A4A6E63AED4FEDF817894F22776B64D6; Path=/; Secure; HttpOnly
Last-Modified: Tue, 13 Mar 2018 05:24:24 GMT
ETag: W/"825-1520918664000"

<!--
  ~ Copyright (c) 2016, some vendor. All Rights Reserved.
  ~ 
  ~ LICENSE TERMS HERE
  -->

<html>
    <head>
        <title>Error 400</title>
    </head>
    <body>
        <h1>Error 400 - Bad Request</h1>
    </body>
</html>

Expected behavior I wouldn’t expect this response to be flagged as a successful ‘disclosure’ of a backup file as it doesn’t seem to disclose anything of interest (to me anyway).

Software versions

ZAP: 2.9.0 snapshot D-2020-01-07

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 19 (12 by maintainers)

Most upvoted comments

Have you tried the weekly release? I think this https://github.com/zaproxy/zap-extensions/commit/45d7523c6daa9317cc444f8b3b88fc034e86af8f might have fixed it. If so we just need to release the beta ascan rules…

psiinon on Jul 22, 2020

And it should be available now 😃

psiinon on Jul 22, 2020

We’re releasing the ascanBeta rules now…

psiinon on Jul 22, 2020

We’ll release the ascanBeta rules asap…

psiinon on Jul 22, 2020

I agree with @davewichers here: Anything other than an HTTP 200 shouldn’t be flagged as a successful backup file disclosure. Also, there needs to be some kind of other check for example on content/type.

Might even be possible to check for keywords in the body of the page like in the example above “HTTP 400 - Bad Request”

This false positive is very common and creates a lot of ‘noise’, as the developers complain, in the scans we perform. I’ll see if I can dig up some more examples to test against.

globeone on Feb 6, 2020

Maybe. I don’t know. I can ask for MADEUPFILENAME.jar and it responds with a 400. So the existence, or not, of the JAR file is irrelevant to the behavior. I just don’t see how a 400 bad request discloses the existence of a ‘backup’ file.

davewichers on Jan 28, 2020