Well for the short term, I've just copied the source for HttpSessionWrapper into our gradle re-bundling script, and just added back in the delegate.invalidate() call at the end. So at least for now, we've got a local solution that lets us deal with this.
I'm afraid I'm not sure what the proper / general solution is. It would seem to me though that the current code doesn't honour the Servlet contact i.e. getSession().invalidate() does not invalidate the underlying HTTP session. I'm not sure I fully understood the issue with the http whiteboard as it's not a service we use. But it feels like in order to allow that to work, we are actually breaking an underlying fundamental operation of HTTP servlets. That feels kinda wrong to me, since it could break all sorts of usage. In our case, it allows session hijacking by cloning the session ID from the cookie or URL parameter. That's a pretty nasty security breach, and one that possibly could hit others who are relying on session invalidate to clear tokens. Anyhow, enough from me, wanted to highlight the issue at least -Rob -----Original Message----- From: Carsten Ziegeler [mailto:[email protected]] Sent: 22 August 2018 17:08 To: [email protected]; Rob Walker <[email protected]> Subject: Re: Session invalidation This is a problem of the http whiteboard wrt to session handling. For each context managed by the whiteboard you get a separate session. These sessions are managed in the real http session. Now I assume you invalidate one of the per context managed sessions. This does not invalidate the real http session as the http whiteboard implementation does not know whether anything else still wants to use it. Imagine you have another application running which happens to use the same http session - and that app is not managed by the whiteboard. The basic idea is that the real session times out eventually. I'm not sure what a good way of invalidating the http session in this case is :( Regards Carsten Rob Walker wrote > So one more from me today - I'm a little perplexed on session invalidation. > > > > In common with general security best practice on HTTP, we invalidate > the session ID obtained during initial logon and create a new one for > the auth'd and logged on user. This helps prevent session sniffing and > spoofing because the initial session ID can become visible and disclosed. > > > > While updating to newer Felix HTTP Jetty the session ID never seems to > get invalidated. We always seem to get the same ID back even after we > try and invalidate > > > > Digging into the code of HttpSessionWrapper shows that the Jetty > delegate invalidate never gets called. > > > > Here's where it gets weird though. It looks like a mod was committed > by Carsten on 29/3/2018 to explicitly remove the delegate invalidate > quiet recently > > > > SHA-1: f86428f2689e62aafe750d1905fff4f5136ab67e > > > > ** FELIX-5819 : Container session should not be invalidated* > > > > git-svn-id: https://svn.apache.org/repos/asf/felix/trunk@1827956 > 13f79535-47bb-0310-9956-ffa450edef68 > > > > > > At which point I get thoroughly confused! Clearly there must be > something I'm missing > > > > ---- > > Rob Walker > > > > cid:[email protected] > > > > www.ascert.com > > [email protected] > > SA +27 21 300 2028 > > UK +44 20 7488 3470 ext 5119 > > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
