Re: Audit Exceptions on Apache
Am 2013-09-18 11:04, schrieb Joy Obba: Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 *Risk * This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. ***Response * Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. I absolutely agree with Mark. Security by obscurity has never worked out and you should not rely on. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Audit Exceptions on Apache
Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 Risk This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. Response Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. Risk There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. Response Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Kindly send documents that will assist us in resolving these vulnerabilities Kind Regards
Re: Audit Exceptions on Apache
On 9/18/2013 5:04 AM, Joy Obba wrote: Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 *Risk * This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. ***Response * Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. * Risk* There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. * Response* Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Kindly send documents that will assist us in resolving these vulnerabilities I think Mark's responses above tell you what you need to know in order to resolve these. Just look in the documentation for the implementation details. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Audit Exceptions on Apache
Hello David, Kindly assist with the documentation I need to use Regards From: David kerber dcker...@verizon.net To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, September 18, 2013 2:09 PM Subject: Re: Audit Exceptions on Apache On 9/18/2013 5:04 AM, Joy Obba wrote: Hello Team, Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 *Risk * This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. ***Response * Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. * Risk* There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. * Response* Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Kindly send documents that will assist us in resolving these vulnerabilities I think Mark's responses above tell you what you need to know in order to resolve these. Just look in the documentation for the implementation details. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Audit Exceptions on Apache
On Sep 18, 2013, at 9:00 AM, Obba Joy joyo...@yahoo.com wrote: Hello Team, Please don't post the same message to the list twice. This list is made up of volunteers who will respond to your request as they have time. If you need a faster response or more hand holding, please consider purchasing a support contract from one of the many companies that offer this service. Some security issues were raised by our audit team and these issues were forwarded to secur...@apache.org. We got a response from Mark Thomas from the Security team Theses issues are listed below: 1. Banner Disclosure We observed that the GTApplication web server disclosed the Apache Coyote version in its HTTP response. The extracted version is: Apache-Coyote/1.1 Risk This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache. Response Not a vulnerability in Apache Tomcat. Every currently supported version of Apache Tomcat includes that information in the header. All it tells an attacker is that you are running Apache Tomcat. If you really want to change it, a configuration option to do that is available on the connector. Have you looked at the connector docs? https://tomcat.apache.org/tomcat-7.0-doc/config/http.html HINT: Search for the server attribute. 2. The Character Set was not set. The Character set (Charset) was not explicitly set by the server. Risk There is a risk that characters in content are incorrectly interpreted by the server. Lack of charset can cause the browser to guess the encoding type and this could lead to Cross-site Scripting by encoding the payload in encoding types like UTF-7. Response Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat responses without a character encoding as being encoding with ISO-8859-1. Clients that try to guess the charset are in breach of RFC2616. Further that they might do so in an unsafe manner is a security vulnerability in those clients and should be reported to the appropriate vendor. If the vendor(s) of the vulnerable client(s) are unwilling to fix this vulnerability there are multiple ways that it could be mitigated. For example, with a filter that always sets the character set. Again, docs are your friend. https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Add_Default_Character_Set_Filter Dan Kindly send documents that will assist us in resolving these vulnerabilities Kind Regards - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
