content/info/css-security/apache_specific.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Cross Site Scripting Info: Apache Specific</TITLE>
 </HEAD>

 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
 <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#000080" 
       ALINK="#FF0000">
  <DIV ALIGN="CENTER">
   <IMG SRC="../../images/apache_sub.gif" ALT="[APACHE DOCUMENTATION]">
  </DIV>
  <H1 ALIGN="CENTER">Cross Site Scripting Info: Apache Specific</H1>

<H2>Introduction:</H2>

<P>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.

<P>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.

<H2>Issues outstanding:</H2>
<UL>

<LI>Older versions of the <CODE>printenv</CODE> 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.

<LI>Current versions of <CODE>printenv</CODE> and <CODE>test-cgi</CODE>
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 <CODE>printenv</CODE> 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 <CODE>printenv</CODE> and
<CODE>test-cgi</CODE> scripts from your site if this issue impacts
you.

<LI>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.

<LI>A number of Apache modules such as <CODE>mod_status</CODE> 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.

<LI>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.


</UL>

<H2>Fixes from CHANGES file:</H2>
<P>These will be expanded on as time permits.  These patches are available
in the current <A HREF="apache_1.3.11_css_patch.txt">Apache patch</A> 
against Apache 1.3.11.

<PRE>
  *) 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]

</PRE>

</BODY>
</HTML>