From: david.karr on
On Jan 19, 12:26 pm, markspace <nos...(a)nowhere.com> wrote:
> 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.

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.
From: Tom Anderson on
On Tue, 19 Jan 2010, markspace wrote:

> 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.

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

--
You have now found yourself trapped in an incomprehensible maze.