Hi Guys,
First of all I would like to thank you for picking up the issue I brought. I conducted a quick experiment and checked how apache.org headers look like and got: $ curl -I apache.org | grep Server Server: Apache I did also a deeper dive and checked a bigger sample of n=86 webpages of ASF sponsors. ===BEGIN OF EXPERIMENT=== STEP 1: we grab the list of ASF sponsors $ curl --url https://www.apache.org/foundation/thanks.html -v | grep sponsored | cut -f 2 -d\" > sponsors result: https://aws.amazon.com/ http://facebook.com/ http://google.com/ < Removed 80 lines > https://www.sonic.com/ http://www.surfnet.nl/ https://www.virtru.com/ STEP 2: we grab Server headers for results from STEP 1. Any missing are replaced with 'SERVER OBSCURED' $ for subject in $(cat sponsors); do echo -n "${subject}: " >> servers; curl --connect-timeout 3 -I -k $subject 2> /dev/null | grep Server >> servers || echo 'SERVER OBSCURED' >> servers; done result: https://aws.amazon.com/: Server: Server http://facebook.com/: SERVER OBSCURED http://google.com/: Server: gws < Removed 80 lines > https://www.sonic.com/: Server: nginx/1.12.1 http://www.surfnet.nl/: Server: nginx https://www.virtru.com/: Server: cloudflare STEP 3: We organize the data and print histogram-like summary $ cut -f 3 -d' ' servers | sort |uniq -c > histogram result: 2 ATS 3 AkamaiGHost 2 AmazonS3 7 Apache 1 Apache/2.4.18 1 Apache/2.4.48 9 Cisco 2 GitHub.com 2 Kestrel 1 LiteSpeed 13 OBSCURED 1 PAAS-WEB 1 SE-1.15.12 2 Server 1 Tengine 1 Varnish 1 awselb/2.0 1 bfe/1.0.8.18 15 cloudflare 1 globaledge-envoy 2 gws 1 ias/1.4.2.3_1.17.3 14 nginx 1 nginx/1.12.1 1 nginx/1.14.0 ===END OF EXPERIMENT=== Observations from data: Observation 1: 15 out of 86 (17.5%) are not willing to share ANYTHING about their servers Observation 2: another 15 are hidden behind cloudflare, summing up to 35% Observation 3: 8/86 (9%) show any version numbers Observation 4: out of 9 servers who claim to be Apache 2 (22%) show varsions Conclusions: Only a tiny percentage of this sample is willing to show any version of their web server (not confirmed if what they show is what they actually run). In view of above, would ASF consider changing its reccommendation[1] from 'Minimal' to 'Product Only'? [1] https://httpd.apache.org/docs/2.4/mod/core.html#servertokens Piotr Sionkowski Senior Application Security Engineer GSK ul. Pastelowa 2, Business Garden, 60-198 Poznan, Poland Email piotr.g.sionkow...@gsk.com<mailto:piotr.g.sionkow...@gsk.com> gsk.com<http://www.gsk.com/> | Twitter<http://twitter.com/GSK> | YouTube<http://www.youtube.com/user/gskvision> | Facebook<http://www.facebook.com/glaxosmithkline> | Flickr<http://www.flickr.com/photos/glaxosmithkline> [signature_1981636734] From: Ruediger Pluem <rpl...@apache.org> Date: Wednesday, 25 August 2021 at 08:56 To: docs@httpd.apache.org <docs@httpd.apache.org>, Roy T. Fielding <field...@gbiv.com>, Piotr Sionkowski <piotr.g.sionkow...@gsk.com> Cc: Milosz Chmiel <milosz.l.chm...@gsk.com> Subject: Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org EXTERNAL On 8/25/21 1:51 AM, Roy T. Fielding wrote: >> On Aug 18, 2021, at 12:21 AM, Piotr Sionkowski >> <piotr.g.sionkow...@gsk.com.INVALID >> <mailto:piotr.g.sionkow...@gsk.com.INVALID>> >> wrote: >> >> Hello httpd docs @ Apache Software Foundation, >> >> I am writing this e-mail to learn more about ASF attitude towards presenting >> or hiding httpd server version details in headers. >> >> I have read the FAQ and documentation and agree with some statements and >> disagree with most. That is why I would like to have it >> clarified. >> >> Both in FAQ[1] and in documentation[2] it is discouraged to obscure the >> details of httpd server. The rationale provided is that >> (all are quotations from [1] and [2]): >> >> Arg1: It does nothing at all to make your server more secure >> Arg2: The idea of "security through obscurity" is a myth and leads to a >> false sense of safety >> Arg3: mistaken understanding that this will make the system more secure >> Arg4: the same exploits will likely be attempted regardless of the header >> information >> Arg5: it makes it more difficult to debug interoperational problems >> >> I have checked the reccomendation from OWASP[3] and they advise to remove or >> alter the headers so that no unnecessary details >> are presented. >> >> I tend to subscribe to owasp's point on view and would like to elaborate on >> it so that we can argue more precisely and reach >> meaningful conclusions. > > Hi Piotr, > > The Server header field is used by clients (especially user agents) to adjust > their behavior with respect to known errors in > servers. While OWASP is welcome to choose an opinion that is "more secure" > based on a theoretical concern, I can assure you (as > the HTTP editor) that their opinion is simply wrong with regards to the > usability of the Web as a long-lived system in the real > world. It simply doesn't matter to an attacker. The version does matter to > admins and customers, who can use automated tools to > ensure their websites are running the right version (or at least not the > wrong version) and trigger testing whenever that version > changes. That tends to result in systems that are actually more secure, > rather than trying to obscure that they aren't being > maintained properly. In addition with many servers in the real world being delivered by LTS Linux distributions just knowing the version number doesn't tell you if a system is vulnerable to a particular security issue or not. For example RedHat 7 ships with version 2.4.6. But if you run this package in the latest release it is not vulnerable to the security issues that a vanilla 2.4.6 server is vulnerable to. The only thing the version number tells you here is that this server is not vulnerable to issues that only affect versions below 2.4.6. And with regards to the product announced in the header I can tell you from practice that despite the servers I have managed clearly announce that they are an Apache I see tons of tries for IIS vulnerabilities being tested. The next thing you have to consider is that when you evaluate the Server header that you cannot be sure that the server you are talking to is really using the particular software announced in the header or if this the software used by some system further down below the chain and you are talking to a gateway system which does not have the vulnerabilities you might expect when looking at the header. The point is: If you as an attacker rely on the information of the header even if it is not obscured you can be severely misguided about the setup and you might miss a lot of attack opportunities if you rule them out upfront based on the header. Hence you need to try them out anyway unless you have other information sources that tell you reliably that it is not worth trying them. Regards Rüdiger GSK monitors email communications sent to and from GSK in order to protect GSK, our employees, customers, suppliers and business partners, from cyber threats and loss of GSK Information. GSK monitoring is conducted with appropriate confidentiality controls and in accordance with local laws and after appropriate consultation.
