httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 11998] New: - mod_usertrack spot_cookie() will not allow Apache to set a new cookie whose name is a substring of an existing cookie
Date Fri, 23 Aug 2002 22:28:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11998>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11998

mod_usertrack spot_cookie() will not allow Apache to set a new cookie whose name is a substring
of an existing cookie 

           Summary: mod_usertrack spot_cookie() will not allow Apache to set
                    a new cookie whose name is a substring of an existing
                    cookie
           Product: Apache httpd-1.3
           Version: 1.3.26
          Platform: All
               URL: http://www.cisco.com
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Other mods
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: msweiger@cisco.com


The function spot_cookie() in mod_usertrack does not allow Apache to set a new 
cookie that is a substring of another, already existent cookie.  The code that 
does the checking to see if the Apache cookie has previously been set is 
wrong.  Suppose the following directives are set:

CookieTracking on
CookieDomain .cisco.com
CookieName cpc
CookieExpires "25 years"

Suppose that another application has previously created a persistent cookie 
called "cpc3".  cpc3 will come across in the http Cookie: header string and the 
spot cookie code will fail as follows:

The code calls the C library strstr function 

strstr("cpc3=2039839", "cpc")

which finds the new cookie "cpc" string as a substring match on the first three 
characters of "cpc3".  This code wrongly assumes that we have found the cookie 
because it fails to check whether the next character in the string is an "=".  
Instead it just assumes it is and skips the next character, in this case "3", 
and uses the remainder of the cookie string as the value field, which is also 
wrong because in this case it has a leading "=".  I have verified the above 
scenario here at Cisco on a fresh install of Apache 1.3.26 and this is clearly 
a major bug.  In general, Apache will silently fail to set cookies if the 
cookie being set is a substring of an existing persistent cookie. 

The code for spot_cookie is included below:

static int spot_cookie(request_rec *r)
{
    cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config,
						&usertrack_module);
    const char *cookie;
    char *value;

    if (!dcfg->enabled) {
        return DECLINED;
    }

    if ((cookie = ap_table_get(r->headers_in, "Cookie")))
        if ((value = strstr(cookie, dcfg->cookie_name))) {
            char *cookiebuf, *cookieend;

            value += strlen(dcfg->cookie_name) + 1;  /* Skip over the '=' */
            cookiebuf = ap_pstrdup(r->pool, value);
            cookieend = strchr(cookiebuf, ';');
            if (cookieend)
                *cookieend = '\0';      /* Ignore anything after a ; */

            /* Set the cookie in a note, for logging */
            ap_table_setn(r->notes, "cookie", cookiebuf);

            return DECLINED;    /* There's already a cookie, no new one */
        }
    make_cookie(r);
    return OK;                  /* We set our cookie */
}

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message