problem with cookie domains and mod_proxy, Apache 1.3.27

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2EF21.D1CC46A0
Content-Type: text/plain

I have configured Apache 1.3.27 to operate as a reverse proxy. My proxy runs
on proxybox.schwab.com. I have a content server sitting behind it,
content.schwab.com. I can access the following URL, and it works perfectly:



http://proxybox.schwab.com/content



I get the content that is sitting on content.schwab.com. So all the reverse
proxy stuff is working fine.



Here's my problem. I use a cookie to authenticate people to
proxybox.schwab.com. This cookie has a domain of .proxybox.schwab.com, so it
should only be presented to that specific host. Web servers running on any
other host should not be able to see this cookie. But, I can see the cookie
on content.schwab.com.



It appears that mod_proxy passes all headers, including cookies with very
restrictive domains, to the content servers. Even though the cookie has a
domain set that should prevent it from going to any other servers, it still
gets passed along.



Is there any way to configure mod_proxy so it will stop doing this? Is there
any way to modify mod_proxy to filter a specific cookie from the header
before passing the request to the content server?









--Ken



------------------------------------------------------------ ---

Ken Weiss ken.weiss@schwab.com

Directory Services 415-667-1424 (voice)

Charles Schwab & Co. 415-786-1545 (cell)

SF211MN-10-353 415-667-1797 (fax)

101 Montgomery St.

San Francisco, CA 94104



WARNING: All email sent to this address will be received by the Charles
Schwab & Co., Inc. corporate email system and is subject to archival and
review by someone other than the recipient.




------_=_NextPart_001_01C2EF21.D1CC46A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable




charset=3Dus-ascii">

Re: problem with cookie domains and mod_proxy, Apache 1.3.27

This is a cryptographically signed message in MIME format.

--------------ms010206010907070505070207
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Humm second thought, we are not running the same config, no auth is done
on our reverse proxies, and I personnaly think this is not the place for
auth as reverse proxies should really be transparent.

I guess the actual mod_proxy code will not enable you to fix your
problem. Maybe Apache 2.0 has more features for tweaking headers.

Regards,

Mathias.

Weiss, Ken wrote:
> I have configured Apache 1.3.27 to operate as a reverse proxy. My proxy runs
> on proxybox.schwab.com. I have a content server sitting behind it,
> content.schwab.com. I can access the following URL, and it works perfectly:
>
>
>
> http://proxybox.schwab.com/content
>
>
>
> I get the content that is sitting on content.schwab.com. So all the reverse
> proxy stuff is working fine.
>
>
>
> Here's my problem. I use a cookie to authenticate people to
> proxybox.schwab.com. This cookie has a domain of .proxybox.schwab.com, so it
> should only be presented to that specific host. Web servers running on any
> other host should not be able to see this cookie. But, I can see the cookie
> on content.schwab.com.
>
>
>
> It appears that mod_proxy passes all headers, including cookies with very
> restrictive domains, to the content servers. Even though the cookie has a
> domain set that should prevent it from going to any other servers, it still
> gets passed along.
>
>
>
> Is there any way to configure mod_proxy so it will stop doing this? Is there
> any way to modify mod_proxy to filter a specific cookie from the header
> before passing the request to the content server?
>
>
>
>
>
>
>
>
>
> --Ken
>
>
>
> ------------------------------------------------------------ ---
>
> Ken Weiss ken.weiss@schwab.com
>
> Directory Services 415-667-1424 (voice)
>
> Charles Schwab & Co. 415-786-1545 (cell)
>
> SF211MN-10-353 415-667-1797 (fax)
>
> 101 Montgomery St.
>
> San Francisco, CA 94104
>
>
>
> WARNING: All email sent to this address will be received by the Charles
> Schwab & Co., Inc. corporate email system and is subject to archival and
> review by someone other than the recipient.
>
>
>
>

--
-- Informatique du Credit Mutuel ---- Reseaux et Systemes Distribues
-- 32 rue Mirabeau -- Le Relecq-Kerhuon -- 29808 Brest Cedex 9, FRANCE
-- Tel +33298004653 - Fax +33298284005 - Mail Mathias.Herberts@gicm.fr
-- Key Fingerprint: 8778 D2FD 3B4A 6B33 10AB F503 63D0 ADAE 9112 03E4

--------------ms010206010907070505070207
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIJ5DCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAw gdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG A1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls IFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7S bngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1h pfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYA LQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQF AAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo4 91BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLz WtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCA1AwggK5oAMCAQICAwhKdzANBgkqhkiG9w0B AQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDkx NzA5MzA1MVoX
DTAzMDkxNzA5MzA1MVowaTERMA8GA1UEBBMISGVyYmVydHMxEDAOBgNVBCoT B01hdGhpYXMx
GTAXBgNVBAMTEE1hdGhpYXMgSGVyYmVydHMxJzAlBgkqhkiG9w0BCQEWGE1h dGhpYXMuSGVy
YmVydHNAZ2ljbS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALOMVpaFTv4v
fZKOxPmOIUTMXZEBkN/wjAT8VujS7VXNjiHbBBLCBvq0hEH6K74wDK0UzUbq PmOSK9Gd3oa/
zmc4ac6XTaUjlBsAMO79OGqkzL1bWIKNlbqE5EcpzFPQB7plfym9Mwhq/B4g KB17GiYVYwUm
isHtemj/Ovs1GpBXu45y/GNV/ipSsbDuP0C0KHeQhRsohpdCBOvWFm3LylHU o/BLxMKeGY2z
PjizycjA1AkGJQebiipiz8JVHsRaED6wE+wNj77HDtX792nEBf+OfhTT9Xws jZWLEZEDtG4K
1iRwWmofCel9zjfqlx7NXISJax0dO78YM+xE0o9Y7YMCAwEAAaNYMFYwDgYD VR0PAQH/BAQD
AgP4MBEGCWCGSAGG+EIBAQQEAwIFoDAjBgNVHREEHDAagRhNYXRoaWFzLkhl cmJlcnRzQGdp
Y20uZnIwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBpFVhPi0SZ pma4qXmNigvH
mujHDRB8SKQqmc0HbFJWA18m44RV3RMxGnQdNqOFoXt2T1azUIpQPAxObIpE Vw9+kzO7pQAo
I0HfgyBbrA6Sh1Y8lqpbsRQpP/AJAdFVCRQG2Y3egb2/NCVDD68q3c14xMw2 BQigmfcab55e
XAk9KDCCA1AwggK5oAMCAQICAwhKdzANBgkqhkiG9w0BAQQFADCBkjELMAkG A1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8w DQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDkxNzA5MzA1MVoXDTAz MDkxNzA5MzA1
MVowaTERMA8GA1UEBBMISGVyYmVydHMxEDAOBgNVBCoTB01hdGhpYXMxGTAX BgNVBAMTEE1h
dGhpYXMgSGVyYmVydHMxJzAlBgkqhkiG9w0BCQEWGE1hdGhpYXMuSGVyYmVy dHNAZ2ljbS5m
cjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALOMVpaFTv4vfZKO xPmOIUTMXZEB
kN/wjAT8VujS7VXNjiHbBBLCBvq0hEH6K74wDK0UzUbqPmOSK9Gd3oa/zmc4 ac6XTaUjlBsA
MO79OGqkzL1bWIKNlbqE5EcpzFPQB7plfym9Mwhq/B4gKB17GiYVYwUmisHt emj/Ovs1GpBX
u45y/GNV/ipSsbDuP0C0KHeQhRsohpdCBOvWFm3LylHUo/BLxMKeGY2zPjiz ycjA1AkGJQeb
iipiz8JVHsRaED6wE+wNj77HDtX792nEBf+OfhTT9XwsjZWLEZEDtG4K1iRw WmofCel9zjfq
lx7NXISJax0dO78YM+xE0o9Y7YMCAwEAAaNYMFYwDgYDVR0PAQH/BAQDAgP4 MBEGCWCGSAGG
+EIBAQQEAwIFoDAjBgNVHREEHDAagRhNYXRoaWFzLkhlcmJlcnRzQGdpY20u ZnIwDAYDVR0T
AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBpFVhPi0SZpma4qXmNigvHmujH DRB8SKQqmc0H
bFJWA18m44RV3RMxGnQdNqOFoXt2T1azUIpQPAxObIpEVw9+kzO7pQAoI0Hf gyBbrA6Sh1Y8
lqpbsRQpP/AJAdFVCRQG2Y3egb2/NCVDD68q3c14xMw2BQigmfcab55eXAk9 KDGCA9UwggPR
AgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl MRIwEAYDVQQH
EwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm aWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu MzACAwhKdzAJ
BgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEP
Fw0wMzAzMjEwNzM0MDRaMCMGCSqGSIb3DQEJBDEWBBQlL0Z1iqLHEEqq1oO0 3v4W4cz2BTBS
BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGd MIGaMIGSMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24x
DzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vydmlj ZXMxKDAmBgNV
BAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwhKdzCBrQYL KoZIhvcNAQkQ
AgsxgZ2ggZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu OC4zMAIDCEp3
MA0GCSqGSIb3DQEBAQUABIIBAHwo5MVIqt2G2w8EaOUhvf7Agt6ts7u9TOm5 o+azryO6WuSV
kaVQKvIm+jvmghz8weIUeWucJwJX877wwAe9w9pf0l+PABHXNMecaanRk3lv VQqrMoALk2Sh
khaWiakEgH1S8a7AYEVSyeX2oqWFXTHYtb02QuyGK3aQw+mkEqVg0ivUkgTo Y/1hX9EiaNOx
PlsrenZqqR3YVarLaN0fGby0Xp8ci/P5lF88wge6n1gsHu1A5amgnoYQsUjf 8C4AW7184IKs
wuZJiFMC71jlwPtUZWexnVqxAGE3jPlXf40TYRwoE6wGDkjpKJkPJ5XrJusE jf4XvcwgW1vr
i1r70PcAAAAAAAA=
--------------ms010206010907070505070207--

Re: problem with cookie domains and mod_proxy, Apache 1.3.27

I don't think 2.0 has any specific options for not passing specific cookies through.
I'm not sure how easy it would be. Looking at a tcpdump of port80 traffic, it doesn't
look like the request passes the domain back.

I guess the only way would be for the site admin to explitly block a cookie, but I don't belive
that option exists at the moment, and I can't think of a workaround via rewrite.

Sorry Ken.

ps.. if this is really really big pain for you, we could add a directive to mask cookies
but It would probably end up in the standard 2.0 distribution, not 1.3

--ian


Mathias Herberts wrote:
> Humm second thought, we are not running the same config, no auth is done
>
> on our reverse proxies, and I personnaly think this is not the place for
>
> auth as reverse proxies should really be transparent.
>
> I guess the actual mod_proxy code will not enable you to fix your
> problem. Maybe Apache 2.0 has more features for tweaking headers.
>
> Regards,
>
> Mathias.
>
> Weiss, Ken wrote:
>
>>I have configured Apache 1.3.27 to operate as a reverse proxy. My
>
> proxy runs
>
>>on proxybox.schwab.com. I have a content server sitting behind it,
>>content.schwab.com. I can access the following URL, and it works
>
> perfectly:
>
>>
>>
>>http://proxybox.schwab.com/content
>
>
>
>>
>>
>>I get the content that is sitting on content.schwab.com. So all the
>
> reverse
>
>>proxy stuff is working fine.
>>
>>
>>
>>Here's my problem. I use a cookie to authenticate people to
>>proxybox.schwab.com. This cookie has a domain of .proxybox.schwab.com,
>
> so it
>
>>should only be presented to that specific host. Web servers running on
>
> any
>
>>other host should not be able to see this cookie. But, I can see the
>
> cookie
>
>>on content.schwab.com.
>>
>>
>>
>>It appears that mod_proxy passes all headers, including cookies with
>
> very
>
>>restrictive domains, to the content servers. Even though the cookie
>
> has a
>
>>domain set that should prevent it from going to any other servers, it
>
> still
>
>>gets passed along.
>>
>>
>>
>>Is there any way to configure mod_proxy so it will stop doing this? Is
>
> there
>
>>any way to modify mod_proxy to filter a specific cookie from the
>
> header
>
>>before passing the request to the content server?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>--Ken
>>
>>
>>
>>---------------------------------------------------------- -----
>>
>>Ken Weiss ken.weiss@schwab.com
>>
>>Directory Services 415-667-1424 (voice)
>>
>>Charles Schwab & Co. 415-786-1545 (cell)
>>
>>SF211MN-10-353 415-667-1797 (fax)
>>
>>101 Montgomery St.
>>
>>San Francisco, CA 94104
>>
>>
>>
>>WARNING: All email sent to this address will be received by the
>
> Charles
>
>>Schwab & Co., Inc. corporate email system and is subject to archival
>
> and
>
>>review by someone other than the recipient.
>>
>>
>>
>>
>
>