disclosure of IP address in cookie

Manuel Haim haim at hrz.uni-marburg.de
Mon Jul 8 09:47:23 EDT 2013


Hi,

by the way: Why don't you use proxy_ajp but proxy_http ? I guess that
would circumvent the proxy address problem.


However, when behind an http proxy (like Apache or Pound), you need to
insert an "org.apache.catalina.valves.RemoteIpValve" in Tomcat's
server.xml right before the closing </Host> or </Engine> node like this:

<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="aaa.bbb.ccc.ddd"/>

...where aaa.bbb.ccc.ddd is the IP address of your proxy machine.

Additionally you might need to configure an
"org.apache.catalina.valves.SSLValve" (remember that port 8443 answers
SOAP requests and must pass the client certificate to the IdP). This
should work with Apache http proxy (not for Pound as it uses different
http headers, i.e. for Pound you have to write one yourself, ask me if
you need it).

-Manuel


Am 08.07.2013 15:07, schrieb Gruber Bernhard SAI sIT:
> Sorry for the confusion about the cookie name.
> There must be a spelling error in the report I received.
> I checked with  the system that was tested.
> The name of the cookie is "_idp_session".
> I do not use any special plugins.
> 
> I would agree that it might be intended to include the user agents IP address here.
> But in our environment it includes the IP address of the reverse proxy (apache httpd with mod-proxy) in front of tomcat server.
> 
> I the source code I see that the IP address is determined by "httpRequest.getRemoteAddr()",
> which according to my experiences, returns the IP address of the last proxy. 
> I found no attempt to evaluate any X-Forwarded-For headers.
> 
> The same is true for the IP addresses in the SAML-Assertion.
> They refer to our reverse proxy instead of the client IP.
> But  I did not find a way to exclude them from the Assertion.
>  
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] Im Auftrag von Peter Schober
> Gesendet: Freitag, 05. Juli 2013 12:16
> An: users at shibboleth.net
> Betreff: Re: disclosure of IP address in cookie [ccs][bayes][heur]
> 
> * Gruber Bernhard SAI sIT <Bernhard.Gruber at s-itsolutions.at> [2013-07-05 11:40]:
>> During a security test of our shibboleth base solution, the
>> following issue was reported to us:
> 
> This mailing list not the proper way to report (percieved) security issues:
> 
>   "If you [...] would like to report a potentially security sensitive
>    issue with one of the products, please use the form below or send an
>    email to contact at shibboleth.net.
>    http://shibboleth.net/about/contact.html
> 
>> The iDP component discloses an internal IP address in the value of
>> the _idp_lc_session cookie. The truncated and base64 decoded value
>> of the cookie is as follows.
> 
> I can't find the string "_idp_lc_session" (or "_idp_lc_") in the IdP's
> source code, so unless I'm looking at the wrong code (very well
> possible) an unmodified IdP does not set a cookie with that name.
> 
>> 127.0.0.1|<sessionID>
> 
> IDP_SESSION_COOKIE_NAME (defaulting to "_idp_session") has a somewhat
> similar format, and does include the HTTP User Agent's own IP address.
> 
> Personal note (IMHO): I somehow doubt an attacker needs that cookie
> only to find out a client's IP address. S/he either attacks the client
> or the network the client is on, in which case the client's IP address
> will be apparent, or attacks the IdP (or the network the IdP is on),
> where the client's IP address is known as well, without decoding HTTP
> Cookie values.
> Also note that that same IP address will be written into the
> SubjectConfirmation/SubjectConfirmationData/@Address attribute in an
> authentication assertion, which will be given out to relying parties.
> -peter
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 



More information about the users mailing list