Possible missing detection of jQuery

Vulnerability Tests
1

This still does not seem to work correctly. It does not catch the following path, at least in our case.

src="…/…/js/lib/jquery-2.1.6.js"

I don’t have enough experience to fix the regex, but perhaps someone can fix it?

2

I have split this posting into a separate topic as the one it was posted has already been fixed since many months and the current used regex is already catching your provided path / pattern so there is nothing which needs to be fixed in the regex.

https://regexr.com/5jnhk

The missing detection might be due to various different reasons:

  1. the page where the jQuery lib is included wasn’t found while crawling the web page (you can add additional directories / path to crawl to the cgi_path scanner preference)
  2. the page where the jQuery lib is included is hidden behind e.g. a login
  3. additional, general scanning problems (web server / page isn’t detected at all, network timeouts while scanning, scan configuration problems, environmental problems like outdated scanner, …)
  4. other unknown reasons
3

Okay, thanks for the info. I’ll do more testing later this week. I think the GVM jQuery plugin file I was looking for had a timestamp around August 2020 and I copied the regex from that file and tested that it didn’t match the path.

Nessus finds that jQuery thing just fine, so it should be findable in this case.

But this is my first time playing around with OpenVAS/GVM, so I don’t have yet much experience with that.

1 Like
4

There is always room for improvements when it comes to product detection, especially for HTTP / Web based products.

Please note that while the NASL based HTTP scanning capabilities are quite thoroughly these currently don’t have the goal to be a full replacement for a web application security scanner. So it always makes sense to do a WASS scan in addition to a scan with GVM for a wider / broader coverage, especially for unknown vulnerabilities.

Ah, yes. This is something NASL specific. In the jQuery Detection VT the following string is used:

pattern = 'src=["\']([^ ]*)(jquery[-.]?([0-9.]+)?(\\.min|\\.slim|\\.slim\\.min)?\\.js)';

Due to NASL treating the escaping of chars (\) in strings with single quotes in a special way these needs to be doubled escaped. So basically the regex above written in NASL is matching the following plain regex:

src=["']([^ ]*)(jquery[-.]?([0-9.]+)?(\.min|\.slim|\.slim\.min)?\.js)
1 Like
5

Hi,
Ah, yes. Thanks! That makes sense.

Is there a way to easily test this jQuery related .nasl?

Based on this information it should be possible but perhaps not so easy: Understanding testing of nasl scripts

I tried to run this as a root:

./openvas-nasl -X -B -d -i //var/lib/openvas/plugins -t gb_jquery_detect.nasl

But it didn’t output anything.

Based on the link above it may be that I need to include to the command all .nasl files that the g_jquery_detect.nasl is depending and also all their dependencies. Is this correct? Because it seems to be quite long list of dependencies…

Or how should I approach this testing task? Can I increase the log level somewhat that I would see what GVM really finds from the particular page when I’m doing the full scan?

6

Unfortunately GVM doesn’t provide any logging capabilities for NASL scripts. I’m mostly working with display calls like e.g. display(res); to get some idea on what’s done in a NASL script.

To call that specific Detection-VT from command line something like the following can be used:

openvas-nasl -X -B -i $pluginsdir -t $ip find_service.nasl httpver.nasl DDI_Directory_Scanner.nasl webmirror.nasl gb_jquery_detect.nasl --kb="Ports/tcp/$port=1"

Just replace $pluginsdir with the path to the scripts folder like e.g. /var/lib/openvas/plugins (depending on your setup) and the $ip and $port with the relevant data.

From a short look it might be possible that the missing detection is originating from the following:

   res = http_get_cache(port: port, item: dir + "/");

This is basically only querying the “main” page of the root dir and any found sub-page but would miss any installations / web pages having jquery located at some special pages like “mypage.php” or similar.

I guess the detection could be improved if all previously found .js files are evaluated as well which are returned by a call like e.g. http_get_kb_file_extensions(port: port, host: host, ext: "js" );

This might require a bigger change to that Detection-VT because it currently is missing the special handling for files gathered from the KB. I have raised an internal issue about that for now, lets see if a member of the feed team is tackling this task.

Btw. thanks a lot for showing interest into this topic :+1:

1 Like