ZGrab is adding a trailing slash `/` to URL's with http scans

[phillip-stephens]

Description

When scanning with the http module, it was noticed that zgrab2 is appending a single '/' character to the URL. This resulted in some target resources not being able to be scanned with ZGrab2.

Steps to Reproduce

Version of ZGrab2 - master branch, latest
ZGrab2 invocation - echo prstephens.com/src/style.css | ./zgrab2 http

tcpdump with appended /

    171.67.71.209.53166 > 104.21.96.65.80: Flags [P.], cksum 0xbc0e (incorrect -> 0xe547), seq 1:126, ack 1, win 502, options [nop,nop,TS val 512711372 ecr 1613683834], length 125: HTTP, length: 125
	GET /src/style.css/ HTTP/1.1
	Host: prstephens.com
	User-Agent: Mozilla/5.0 zgrab/0.x
	Accept: */*
	Accept-Encoding: gzip

Desired Behavior

Resources can either have or not have a trailing slash and zgrab2 should respect the user's selected input. No slash should be appended to the scanned URL.

[mzpqnxow]

Description

When scanning with the http module, it was noticed that zgrab2 is appending a single '/' character to the URL. This resulted in some target resources not being able to be scanned with ZGrab2.

Steps to Reproduce

Version of ZGrab2 - master branch, latest

ZGrab2 invocation - echo prstephens.com/src/style.css | ./zgrab2 http

tcpdump with appended /

    171.67.71.209.53166 > 104.21.96.65.80: Flags [P.], cksum 0xbc0e (incorrect -> 0xe547), seq 1:126, ack 1, win 502, options [nop,nop,TS val 512711372 ecr 1613683834], length 125: HTTP, length: 125

	GET /src/style.css/ HTTP/1.1

	Host: prstephens.com

	User-Agent: Mozilla/5.0 zgrab/0.x

	Accept: */*

	Accept-Encoding: gzip

Desired Behavior

Resources can either have or not have a trailing slash and zgrab2 should respect the user's selected input. No slash should be appended to the scanned URL.

It's arguable whether this is a bug, though I understand it's not intuitive

What I can tell you for sure, though, is that the intended way to request a URL path is:

echo prstephens.com | zgrab2 http --endpoint=/src/style.css

Like I said, what you're seeing is certainly not intuitive- but it's also not how the http module was intended to be used

The input should only be the target name (or the CSV format, which allows name, ip, tag/trigger and optionally, port, all on one line)

I'm actually a little surprised that it didn't result in a host header like:

Host: prstephens.com/src/styles.css

[mzpqnxow]

Description

When scanning with the http module, it was noticed that zgrab2 is appending a single '/' character to the URL. This resulted in some target resources not being able to be scanned with ZGrab2.

Steps to Reproduce

Version of ZGrab2 - master branch, latest

ZGrab2 invocation - echo prstephens.com/src/style.css | ./zgrab2 http

tcpdump with appended /

    171.67.71.209.53166 > 104.21.96.65.80: Flags [P.], cksum 0xbc0e (incorrect -> 0xe547), seq 1:126, ack 1, win 502, options [nop,nop,TS val 512711372 ecr 1613683834], length 125: HTTP, length: 125

	GET /src/style.css/ HTTP/1.1

	Host: prstephens.com

	User-Agent: Mozilla/5.0 zgrab/0.x

	Accept: */*

	Accept-Encoding: gzip

Desired Behavior

Resources can either have or not have a trailing slash and zgrab2 should respect the user's selected input. No slash should be appended to the scanned URL.

It's arguable whether this is a bug, though I understand it's not intuitive

What I can tell you for sure, though, is that the intended way to request a URL path is:

echo prstephens.com | zgrab2 http --endpoint=/src/style.css

Like I said, what you're seeing is certainly not intuitive- but it's also not how the http module was intended to be used

The input should only be the target name (or the CSV format, which allows name, ip, tag/trigger and optionally, port, all on one line)

I'm actually a little surprised that it didn't result in a host header like:

Host: prstephens.com/src/styles.css

In retrospect, I'm not certain about my assessment

If what I asserted is correct, it's arguably still fair to call this behavior a bug- for one, because "/" is not a valid hostname and should possibly be rejected in some way by zgrab2

It's your call either way @phillip-stephens

I could take a shot at a PR if you can determine about what the desired behavior is