Mailing List Archive

[FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org
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.



If we were to experience a targeted cyber attack against our servers it is certain that criminals would launch a battery of exploits against our assets and presence/absence of headers would change nothing about it. This supports your Arg4. Moreover, even if misleading data was presented to a determined attacker this would not make them narrow their arsenal. This seems to support arguments 1,2,3, and 4.



But not all attacks are targeted. If malicious actors have at their disposal an exploit that works on a given version of software they would probably first assemble a list of potential victims. Showing too much in one's headers can lead to appearing on the list or not. Not appearing on the list is in my opinion a valid way of cyber defense. It should not be named 'security by obscurity' as long as it is not THE ONLY means of defence taken. Cybersecurity is a multi-layer problem. This undermines arguments 1,2,3 and to some extent argument 4.



What is left to tackle from rationale provided is argument 5 - debugging. I would split debugging into two categories: internal and external. An engineer that is debugging internally should have access to some CMDB systems to learn what system they are dealing with, what are the version and who is the owner/administrator so that they can ask them any burning questions. I agree that this adds some extra steps to debugging but in my (and owasp's) opinion it is not the sweet spot where we should give up some security to gain some debugging ease. If we are dealing with external debugging in many cases this would fulfill the definition of a cyber attack.



What I would like to achieve with this e-mail?

I would like you to share your opinions on my argumentation against statements in docs and FAQ. If you agree with what I write I would like to have those statements[1,2] changed. If needed I can propose the change ? in this case I would need some guidance on how to do this and how to request necessary access.



Why it matters for me?

I am a security engineer trying to convince some other teams to hide unnecesary information from headers. They rejected my request using ASF statements as a rationale. I respect the authority ASF has earned in the tech world and would rather discuss with you problems I run into rather than state myself that we should act in opposition to what is written in ASF documents. Let's do it the Apache way[4]!



Thank you in advance,




[1] https://cwiki.apache.org/confluence/display/httpd/FAQ#FAQ-HowcanIchangetheinformationthatApachereturnsaboutitselfintheheaders?
[2] https://httpd.apache.org/docs/2.4/mod/core.html#servertokens
[3] https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server
[4] https://apache.org/theapacheway/index.html


Piotr Sionkowski
Senior Application Security Engineer

GSK
ul. Pastelowa 2, Business Garden, 60-198 Poznan, Poland
Email piotr.g.sionkowski@gsk.com<mailto:piotr.g.sionkowski@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_998159052]


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.
Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org [ In reply to ]
> On Aug 18, 2021, at 12:21 AM, Piotr Sionkowski <piotr.g.sionkowski@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.

.....Roy
Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org [ In reply to ]
On 8/25/21 1:51 AM, Roy T. Fielding wrote:
>> On Aug 18, 2021, at 12:21 AM, Piotr Sionkowski <piotr.g.sionkowski@gsk.com.INVALID <mailto:piotr.g.sionkowski@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

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org [ In reply to ]
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.sionkowski@gsk.com<mailto:piotr.g.sionkowski@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 <rpluem@apache.org>
Date: Wednesday, 25 August 2021 at 08:56
To: docs@httpd.apache.org <docs@httpd.apache.org>, Roy T. Fielding <fielding@gbiv.com>, Piotr Sionkowski <piotr.g.sionkowski@gsk.com>
Cc: Milosz Chmiel <milosz.l.chmiel@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.sionkowski@gsk.com.INVALID <mailto:piotr.g.sionkowski@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.
Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org [ In reply to ]
On 9/21/21 2:40 PM, Piotr Sionkowski wrote:
> 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'?

Thanks for the data, but in my opinion it actually tells you not much. From my experience in a lot of big companies people are
forced to stick to the owasp recommendations whether they make sense in peoples eyes or not. I for myself got tired with this
topic in professional life. If people demand me to remove that stuff I do, not because I think it makes sense, but because I do
not want to waste time any longer like in the past to discuss with people why I think it does not make sense and in the end the
only argument I get is: But owasp recommends it.
Just because people apply them does not tell you that the arguments we mentioned are wrong and what owasp recommends is right.

Regards

R?diger


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: [FAQ] ASF advisory regarding http headers verbosity contradicts with one from owasp.org [ In reply to ]
hello,

This is like arguing if VIM or emacs should be used. (jokes aside) I mean,
some companies will accept that as a vulnerability and will make the effort
to fix it and comply with security standards like OWASP as you mention
@Piotr. But not all time is as great as that.
If you search on any bug bounty program they exclude
meaningless vulnerabilities like cookies with no secure or http options, or
this header that you are mentioning will be no relevant.

But I do agree with you that this simple thing of removing the version or
tampering will "*improve*" your security posture or fool the bad guys, but
as Ruedinger says, if they want to hack you they will end up hacking
you, and possibly not because of a server header but for a human error, you
know.

Although you can have the header version, that's ok, but normally it's
behind something, a WAF, a fancy firewall or whatever.
The question here you have to ask yourself is, does the server have any
critical data?, does the server may disrupt the normal functionality of the
application? (i know this is too much for a simple header but sometimes it
might help securing it). But sometimes it can lead you to the fix.

And maybe you know about the netcraft server survey vendors:(
https://news.netcraft.com/archives/2021/08/25/august-2021-web-server-survey.html
)
[image: image.png]
similar to the data you posted ;) maybe you would like to have a look at
it.

In conclusion, *it depends on the security posture your company* would want
to have, whether they will remove it or not. ( i will do the same, remove
it or tamper it)
On the developers and sysadmin perspective will be just another header ;)

Hope it helps too,
Kind regards,

Luis



On Tue, 21 Sept 2021 at 15:45, Ruediger Pluem <rpluem@apache.org> wrote:

>
>
> On 9/21/21 2:40 PM, Piotr Sionkowski wrote:
> > 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'?
>
> Thanks for the data, but in my opinion it actually tells you not much.
> From my experience in a lot of big companies people are
> forced to stick to the owasp recommendations whether they make sense in
> peoples eyes or not. I for myself got tired with this
> topic in professional life. If people demand me to remove that stuff I do,
> not because I think it makes sense, but because I do
> not want to waste time any longer like in the past to discuss with people
> why I think it does not make sense and in the end the
> only argument I get is: But owasp recommends it.
> Just because people apply them does not tell you that the arguments we
> mentioned are wrong and what owasp recommends is right.
>
> Regards
>
> RĂ¼diger
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
>
>