How to use JSESSIONID on follow-on request without basic auth?
in [Java Help]
|
Prev: Best way to limit max number of characters per line in JEditorPane ?
Next: Inconsistent whether new browser window opens from signed applet
From: david.karr on 19 Jan 2010 11:36 I'm trying to understand some details under the covers of basic auth and the use of JSESSIONID in webapp security. On an initial request, I can send an HTTP request with an Authorization header containing the basic auth encoded value. The server sends back a response along with the JSESSIONID cookie. Now that I have the JSESSIONID cookie on the client side, is it possible to form a (successful) secondary request that does not have the Authorization header, using the JSESSIONID value? Secondly, is it possible for that secondary request to come from a different IP than the initial request? I doubt this can work like this, but I'm envisioning a collaboration between the client and server portion of a webapp where the server portion sends an HTTP request to a third-party server, sending the Authorization header, which gets back a JSESSIONID value. This value is rendered to the browser and used in subsequent requests from Javascript. If this can work, it allows the Javascript to be rendered with just a transient session id, instead of the basic auth credentials. I could specify the implementation of a web proxy on the server side of the "client" webapp, but that wouldn't be as efficient or scalable.
From: david.karr on 19 Jan 2010 12:15 On Jan 19, 8:36 am, "david.karr" <davidmichaelk...(a)gmail.com> wrote: > I'm trying to understand some details under the covers of basic auth > and the use of JSESSIONID in webapp security. > > On an initial request, I can send an HTTP request with an > Authorization header containing the basic auth encoded value. The > server sends back a response along with the JSESSIONID cookie. > > Now that I have the JSESSIONID cookie on the client side, is it > possible to form a (successful) secondary request that does not have > the Authorization header, using the JSESSIONID value? > > Secondly, is it possible for that secondary request to come from a > different IP than the initial request? > > I doubt this can work like this, but I'm envisioning a collaboration > between the client and server portion of a webapp where the server > portion sends an HTTP request to a third-party server, sending the > Authorization header, which gets back a JSESSIONID value. This value > is rendered to the browser and used in subsequent requests from > Javascript. > > If this can work, it allows the Javascript to be rendered with just a > transient session id, instead of the basic auth credentials. > > I could specify the implementation of a web proxy on the server side > of the "client" webapp, but that wouldn't be as efficient or scalable. Ok, I think I figured this out. Taking the cookie value and adding ";jsessionid=$value" to the URL will work. I verified that I can make that secondary request from a different host than the initial authenticated request, so I think this will work. Anyone disagree?
From: Tom Anderson on 19 Jan 2010 12:50 On Tue, 19 Jan 2010, david.karr wrote: > On Jan 19, 8:36�am, "david.karr" <davidmichaelk...(a)gmail.com> wrote: >> I'm trying to understand some details under the covers of basic auth >> and the use of JSESSIONID in webapp security. >> >> On an initial request, I can send an HTTP request with an >> Authorization header containing the basic auth encoded value. �The >> server sends back a response along with the JSESSIONID cookie. >> >> Now that I have the JSESSIONID cookie on the client side, is it >> possible to form a (successful) secondary request that does not have >> the Authorization header, using the JSESSIONID value? >> >> Secondly, is it possible for that secondary request to come from a >> different IP than the initial request? > > Ok, I think I figured this out. Taking the cookie value and adding > ";jsessionid=$value" to the URL will work. I verified that I can make > that secondary request from a different host than the initial > authenticated request, so I think this will work. > > Anyone disagree? I'm surprised it works. Disappointed, even - that doesn't seem very secure. I suspect it may be implementation-dependent - what's the server that is being fed the session IDs? tom -- There is a faster way to find out...
From: david.karr on 19 Jan 2010 13:02 On Jan 19, 9:50 am, Tom Anderson <t...(a)urchin.earth.li> wrote: > On Tue, 19 Jan 2010, david.karr wrote: > > On Jan 19, 8:36 am, "david.karr" <davidmichaelk...(a)gmail.com> wrote: > >> I'm trying to understand some details under the covers of basic auth > >> and the use of JSESSIONID in webapp security. > > >> On an initial request, I can send an HTTP request with an > >> Authorization header containing the basic auth encoded value. The > >> server sends back a response along with the JSESSIONID cookie. > > >> Now that I have the JSESSIONID cookie on the client side, is it > >> possible to form a (successful) secondary request that does not have > >> the Authorization header, using the JSESSIONID value? > > >> Secondly, is it possible for that secondary request to come from a > >> different IP than the initial request? > > > Ok, I think I figured this out. Taking the cookie value and adding > > ";jsessionid=$value" to the URL will work. I verified that I can make > > that secondary request from a different host than the initial > > authenticated request, so I think this will work. > > > Anyone disagree? > > I'm surprised it works. Disappointed, even - that doesn't seem very > secure. I suspect it may be implementation-dependent - what's the server > that is being fed the session IDs? WebLogic 10.3.2. I'd appreciate it if someone could try this scenario on a different container and see if it behaves differently. If there's a specification statement to this effect somewhere, that would be even better.
From: markspace on 19 Jan 2010 15:26
Tom Anderson wrote: > I'm surprised it works. Disappointed, even - that doesn't seem very > secure. I suspect it may be implementation-dependent - what's the server > that is being fed the session IDs? If a client is behind a proxy, then normal HTTP requests could be seen coming from different IP addresses. In other words, one request could be routed through proxy A, then the next request could see proxy A under higher load, and be routed through proxy B. Both proxy A and proxy B should have different IP addresses. I'm not sure what kind of vulnerabilities this introduces. Hopefully security depends on more state than just the jsession ID. One should have a hash or unique ID set in the cookie, I think. |