Hmm, maybe I'm missing something here, so you call getSession().invalidate(). This should invalidate this session and clear all attributes.
If another request comes in using the same session id, a getSession(false) should return null. A getSession() should return a new session which is empty. So this should follow the servlet API contract. Or do you experience different results here? Regards Carsten Rob Walker wrote > 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] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
