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 16:23 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 21 Jan 2010 17:32
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. |