Cross Site Scripting Info: Apache Specific

Introduction:

While reviewing the Apache code for any problems related to this problem, we have discovered a number of issues. Many of them are not bugs in Apache, but are places where Apache can do more to avoid being vulnerable to the Cross Site Scripting security problem. None of the changes fix any security holes in Apache itself that can compromise the server directly, but are focused towards its interaction with clients.

Included below is a summary of the current known issues and fixes, where available. This information will be expanded on as information becomes available and time permits.

Issues outstanding:

• Older versions of the printenv CGI script distributed with Apache did not properly encode their output. If you have one of these on your system, and this issue impacts your site, you should disable the CGI.
• Current versions of printenv and test-cgi send content with a MIME type of text/plain, meaning that no encoding is required or possible. This was changed effective in Apache 1.3.11 to fix the problem of printenv not properly encoding its output. Unfortunately, Microsoft Internet Explorer does not respect that MIME type, and incorrectly processes the output as HTML that is what it guesses it to be. This security problem has been reported to Microsoft. At this time, the recommended workaround is to simply remove the printenv and test-cgi scripts from your site if this issue impacts you.
• If you do have other legitimate text/plain content on your site that is generated based on user input, you may need to configure your server to prevent IE from accessing it or change it to text/html so you can encode it. Alternatively, you can filter special characters if that is possible in your situation. Thankfully, this only impacts a very few sites.
• A number of Apache modules such as mod_status do not set an explicit character set on their output. Using the AddDefaultCharset directive will work around this. The modules that don't set an explicit character set are not normally accessible to users and they are not thought to pose a significant risk.
• What is necessary to ensure that sites that legitimately use character sets with different encodings of special characters, such as UTF-7, are protected. How can Apache facilitate this? This is a major issue for those with a significant amount of content in character sets other than iso-8859-1.

Fixes from CHANGES file:

These will be expanded on as time permits. These patches are available in the current Apache patch against Apache 1.3.11.

  *) Add an explicit charset=iso-8859-1 to pages generated by
     ap_send_error_response(), such as the default 404 page.
     [Marc Slemko]

  *) Add the AddDefaultCharset and AddDefaultCharsetName directives.
     These allow you to tell Apache to specify the given character
     set on any document that does not have one explicitly specified in
     the headers.  [Marc Slemko]

  *) Properly escape various messages output to the client from a number
     of modules and places in the core code.  [Marc Slemko]

  *) Change mod_actions, mod_autoindex, mod_expires, and mod_log_config to
     not consider any parameters such as charset when making decisions
     based on content type.  This does remove some functionality for
     some users, but means that when these modules are configured to do
     particular things with particular MIME types, the charset should
     not be included.  A better way of addressing this for users who
     want to set things on a per charset basis is necessary in the future.
     [Marc Slemko]

  *) mod_include now entity encodes output from "printenv" and "echo var"
     by default.  The encoding for "echo var" can be set to URL encoding
     or no encoding using the new "encoding" attribute to the echo tag.
     [Marc Slemko]