Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http-enum does not honour some fingerprint values #1467

wants to merge 1 commit into from


Copy link

@mylk mylk commented Feb 11, 2019

While creating an HTTP fingerprint that should ignore the 404 check of non 200 HTTP responses, I noticed that http-enum.nse does not honour the values of the fingerprint properties:

  • ignore_404
  • severity

So, even if I set the fingerprint up with ignore_404 = true, it would always get to false.

Copy link

Hi, thanks for the feedback. I don't see how that code path (the else statement) could get triggered unless the value were not valid. What is the actual code of your fingerprint?

An example of a bad fingerprint that your code would simply pass through would be ignore_404 = "false", severity = -1

Copy link

mylk commented Feb 22, 2019

Hello @dmiller-nmap.
The else statement is executed whenever the value is valid.
A hardcoded value is set there, ignoring the value set on the fingerprint's definition.

My case was that I had to identify a web application that was expected to not return a 200 nor a 404 HTTP response. I noticed the doc block of http-fingerprints.lua mentioning ignore_404 that seemed to allow what I needed.
Setting the value to true did nothing, unless I did that change you see in this commit.

Copy link

Thanks for this patch. I have no idea what I was thinking earlier: your fix is clearly correct. I think nobody noticed it earlier because none of the existing fingerprints uses either severity or ignore_404. Applied in r37625.

@nmap-bot nmap-bot closed this in 61e2976 May 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants