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

[phillip-stephens]

I think this can be marked close, I made this issue when I familiarizing myself with ZGrab and didn't know about the --endpoint flag. Since then, commit 229a5b0 added --help to the http module:

$ ./zgrab2 http --help | head
Usage:
  zgrab2 [OPTIONS] http [http-OPTIONS]

Send an HTTP request and read the response, optionally following redirects
Ex: echo "en.wikipedia.org" | ./zgrab2 http --max-redirects=1 --endpoint="/wiki/New_York_City"

Additionally, now if a user tries to use the input I gave earlier, it errors:

$ echo "en.wikipedia.org/wiki/New_York_City" | ./zgrab2 http --max-redirects=2
INFO[0000] started grab at 2025-05-12T16:44:43-07:00
{"domain":"en.wikipedia.org/wiki/New_York_City","error":"could not resolve en.wikipedia.org/wiki/New_York_City"}

IMO, this can be closed because the user has the info they need to appropriately construct a query and gets a appropriate error if they don't.