Forum Discussion
Severity Update on plugin 84502 (HSTS Missing From HTTPS...
Severity Update on plugin 84502 (HSTS Missing From HTTPS Server)
Summary
We will be updating the severity level of plugin 84502 to INFO (currently MEDIUM)
Change
Plugin 84502 checks if the remote HTTPS server is not enforcing HTTP Strict Transport Security (HSTS). We will be changing the severity of the plugin to INFO level, as in some cases the missing HSTS does not imply a vulnerable server. Additionally, we are considering releasing a separate plugin, including extra HSTS checks with a higher severity level.
Impact
Plugin 84502 will see its severity level changed to INFO
Target Release Date
Thursday 5 November 2020
5 Replies
I have two different service on Windows, one developed in C++ and one in Java.
The 1st trigger only 84502, the second both 84502 and 142960... in the global reports I get the second service flagged with a medium vulnerability, the only one above the info level.
Why do we get this difference between the two plug-ins?
Hello, a new pluging at been created (HSTS Missing From HTTPS Server (RFC 6797) | Tenable®) that seems a duplicate of the plug-ins reported here (HSTS Missing From HTTPS Server | Tenable®)
The plugins 84502 has been updated to change the level to "information" but the new plugins 142960 has been created with severity medium.
I think the new plug-ins should be removed or changed to be "information" level.
Regards,
Hi @Edgar Coss ,
at least for us (tenable customer) this change makes sense for a number of reasons:
- this plugin also alerts a missing HSTS header on systems which are scanned by IP. Since you cannot get valid TLS-Certs on IPs a strict redirection to a HTTPS port cannot sent you to a secure site (since the site you're being forwarded to is presenting a wrong Cert).
- this plugin only makes sense on http endpoints which are accessed by endusers (ie browsers; See 2.1. Use-Cases in the RFC6797). In cases where the backend is scanned, the HSTS header doesn't make sense, since you typically configure the service which consumes the services of the scanned host to use a certain port. Most http-libraries which are used in backends do not support HSTS at all. Besides, HSTS is a standard to prevent End-User mistakes (accidentally browsing to an unsecure port). In Backend scenarios you should have explicit configurations and not relying on a redirect.
Don't get me wrong: its a valid approach to scan for this issue, but I'd say it only makes sense in a Web-App Scanner, not on the infrastructure scans.
Thanks for the information. It would be beneficial. for those that are curious, if some of the thinking behind the changes were explained.
Hi Edgar,
In fact, this action has been triggered by the fact that the plugins 84502 was, based on the investigation we made, wrongly reporting this error for a server with HSTS present. I can't know why the severity level has been changed instead of fixing the pluging. Now that the new/duplicate pluging 142960 is causing the same issue, maybe we will be able to address the root cause behind this.
