[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvas-plugins
Subject:    Re: [Openvas-plugins] [openvas-Bugs][6925] False positive result from "ClearBudget Invalid '.htacces
From:       Christian Fischer <christian.fischer () greenbone ! net>
Date:       2017-05-09 13:30:04
Message-ID: f5cc4378-a9f9-0115-0df6-fd85c9c2d05e () greenbone ! net
[Download RAW message or body]

Hi,

On 21.04.2017 12:26, Christian Fischer wrote:
> Hi,
> 
> On 21.04.2017 11:17, Chris Butler wrote:
> > Hi,
> > 
> > Following up to my comment on: \
> > https://wald.intevation.org/tracker/?func=detail&atid=220&aid=6925&group_id=29 
> > > thanks for your report. That webserver behaved quite strange and returned a 200
> > > with the following content back if a request was coming from OpenVAS:
> > > 
> > > <input type="hidden" name="AfterLoginGoTo" \
> > > value="/application/db/budget.sqlite" 
> > > This matched the pattern in that check as it was looking for "sqlite" and a 200
> > > in the response.
> > > 
> > > Just have commited a fix into the feed to avoid a false positive. Will also
> > > check why we're getting a different response in the next few weeks.
> > > 
> > > For further NVT problems please use the
> > > https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins
> > > mailinglist as this bugtracker is abandoned.
> > > 
> > 
> > Ah, I can see now why the webserver is returning a different response to what we \
> > see in a web browser. I'm guessing that OpenVAS isn't providing a "Host" header \
> > when it goes to the URL \
> > https://83-223-123-138.as29017.net/application/db/budget.sqlite but the browser \
> > is. 
> > Without a host header, our nginx web server is taking the first host that matches \
> > based on the IP address, which ends up at the login page for our web application. \
> > It would actually give a 404 if logged in, but default behaviour is to redirect \
> > to login for all addresses to avoid any information disclosure to unauthenticated \
> > users. 
> > When going there in a browser the Host header causes nginx to select the \
> > "catch-all" name-based vhost on the same server (since a name-based vhost match \
> > takes precedence over an IP-based one apparently), and this gives the 410 "domain \
> > not found" response. 
> 
> thanks for your follow-up. I came to the same conclusion during my test,
> currently httpver.nasl is only detection HTTP/1.0 support at this server
> due to a broken test for HTTP/1.0 vs. HTTP/1.1 support. Because of this
> no Host header is sent and this explains the difference.
> 
> Updating the httpver.nasl to correctly detect HTTP/1.0 vs. HTTP/1.1 on
> such hosts is already on my TODO list since a few days but it will take
> some time to implement and test the changes.

just want to let you know that issues has been fixed and should be
available in one of the next feed updates.

The main issue here was, that this old implementation of httpver.nasl
assumed HTTP/1.1 support if one of the following HTTP status codes matched:

buf =~ "HTTP/1.1 20[0-6]" || buf =~ "HTTP/1.1 30[0-7]" || buf =~
"HTTP/1.1 40[13]"

Your server responded with an HTTP/1.1 410 (which is absolutely fine)
and so only HTTP/1.0 support was assumed. I've simplified this check:

https://lists.wald.intevation.org/pipermail/openvas-nvts-commits/2017-May/006077.html

as we shouldn't make a decision of the HTTP version support based on a
response code other then 505 (HTTP Version Not Supported).

Regards,

-- 

Christian Fischer | PGP Key: 0x54F3CE5B76C597AD
Greenbone Networks GmbH | http://greenbone.net
Neumarkt 12, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-plugins mailing list
Openvas-plugins@wald.intevation.org
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins


[prev in list] [next in list] [prev in thread] [next in thread]