Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of solprovider@gmail.com
 designates 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=UrbheiRFVcwyElsF74c/XIESp5aTI6VfJyXbkQoQhjdW6SF5P5QMSa4FNlXBvfsVoj
         8tBj1+aEzjnuBvCq4/714Bd+meY8iYJR84wC6sehmzg6NQ//xZyk+39LL4ggZVTgEype
         s0YwE3Lc5ulYJmxI9LcrSYKSfSy9XLLJO8H1k=
Message-ID: <dfe834320807191913o8260f9agf2088d74927cba8@mail.gmail.com>
Date: Sat, 19 Jul 2008 22:13:42 -0400
From: solprovider@apache.org
Sender: solprovider@gmail.com
To: users@httpd.apache.org
In-Reply-To: <b9ff57f30807191255w6a1522d1ta647b403e3acf25d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <b9ff57f30807170354h35442bday7dd5256d76065b75@mail.gmail.com>
	 <dfe834320807170820l65e3b74fs6ec34bc2b699d1c1@mail.gmail.com>
	 <488050F8.6050505@ice-sa.com>
	 <dfe834320807180532o1efc5156x4673474566b2c547@mail.gmail.com>
	 <b9ff57f30807190555h79ff21fat1451a89d2951963c@mail.gmail.com>
	 <48820198.5040901@ice-sa.com>
	 <dfe834320807191049p5ab63488i899d48bd7632ff77@mail.gmail.com>
	 <b9ff57f30807191255w6a1522d1ta647b403e3acf25d@mail.gmail.com>
Subject: Re: [users@httpd] Setting cookies from proxied backend

On 7/19/08, jamanbo jamanbo <jamanbo@googlemail.com> wrote:
> > If the applications use Cookies, the
>  > application Cookies must be rewritten by the Web proxy server because
>  > the browsers use the server name of the Web proxy server, not the
>  > application servers.
>  > 1. The browser requests http://myapp.example.com.
>  > 2. The Web proxy server myapp.example.com sends the request to
>  > myInternalApplicationServer.example.org.
>  > 3. The myInternalApplicationServer.example.org sends a response with a
>  > Cookie for myInternalApplicationServer.example.org to the Web proxy
>  > server.
>  > 4. The Web proxy server changes the Cookie from
>  > myInternalApplicationServer.example.org to myapp.example.com.
>  > 5. The browser receives the Cookie for myapp.example.com and send the
>  > Cookie with future requests to the Web proxy server.
>  > 6. The Web proxy server sends the incoming Cookies with the request to
>  > the application server as in #2.  (Depending on security, the incoming
>  > Cookies may need to be changed to match the receiving server.)
>  > 7. GOTO #3.
>
> This is how I have come to understand the process too.
>
>  It is step 4 I would like to change though. In my case I need cookies
>  to continue to be set for .example.ORG and not modify them to
>  .example.COM. Whilst there seems to be no difficulty in doing this in
>  Apache (you simply omit the ProxyPassReverseCookieDomain), I am
>  thinking that it amounts to a cross domain cookie injection "attack"
>  and that no half-decent browser would accept the cookies.
>
>  What I have been asking for most of this last week is whether or not
>  it is possible for me to visit a site via a proxy yet continue to have
>  cookies set as though I had visited the site directly. Those who said
>  "yes you can" also generally said something like "thats the way
>  proxies work". I just want to make absolutely certain that this was
>  just a misunderstanding and that what they were really saying was that
>  the cookies can be set, but only by translating them into the proxy
>  domain ... otherwise I have made some rash claims about how I was
>  going to prove a concept of mine rapidly by using a proxy, and will
>  have to make an embarrassing climb down in work on Monday :S

I think you understand.  Browsers should discard Cookies not from the
originating server, i.e. example.com cannot set Cookies for
example.org.  Servers can only set Cookies for themselves and higher
domains containing at least a prefixed and one internal dot
".example.com".  (This is dangerous when the domain is ".com.us" or
some other country codes when two levels does not determine
ownership.)

There are workarounds when you control both domains.  Single-sign-on
solutions often redirect several times using different URLs to set
Cookies for multiple domains.  The process might be:
1. Send login information to first domain.
2. First domain's login redirects browser to master domain.
3. Master domain checks for Cookie from master domain.  If master
domain Cookie is not found, create session and Cookie.
4. Redirect to first domain with session ID in URL.
5. First domain checks with master domain that session is valid.
6. First domain sets Cookie based on new URL
Step 5 in this process requires the first domain is able to verify the
master domain session using a backend process.  The first domain can
maintain its session independent of the master session after this
process completes once.  Again, this requires that either you control
both domains or the master domain provides an API for single-sign-on.
This probably does not apply to your situation.

Using a Web "reverse" proxy, the answer is that creating a Cookie for
amazon.com requires the browser to receive a page from a server named
*.amazon.com.  Using something similar to a cross-site attack could
handle this (e.g. opening www.amazon.com in a frame), but is highly
discouraged.

If you want people on an internal network to be able to access
amazon.com and receive Cookies from amazon.com, a Web reverse proxy is
not the solution.  The two solutions are:
- A forward proxy could be used.  This requires clients to be
configured to use the forward proxy.
- Any NAT firewall should handle this transparently. No client
configuration is necessary; just configure routing between networks to
use the NAT firewall as the gateway..

Apache httpd can handle both forward and reverse proxying, but is not
a NAT firewall.  Standard *nix software (e.g. iptables and PF) can be
NAT firewalls.  (Using Microsoft software for networking may be a
criminal offense and should lead to a justified termination.)

solprovider

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org