www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bill parducci <b...@parducci.net>
Subject mod_proxy/5354: Proxy-Authenticate Issue
Date Tue, 23 Nov 1999 19:25:27 GMT

>Number:         5354
>Category:       mod_proxy
>Synopsis:       Proxy-Authenticate Issue
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Nov 23 11:30:02 PST 1999
>Last-Modified:
>Originator:     bill@parducci.net
>Organization:
apache
>Release:        1.3.9
>Environment:
redhat 6.1
>Description:
i am using apache v1.3.9 as a proxy/cache in an environment where there is an upstream cache.
i have apache configured to point to the upstream cache using ProxyRemote. Everything works
fine as long as authentication is not turned on at the upstream cache. 
                       
if it is, when the browser issues a GET, it is passed to apache, then forwarded by apache
to the upstream cache.  the upstream cache issues a 407 (Proxy-Authenticate: in the header)
back to apache. apache forwards that back to the browser. the browser responds and passes
the authentication back to apache. now the problem: apache strips the authentication response
out of the header and passes the request to the upstream cache (where it reissues a 407 again).

                       
browser:GET --> apache:GET --> upstreamcache:407 --> apache:407 --> browser:GET/Proxy-Authenticate
--> apache:GET/{NO auth info]
--> upstreamcache:407 --> apache...
                       
i have seen a number of posts that discuss similar issues, however they tend to place blame
on the browser which does not make sense in this case since i can see the browser responding
properly in my traces.  obviously there is an issue because the following code snippet says
so! 
                
 reqhdrs_arr = ap_table_elts(r->headers_in);
    reqhdrs = (table_entry *) reqhdrs_arr->elts;
    for (i = 0; i < reqhdrs_arr->nelts; i++) {
        if (reqhdrs[i].key == NULL || reqhdrs[i].val == NULL
        /* Clear out headers not to send */
            || !strcasecmp(reqhdrs[i].key, "Host")      /* Already sent */
            /* XXX: @@@ FIXME: "Proxy-Authorization" should *only* be
             * suppressed if THIS server requested the authentication,
             * not when a frontend proxy requested it!
             */
            || !strcasecmp(reqhdrs[i].key, "Proxy-Authorization"))
            continue;
        ap_bvputs(f, reqhdrs[i].key, ": ", reqhdrs[i].val, CRLF, NULL);
    }


i can get this to work in my current environment, however i am concerned as to what it is
that i will be allowing to happen once i do so. there has to be a reason why the 'quick fix'
was applied above (i assume that code commented with FIXME is a quick fix! :o). i can see
why stripping this information out has value because it is a license to 'spoof' on a shared
ip address, but i am in a closed environment where authentication should (and must) only reside
at the perimeter of the entire network. is it a security issue? a lack of standard? bad juju?


thanks

b
>How-To-Repeat:
just point an apache to a proxy requiring authentication
>Fix:
the 'fix' that we have implemented is to simply pass authentication requests on. this is very
simple, so i am quite sure that there is a reason why you are not allowing this.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <apbugs@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]




Mime
View raw message