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
