How to use JSESSIONID on follow-on request without basic auth?

[david.karr]

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.

 

[david.karr]

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?

 

[Tom Anderson]

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

 

[david.karr]

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.

 

[markspace]

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.

 

[david.karr]

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.

Good thought. After I made all the requests, I checked the
access.log, and the IP values were for the boxes they were sent from,
not from a proxy.

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.

Someone could implement whatever custom security they need, but I'm
just using Java webapp security out of the box. The "hash" as you
call it, is the jsessionid itself.

I've asked a question about this on the WebLogic security forum.
Perhaps I'll get a useful response.

 

[Tom Anderson]

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.

In which case the server could repeat its demand for authentication when
the requests come via proxy B. It means an additional round-trip when that
happens, but that doesn't seem like a huge deal.

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.

If an attacker can get the JSESSIONID, then it would be able to get those
too, no?

Of course, once i start using words like 'attacker', i'm talking about
security, and then, the answer is that the connection should be using
HTTPS. Plain HTTP with authentication is really only a deterrent to idle
troublemakers, not serious villains.

tom