httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 51543] New: Space in username not properly escaped in log files (%u)
Date Fri, 22 Jul 2011 19:43:16 GMT

             Bug #: 51543
           Summary: Space in username not properly escaped in log files
           Product: Apache httpd-2
           Version: 2.2.3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
    Classification: Unclassified

Spaces, if any, in a username are not being properly escaped when they are
written to logs (as part of %u). The normal logs use space as a delimiter
between field, so have an unescaped space screws up all log processing for
anything involving usernames (%u) with spaces.

This is ESPECIALLY a problem for user SSL certificates, because organizations
(O=) typically include a space character, e.g., "U.S. Government".  Even the
Apache docs show an organization "O=" with a space in:  Thus, if usernames are
actually user SSL certificates, then anyone with an organization having a space
in it (including U.S. Government") will have a corrupted log entry.

Note that the DEFAULT log format includes %u.

This is NOT the same as bug 28117, because this involves whitespace not

Here's an example of the format I see in the log files: "-" /C=US/O=U.S.
[22/Jul/2011:14:56:50 -0400] "GET /somestuff HTTP/1.1" 200 4319
Notice that "U.S. Government" has an embedded space.  But a leading "/" doesn't
tell anyone where it begins or ends.

I don't know which escape mechanism is the right one for usernames.  I can
imagine %20 working.  Alternatively, surround it with double-quotes if there's
an embedded space, and escape double-quote as a pair of double-quotes inside
that.  The key is to pick one.

I have confirmed that this happens in httpd version 2.2.3 of CentOS version
5.6.  I don't know for sure if it happens in later versions, though I suspect
it does.  However, I'm seeing this in a production system, and I don't have the
luxury of upgrading to latest version of Apache.  I originally found this
problem when trying to parse a log using the Apachelog Python library at but I don't think the library
is at fault here.


Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message