Growing together! - Githubissues

rfc-st commented 6 months ago

What is 'humble' missing?; being reasonable :):

What HTTP header checks do you miss?.
What totals do you think should be reported?.
What results export format do you need and why?.

Let's use this issue to talk about the shortcomings of 'humble' (without preventing specific issues to be created for specific topics), ideas to make it more interesting and accessible for everyone. With total freedom and regardless of your technical knowledge,

I have the healthy habit of thanking all the contributions that result in an improvement of this tool: https://github.com/rfc-st/humble/?tab=readme-ov-file#acknowledgements .

Thanks for your time!.

jdelamo3 commented 5 months ago

it would be a good idea to register a Humble formula in HomeBrew, which is one of the most popular package managers for macOSX and Linux, and which also greatly simplifies the compilation and installation of libraries and dependencies. https://brew.sh

rfc-st commented 5 months ago

Hi, @jdelamo3

I have “zero” experience in the macOS and HomeBrew worlds :); but I promise to take a look and see what the process is like.

Regards,

rfc-st commented 2 months ago

Hi, @jdelamo3

Reviewing the necessary steps to make your suggestion possible ... we will keep in touch.

Best regards,

cr4zyfish commented 1 month ago

check for security headers via meta tags. Deprecated HTTP Response Headers/Protocols and Insecure Values ====> separate these results

in this report for Deprecated HTTP Response Headers/Protocols and Insecure Values the value from server response is Deny so only the advice should be printed.

 X-Frame-Options (Incorrect Values)
 The only values allowed for this header are 'DENY' or 'SAMEORIGIN'.
 Advice: Replace this header with the CSP 'frame-ancestors' directive.
 Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

rfc-st commented 1 month ago

Hello, @cr4zyfish

Good suggestions, thanks!. I will take them into account.

Regarding the first one, it seems (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#http-equiv) that the definition of attributes associated with HTTP directives would really be limited to three of them, at the security level: 'content-security-policy', 'content-type' and 'x-ua-compatible' ... at the HTTP response header level 'humble' has checks for all three ... I have to evaluate whether it is worth retrieving and parsing the response body for those meta directives with the added parsing time that might entail.
Regarding separating the results of “Deprecated HTTP Response Headers/Protocols and Insecure Values” require modifying quite a lot of code (global/per URL statistics, grade of analysis, export to CSV/JSON, etc ...) but yes, it could be interesting to have specific sections for them.
Regarding the value and messages of “X-Frame-Options”, checking the standards gives me the impression that the only valid values of this header are exactly 'DENY' or 'SAMEORIGIN' ('ALLOW-FROM' is deprecated): https://www.rfc-editor.org/rfc/rfc7034#section-2.1, https://html.spec.whatwg.org/multipage/document-lifecycle.html#the-x-frame-options-header and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options#syntax. Hence the need to indicate that any other value is not correct, and also indicate the suggestion to use a more current option, such as 'frame-ancestors' from CSP.

Regards,

rfc-st commented 1 month ago

Hi, @cr4zyfish

Check out this commit: https://github.com/rfc-st/humble/commit/aeabd4ba094d9a3248e0122400cdd6ada6833ffb

'humble' checks, thanks to your suggestion, the values of headers defined via meta tags. For now two of them; I will improve this functionality.

I've added you at https://github.com/rfc-st/humble/?tab=readme-ov-file#acknowledgements.

Thanks & regards!.

cr4zyfish commented 1 month ago

I scanned a target it has this header: Cache-Control: no-cache, private

The result:

[3. Deprecated HTTP Response Headers/Protocols and Insecure Values]

 The following headers/protocols are deprecated or their values may be considered unsafe:

 Cache-Control (Recommended Values)
 Enable 'no-cache', 'no-store', and 'must-revalidate' if there are sensitive data.
 Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

why there is a warning here? is anything wrong with no-cache, private ?

this header reported in [1. Missing HTTP Security Headers] is not part of OWASP secure headers:

 NEL
 Enables web applications to declare a reporting policy to report errors.
 Ref: https://scotthelme.co.uk/network-error-logging-deep-dive/

is it a necessary header?

May be more explanation is needed for user why X-XSS-Protection: 1; mode=block is unsafe Value. because not everybody know why 1 is unsafe.

 X-XSS-Protection (Unsafe Value)
 To mitigate XSS attacks, restrictively use the "Content-Security-Policy" header.
 Ref: https://auth0.com/blog/defending-against-xss-with-csp/

These headers are in my target:

Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

but in reports says:


[3. Deprecated HTTP Response Headers/Protocols and Insecure Values]

 The following headers/protocols are deprecated or their values may be considered unsafe:

 Keep-Alive (Ignored Header)
 This header is ignored if the value of the "Connection" header is not 'keep-alive'.
 Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive

The value of Connection is Keep-Alive but still this result shows up in scan.

rfc-st commented 1 month ago

Hi, @cr4zyfish

Regarding 'Cache-Control' the warning is more of a recommendation (hence the indication of 'Recommended Values'), to completely avoid caching resources that may be associated with sensitive information, if indeed there is any in the URL being analyzed.

Regarding NEL, 'humble' not only analyzes the set of HTTP response headers considered secure by OWASP, but is much strict and comprehensive, extending checks to more headers, including experimental ones: https://github.com/rfc-st/humble/?tab=readme-ov-file#checks-deprecated-headersprotocols-and-insecure-values & https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/NEL

Regarding 'X-XSS-Protection', indeed, I will include an additional reference indicating why '1; mode=block' is not recommended: in some cases XSS protection can create XSS vulnerabilities (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection) and also this header is deprecated in the three major web browsers.

(You can always use the -s parameter in 'humble', excluding the HTTP headers of your choice from the analysis).

And finally, regarding 'Keep-Alive', it seems the value for that header should be exactly 'keep-alive', according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection.

Thanks & regards!.

rfc-st commented 1 month ago

Hi, @cr4zyfish

Check out this commit: https://github.com/rfc-st/humble/commit/07fcb54b6863d06e9a87cbea751c15cd9b1549fe

Thanks to your suggestion, I have improved the message and the reference associated with checking for values other than '0' in the 'X-XSS-Protection' header.

Regards!

rfc-st commented 1 month ago

Hi, @cr4zyfish

Check out this commit: https://github.com/rfc-st/humble/commit/7bf86326a66b244bf0d6bf880f0d668b46b6f00b

You were absolutely right: now 'humble', when checking for missing HTTP headers (e.g. 'NEL'), shows whether the header is Experimental or not, based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers:

exp_header

It's a start; I will think of ways to improve these messages.

Regards!

rfc-st commented 1 month ago

Hi, @cr4zyfish

Take a look at this.

I think 'humble' reflects now more clearly everything related to experimental HTTP headers :).

Regards!

vincentcox commented 1 day ago

I have a humble feature request. Is it possible to show which headers are present (like in "test passed")? Would be nice to have that in Json output too!

Thanks!

rfc-st commented 12 hours ago

Hi, @vincentcox

Thanks for your suggestion: on which specific HTTP response headers would you want to see if they have passed or not? humble, currently, has 113 checks (focused on insecure values or those considered deprecated), 14 checks (focused on missing headers) and 1186 checks (focused on fingerprint headers).

Do you have an example, in text, of what you would like to see displayed?

Additionally, with the '-r' parameter humble shows the HTTP response headers enabled on the analyzed URL.

Regards!,

rfc-st / humble

Growing together! #19