Feature fail http to https for known status code and substrings #308
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merge master into fork
Merge back into master
Sync master
Sync with upstream master
…ed and certain known responses are encountered indicating HTTPS should be used * Apache: HTTP/400, substring "You're speaking plain HTTP to an SSL-enabled server port" * NGINX: HTTP/400, substring "The plain HTTP request was sent to HTTPS port"
vl4deee11
reviewed
Apr 7, 2021
modules/http/scanner.go
Outdated
| if readLen < sliceLen { | ||
| sliceLen = readLen | ||
| } | ||
| sliceBuf := bodyText[0:sliceLen] |
There was a problem hiding this comment.
you can replace with this sliceBuf := bodyText[:sliceLen]
There was a problem hiding this comment.
Thanks @vl4deee11, just committed. I'm very slowly picking up go as you can tell :>
|
@dadrian what are your thoughts on this? Is it a reasonable feature to include for the http module? I've gotten a good deal of use out of it and couldn't find any alternative aside from postprocessing results and running again, forcing https for the servers that behaved this way |
|
poke :) |
zakird
approved these changes
Jun 6, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements what is described in #273. If zgrab2 http was invoked with
--retry-https, the response code to a request is 400 AND one of the three known substrings is present, consider it as a protocol failure to cause a retry as HTTPSHow to Test
Use against an nginx or Apache server that speaks HTTPS. Specify
--retry-httpsand the flag implemented here (--fail-http-to-https). Rather than storing the 400 response that suggests you retry the request as HTTPS, zgrab2 will automatically retry as HTTPSNotes & Caveats
This is not a generic solution- it's a specific workaround for specific HTTP servers- nginx and Apache. I believe that the substrings included have very good coverage for this sort of behavior based on some sample data I collected
I considered what impact this might have on performance, but I figured since the function this happens in is responsible for performing the hashing of the body the limited logic and string comparisons shouldn't be much overhead. To be on the safe side, I slice the string down to a smaller size since the sub-strings it looks for are always towards the beginning of the response
Issue Tracking
Issue #273