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

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.

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

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

zmap / zgrab2