You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2018/08/22 12:55:35 UTC
Session invalidation
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:image001.jpg@01D39C2C.9DA64510]
www.ascert.com
robw@ascert.com
SA +27 21 300 2028
UK +44 20 7488 3470 ext 5119
Re: Session invalidation
Posted by David Jencks <da...@gmail.com>.
I recall running into approximately the same situation years and years ago, although I can’t remember if it was for portlet applications or in Geronimo for ears with multiple wars with servlets that forwarded from one war to another. I think my conclusion was that the servlet spec was just wrong, and that I implemented something similar to what Felix has here. So, I think it’s quite possible that Felix’s solution is the best possible even if there are conflicts with the servlet spec.
David Jencks
> On Aug 22, 2018, at 7:28 PM, Rob Walker <ro...@ascert.com> wrote:
>
> Carsten
>
> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>
> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>
> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>
> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>
> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>
> We could of course add a higher level wrapper, but that seems to get heavyweight.
>
> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>
> Cheers
>
> --Rob
>
> -----Original Message-----
> From: Rob Walker
> Sent: 22 August 2018 18:49
> To: Carsten Ziegeler <cz...@apache.org>; dev@felix.apache.org
> Subject: RE: Session invalidation
>
> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:59
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
>> What I'm seeing is that I get the same session with the same ID back,
>> and it never gets invalidated. I think it has something to do with the
>> wrapper not invalidating the delegate. In our local code I've patched
>> the wrapper to put the delegate.invalidate() call back, and it seems
>> then to be creating a new session for me (or returning null) -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:33
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> Subject: Re: Session invalidation
>>
>> 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:cziegeler@apache.org]
>>> Sent: 22 August 2018 17:08
>>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>>> 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:image001.jpg@01D39C2C.9DA64510
>>>>
>>>>
>>>>
>>>> www.ascert.com
>>>>
>>>> robw@ascert.com
>>>>
>>>> SA +27 21 300 2028
>>>>
>>>> UK +44 20 7488 3470 ext 5119
>>>>
>>>>
>>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Session invalidation
Posted by Timothy Ward <ti...@apache.org>.
My thought was that by hooking into the Jetty handlers it wouldn’t be necessary to do any work with the session cookie, effectively making the SessionIdManager “OSGi HttpContext aware” so that different contexts create and/or get different sessions back. It’s possible that this isn’t sufficient though.
Tim
> On 23 Aug 2018, at 10:50, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> potentially yes, as mentioned we could do this in the Jetty case.
> However, it might require a little bit more like ensuring that the
> virtual id is correctly used for rewriting urls/managing the session cookie.
>
>
> Regards
>
> Carsten
>
>
> Timothy Ward wrote
>> Would it not be sufficient to generate a virtual session id for each session in the whiteboard? This should be possible by customising the Whiteboard’s SessionIdManager<https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/server/SessionIdManager.html> and SessionCache<http://www.eclipse.org/jetty/javadoc/9.4.6.v20170531/org/eclipse/jetty/server/session/SessionCache.html>. Obviously this won’t help you when you’re running in a nested whiteboard, but it should let you provide separate native Jetty Sessions despite multiplexing.
>>
>> Tim
>>
>> On 23 Aug 2018, at 07:19, Carsten Ziegeler <cz...@apache.org>> wrote:
>>
>> I remember a similar discussion about session handling some time ago,
>> but couldn't find it anymore. I would like to start by describing how it
>> works today.
>>
>> The http implementation is registering a single servlet context in the
>> container (jetty in standalone mode and an app server/servlet engine in
>> bridged mode running as a webapp) and as the container is managing the
>> session, there is only a single session regardless of what the http
>> implementation does.
>>
>> The http implementation generates one or more http contexts which can be
>> seen as child contexts of the container servlet context. There is one
>> for everything registered through the http service and using the http
>> whiteboard you'll have at least one more, but might have a set of
>> additional ones. All these contexts share the single container session.
>> In a bridged scenario the session might even be shared with something
>> running outside of the OSGi container in the app server.
>>
>> Each of these http contexts has its own "local" session which can be
>> created and invalidated. In order to leverage the container session
>> handling, these local sessions make use of the container session. Due to
>> that if you invalidate such a local session, the surrounding container
>> session is not invalidated as this local session has no idea whether
>> anyone else is also using the container session.
>>
>> Before FELIX-5819, there was the assumption that if there is nothing
>> else stored in the container session, the container session can be
>> invalidated. But that's a weak assumption, it is right in most cases but
>> wrong in some others.
>>
>> In the general case I think we can't work around the single container
>> session. We might be able to create more than one session with a Jetty
>> based implementation but not in the bridged case. And having separate
>> sessions per http context poses new problems as this prohibits
>> exchanging information between different http contexts for a session.
>>
>> As a immediate workaround we could add the old behaviour back in again -
>> which invalidates the container session if its empty and make this
>> configurable. That should solve your immediate problem.
>>
>> But to be honest, I'm unsure what the right solution should look like.
>>
>> Regards
>>
>> Carsten
>>
>>
>> Rob Walker wrote
>> Carsten
>>
>> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>>
>> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>>
>> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>>
>> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>>
>> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>>
>> We could of course add a higher level wrapper, but that seems to get heavyweight.
>>
>> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>>
>> Cheers
>>
>> --Rob
>>
>> -----Original Message-----
>> From: Rob Walker
>> Sent: 22 August 2018 18:49
>> To: Carsten Ziegeler <cz...@apache.org>>; dev@felix.apache.org<ma...@felix.apache.org>
>> Subject: RE: Session invalidation
>>
>> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
>> -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:59
>> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
>> Subject: Re: Session invalidation
>>
>> The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
>>
>> Regards
>>
>> Carsten
>>
>>
>> Rob Walker wrote
>> What I'm seeing is that I get the same session with the same ID back,
>> and it never gets invalidated. I think it has something to do with the
>> wrapper not invalidating the delegate. In our local code I've patched
>> the wrapper to put the delegate.invalidate() call back, and it seems
>> then to be creating a new session for me (or returning null) -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:33
>> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
>> Subject: Re: Session invalidation
>>
>> 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:cziegeler@apache.org]
>> Sent: 22 August 2018 17:08
>> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
>> 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:image001.jpg@01D39C2C.9DA64510
>>
>>
>>
>> www.ascert.com
>>
>> robw@ascert.com
>>
>> SA +27 21 300 2028
>>
>> UK +44 20 7488 3470 ext 5119
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org<ma...@apache.org>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org<ma...@apache.org>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org<ma...@apache.org>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org<ma...@apache.org>
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
potentially yes, as mentioned we could do this in the Jetty case.
However, it might require a little bit more like ensuring that the
virtual id is correctly used for rewriting urls/managing the session cookie.
Regards
Carsten
Timothy Ward wrote
> Would it not be sufficient to generate a virtual session id for each session in the whiteboard? This should be possible by customising the Whiteboard’s SessionIdManager<https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/server/SessionIdManager.html> and SessionCache<http://www.eclipse.org/jetty/javadoc/9.4.6.v20170531/org/eclipse/jetty/server/session/SessionCache.html>. Obviously this won’t help you when you’re running in a nested whiteboard, but it should let you provide separate native Jetty Sessions despite multiplexing.
>
> Tim
>
> On 23 Aug 2018, at 07:19, Carsten Ziegeler <cz...@apache.org>> wrote:
>
> I remember a similar discussion about session handling some time ago,
> but couldn't find it anymore. I would like to start by describing how it
> works today.
>
> The http implementation is registering a single servlet context in the
> container (jetty in standalone mode and an app server/servlet engine in
> bridged mode running as a webapp) and as the container is managing the
> session, there is only a single session regardless of what the http
> implementation does.
>
> The http implementation generates one or more http contexts which can be
> seen as child contexts of the container servlet context. There is one
> for everything registered through the http service and using the http
> whiteboard you'll have at least one more, but might have a set of
> additional ones. All these contexts share the single container session.
> In a bridged scenario the session might even be shared with something
> running outside of the OSGi container in the app server.
>
> Each of these http contexts has its own "local" session which can be
> created and invalidated. In order to leverage the container session
> handling, these local sessions make use of the container session. Due to
> that if you invalidate such a local session, the surrounding container
> session is not invalidated as this local session has no idea whether
> anyone else is also using the container session.
>
> Before FELIX-5819, there was the assumption that if there is nothing
> else stored in the container session, the container session can be
> invalidated. But that's a weak assumption, it is right in most cases but
> wrong in some others.
>
> In the general case I think we can't work around the single container
> session. We might be able to create more than one session with a Jetty
> based implementation but not in the bridged case. And having separate
> sessions per http context poses new problems as this prohibits
> exchanging information between different http contexts for a session.
>
> As a immediate workaround we could add the old behaviour back in again -
> which invalidates the container session if its empty and make this
> configurable. That should solve your immediate problem.
>
> But to be honest, I'm unsure what the right solution should look like.
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
> Carsten
>
> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>
> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>
> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>
> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>
> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>
> We could of course add a higher level wrapper, but that seems to get heavyweight.
>
> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>
> Cheers
>
> --Rob
>
> -----Original Message-----
> From: Rob Walker
> Sent: 22 August 2018 18:49
> To: Carsten Ziegeler <cz...@apache.org>>; dev@felix.apache.org<ma...@felix.apache.org>
> Subject: RE: Session invalidation
>
> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:59
> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
> Subject: Re: Session invalidation
>
> The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
> What I'm seeing is that I get the same session with the same ID back,
> and it never gets invalidated. I think it has something to do with the
> wrapper not invalidating the delegate. In our local code I've patched
> the wrapper to put the delegate.invalidate() call back, and it seems
> then to be creating a new session for me (or returning null) -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:33
> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
> Subject: Re: Session invalidation
>
> 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:cziegeler@apache.org]
> Sent: 22 August 2018 17:08
> To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
> 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:image001.jpg@01D39C2C.9DA64510
>
>
>
> www.ascert.com
>
> robw@ascert.com
>
> SA +27 21 300 2028
>
> UK +44 20 7488 3470 ext 5119
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org<ma...@apache.org>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org<ma...@apache.org>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org<ma...@apache.org>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org<ma...@apache.org>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Session invalidation
Posted by Timothy Ward <ti...@apache.org>.
Would it not be sufficient to generate a virtual session id for each session in the whiteboard? This should be possible by customising the Whiteboard’s SessionIdManager<https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/server/SessionIdManager.html> and SessionCache<http://www.eclipse.org/jetty/javadoc/9.4.6.v20170531/org/eclipse/jetty/server/session/SessionCache.html>. Obviously this won’t help you when you’re running in a nested whiteboard, but it should let you provide separate native Jetty Sessions despite multiplexing.
Tim
On 23 Aug 2018, at 07:19, Carsten Ziegeler <cz...@apache.org>> wrote:
I remember a similar discussion about session handling some time ago,
but couldn't find it anymore. I would like to start by describing how it
works today.
The http implementation is registering a single servlet context in the
container (jetty in standalone mode and an app server/servlet engine in
bridged mode running as a webapp) and as the container is managing the
session, there is only a single session regardless of what the http
implementation does.
The http implementation generates one or more http contexts which can be
seen as child contexts of the container servlet context. There is one
for everything registered through the http service and using the http
whiteboard you'll have at least one more, but might have a set of
additional ones. All these contexts share the single container session.
In a bridged scenario the session might even be shared with something
running outside of the OSGi container in the app server.
Each of these http contexts has its own "local" session which can be
created and invalidated. In order to leverage the container session
handling, these local sessions make use of the container session. Due to
that if you invalidate such a local session, the surrounding container
session is not invalidated as this local session has no idea whether
anyone else is also using the container session.
Before FELIX-5819, there was the assumption that if there is nothing
else stored in the container session, the container session can be
invalidated. But that's a weak assumption, it is right in most cases but
wrong in some others.
In the general case I think we can't work around the single container
session. We might be able to create more than one session with a Jetty
based implementation but not in the bridged case. And having separate
sessions per http context poses new problems as this prohibits
exchanging information between different http contexts for a session.
As a immediate workaround we could add the old behaviour back in again -
which invalidates the container session if its empty and make this
configurable. That should solve your immediate problem.
But to be honest, I'm unsure what the right solution should look like.
Regards
Carsten
Rob Walker wrote
Carsten
Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
We could of course add a higher level wrapper, but that seems to get heavyweight.
One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
Cheers
--Rob
-----Original Message-----
From: Rob Walker
Sent: 22 August 2018 18:49
To: Carsten Ziegeler <cz...@apache.org>>; dev@felix.apache.org<ma...@felix.apache.org>
Subject: RE: Session invalidation
I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
-R
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 22 August 2018 17:59
To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
Subject: Re: Session invalidation
The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
Regards
Carsten
Rob Walker wrote
What I'm seeing is that I get the same session with the same ID back,
and it never gets invalidated. I think it has something to do with the
wrapper not invalidating the delegate. In our local code I've patched
the wrapper to put the delegate.invalidate() call back, and it seems
then to be creating a new session for me (or returning null) -R
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 22 August 2018 17:33
To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
Subject: Re: Session invalidation
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:cziegeler@apache.org]
Sent: 22 August 2018 17:08
To: dev@felix.apache.org<ma...@felix.apache.org>; Rob Walker <ro...@ascert.com>>
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:image001.jpg@01D39C2C.9DA64510
www.ascert.com
robw@ascert.com
SA +27 21 300 2028
UK +44 20 7488 3470 ext 5119
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
I remember a similar discussion about session handling some time ago,
but couldn't find it anymore. I would like to start by describing how it
works today.
The http implementation is registering a single servlet context in the
container (jetty in standalone mode and an app server/servlet engine in
bridged mode running as a webapp) and as the container is managing the
session, there is only a single session regardless of what the http
implementation does.
The http implementation generates one or more http contexts which can be
seen as child contexts of the container servlet context. There is one
for everything registered through the http service and using the http
whiteboard you'll have at least one more, but might have a set of
additional ones. All these contexts share the single container session.
In a bridged scenario the session might even be shared with something
running outside of the OSGi container in the app server.
Each of these http contexts has its own "local" session which can be
created and invalidated. In order to leverage the container session
handling, these local sessions make use of the container session. Due to
that if you invalidate such a local session, the surrounding container
session is not invalidated as this local session has no idea whether
anyone else is also using the container session.
Before FELIX-5819, there was the assumption that if there is nothing
else stored in the container session, the container session can be
invalidated. But that's a weak assumption, it is right in most cases but
wrong in some others.
In the general case I think we can't work around the single container
session. We might be able to create more than one session with a Jetty
based implementation but not in the bridged case. And having separate
sessions per http context poses new problems as this prohibits
exchanging information between different http contexts for a session.
As a immediate workaround we could add the old behaviour back in again -
which invalidates the container session if its empty and make this
configurable. That should solve your immediate problem.
But to be honest, I'm unsure what the right solution should look like.
Regards
Carsten
Rob Walker wrote
> Carsten
>
> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>
> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>
> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>
> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>
> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>
> We could of course add a higher level wrapper, but that seems to get heavyweight.
>
> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>
> Cheers
>
> --Rob
>
> -----Original Message-----
> From: Rob Walker
> Sent: 22 August 2018 18:49
> To: Carsten Ziegeler <cz...@apache.org>; dev@felix.apache.org
> Subject: RE: Session invalidation
>
> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:59
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
>> What I'm seeing is that I get the same session with the same ID back,
>> and it never gets invalidated. I think it has something to do with the
>> wrapper not invalidating the delegate. In our local code I've patched
>> the wrapper to put the delegate.invalidate() call back, and it seems
>> then to be creating a new session for me (or returning null) -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:33
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> Subject: Re: Session invalidation
>>
>> 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:cziegeler@apache.org]
>>> Sent: 22 August 2018 17:08
>>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>>> 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:image001.jpg@01D39C2C.9DA64510
>>>>
>>>>
>>>>
>>>> www.ascert.com
>>>>
>>>> robw@ascert.com
>>>>
>>>> SA +27 21 300 2028
>>>>
>>>> UK +44 20 7488 3470 ext 5119
>>>>
>>>>
>>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Session invalidation
Posted by Rob Walker <ro...@ascert.com>.
Yep, from my side I'd fully agree. I can see the existing behaviour is very useful for specific scenarios, and definitely not something that should be devalued.
But on the other hand, the session ID usage it creates is atypical and problematic for many more regular, out of the box usage cases.
Your proposal seems a good balance between these two, so +1 from me
--Rob
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 14 September 2018 08:14
To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
Subject: Re: Session invalidation
Hi Rob,
I think we should do the following:
a) provide a configuration whether the Http Implementation has full control over the session or not. This used to be the case but has been changed in recent versions and is the root of your problem. I think we can even go that far and make this the default. I think sharing the session with web components outside of OSGi is rather the exception.
b) The session wrapper uses the same session id for all internally managed sessions; and i think this is another source of problem. And again before the change the internal sessions had different id.
So with the defaul set as above, we're back to the old behaviour and all internal sessions have different ids. With this even if you have additional components like a cache using the session id, these caches will get invalidated correctly (through session events) and not be reused.
If someone changes the default setting, then still we have different session ids, so it can't happen that data from an old session (through a cache or something like that) reappears in a new session.
WDYT?
Regards
Carsten
Rob Walker wrote
> Carsten
>
> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>
> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>
> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>
> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>
> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>
> We could of course add a higher level wrapper, but that seems to get heavyweight.
>
> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>
> Cheers
>
> --Rob
>
> -----Original Message-----
> From: Rob Walker
> Sent: 22 August 2018 18:49
> To: Carsten Ziegeler <cz...@apache.org>; dev@felix.apache.org
> Subject: RE: Session invalidation
>
> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:59
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> The new session has the same ID (and I'm not trying to imply that this
> is good), but it should be a different session object being empty
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
>> What I'm seeing is that I get the same session with the same ID back,
>> and it never gets invalidated. I think it has something to do with
>> the wrapper not invalidating the delegate. In our local code I've
>> patched the wrapper to put the delegate.invalidate() call back, and
>> it seems then to be creating a new session for me (or returning null)
>> -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:33
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> Subject: Re: Session invalidation
>>
>> 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:cziegeler@apache.org]
>>> Sent: 22 August 2018 17:08
>>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>>> 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:image001.jpg@01D39C2C.9DA64510
>>>>
>>>>
>>>>
>>>> www.ascert.com
>>>>
>>>> robw@ascert.com
>>>>
>>>> SA +27 21 300 2028
>>>>
>>>> UK +44 20 7488 3470 ext 5119
>>>>
>>>>
>>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Rob,
I think we should do the following:
a) provide a configuration whether the Http Implementation has full
control over the session or not. This used to be the case but has been
changed in recent versions and is the root of your problem. I think we
can even go that far and make this the default. I think sharing the
session with web components outside of OSGi is rather the exception.
b) The session wrapper uses the same session id for all internally
managed sessions; and i think this is another source of problem. And
again before the change the internal sessions had different id.
So with the defaul set as above, we're back to the old behaviour and all
internal sessions have different ids. With this even if you have
additional components like a cache using the session id, these caches
will get invalidated correctly (through session events) and not be reused.
If someone changes the default setting, then still we have different
session ids, so it can't happen that data from an old session (through a
cache or something like that) reappears in a new session.
WDYT?
Regards
Carsten
Rob Walker wrote
> Carsten
>
> Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
>
> So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
>
> Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
>
> So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
>
> Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
>
> We could of course add a higher level wrapper, but that seems to get heavyweight.
>
> One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
>
> Cheers
>
> --Rob
>
> -----Original Message-----
> From: Rob Walker
> Sent: 22 August 2018 18:49
> To: Carsten Ziegeler <cz...@apache.org>; dev@felix.apache.org
> Subject: RE: Session invalidation
>
> I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:59
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
>
> Regards
>
> Carsten
>
>
> Rob Walker wrote
>> What I'm seeing is that I get the same session with the same ID back,
>> and it never gets invalidated. I think it has something to do with the
>> wrapper not invalidating the delegate. In our local code I've patched
>> the wrapper to put the delegate.invalidate() call back, and it seems
>> then to be creating a new session for me (or returning null) -R
>>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: 22 August 2018 17:33
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> Subject: Re: Session invalidation
>>
>> 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:cziegeler@apache.org]
>>> Sent: 22 August 2018 17:08
>>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>>> 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:image001.jpg@01D39C2C.9DA64510
>>>>
>>>>
>>>>
>>>> www.ascert.com
>>>>
>>>> robw@ascert.com
>>>>
>>>> SA +27 21 300 2028
>>>>
>>>> UK +44 20 7488 3470 ext 5119
>>>>
>>>>
>>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Session invalidation
Posted by Rob Walker <ro...@ascert.com>.
Carsten
Been pondering this one some more and thrown some notes down below. Caveat to all of them though: I am not so familiar with the recent Felix codebase in this area; and my experience of real-world HTTP security definitely has gaps!
So my take is that some apps (obviously not many as we're the 1st to hit this in 6 months since the change!) would expected a session invalidate() to destroy every aspect of that session. All attributes definitely, and also most would expect the ID to be destroyed and not re-used. I haven't checked the Servlet or HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I could certainly see apps that hold their session information in some external cache not in attributes getting tripped up with narrow timing windows where an old session ID comes in again before a cache is cleared. Bad coding by that app - sure, almost certainly. But also caught out by non-standard behaviour.
Of course it sounds like we have just as many if not more HTTP whiteboard users that would get caught by this changed. I'm not going to argue the current re-use of IDs is wrong, and that we need to refactor since we risk breaking things for these users, and that is just as bad.
So my proposal is (hopefully) a simple one. We add a property that lets users (like us) tripped up by the wrapper behaviour, have the raw Jetty Session object returned rather than the wrapper. That way no Felix code gets in the way of normal Jetty handling for those not using HTTP whiteboard.
Looking at the code, I think there's a very small number of places this would change. Obviously getSession() is one. And then in Dispatcher we'd need to do an instanceof test in dispatch before calling getExpiredSessionContextNames. And I think again something similar in ServiceController.
We could of course add a higher level wrapper, but that seems to get heavyweight.
One added benefit of the above is it allows use of the normal Jetty SecureHandler code which does an automatic session invalidate/renew as part of the auth steps. But this gets torpedoed by the use of the Felix wrapper due to an (admittedly also nasty) instanceof test in the Jetty code.
Cheers
--Rob
-----Original Message-----
From: Rob Walker
Sent: 22 August 2018 18:49
To: Carsten Ziegeler <cz...@apache.org>; dev@felix.apache.org
Subject: RE: Session invalidation
I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
-R
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 22 August 2018 17:59
To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
Subject: Re: Session invalidation
The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
Regards
Carsten
Rob Walker wrote
> What I'm seeing is that I get the same session with the same ID back,
> and it never gets invalidated. I think it has something to do with the
> wrapper not invalidating the delegate. In our local code I've patched
> the wrapper to put the delegate.invalidate() call back, and it seems
> then to be creating a new session for me (or returning null) -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:33
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> 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:cziegeler@apache.org]
>> Sent: 22 August 2018 17:08
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> 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:image001.jpg@01D39C2C.9DA64510
>>>
>>>
>>>
>>> www.ascert.com
>>>
>>> robw@ascert.com
>>>
>>> SA +27 21 300 2028
>>>
>>> UK +44 20 7488 3470 ext 5119
>>>
>>>
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Session invalidation
Posted by Rob Walker <ro...@ascert.com>.
I didn’t check for that, will take a look. The duplicate ID was what I noticed, and one of the things tripping me up.
-R
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 22 August 2018 17:59
To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
Subject: Re: Session invalidation
The new session has the same ID (and I'm not trying to imply that this is good), but it should be a different session object being empty
Regards
Carsten
Rob Walker wrote
> What I'm seeing is that I get the same session with the same ID back,
> and it never gets invalidated. I think it has something to do with the
> wrapper not invalidating the delegate. In our local code I've patched
> the wrapper to put the delegate.invalidate() call back, and it seems
> then to be creating a new session for me (or returning null) -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:33
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> 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:cziegeler@apache.org]
>> Sent: 22 August 2018 17:08
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> 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:image001.jpg@01D39C2C.9DA64510
>>>
>>>
>>>
>>> www.ascert.com
>>>
>>> robw@ascert.com
>>>
>>> SA +27 21 300 2028
>>>
>>> UK +44 20 7488 3470 ext 5119
>>>
>>>
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
The new session has the same ID (and I'm not trying to imply that this
is good), but it should be a different session object being empty
Regards
Carsten
Rob Walker wrote
> What I'm seeing is that I get the same session with the same ID back, and it never gets invalidated. I think it has something to do with the wrapper not invalidating the delegate. In our local code I've patched the wrapper to put the delegate.invalidate() call back, and it seems then to be creating a new session for me (or returning null)
> -R
>
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: 22 August 2018 17:33
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> Subject: Re: Session invalidation
>
> 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:cziegeler@apache.org]
>> Sent: 22 August 2018 17:08
>> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
>> 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:image001.jpg@01D39C2C.9DA64510
>>>
>>>
>>>
>>> www.ascert.com
>>>
>>> robw@ascert.com
>>>
>>> SA +27 21 300 2028
>>>
>>> UK +44 20 7488 3470 ext 5119
>>>
>>>
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Session invalidation
Posted by Rob Walker <ro...@ascert.com>.
What I'm seeing is that I get the same session with the same ID back, and it never gets invalidated. I think it has something to do with the wrapper not invalidating the delegate. In our local code I've patched the wrapper to put the delegate.invalidate() call back, and it seems then to be creating a new session for me (or returning null)
-R
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@apache.org]
Sent: 22 August 2018 17:33
To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
Subject: Re: Session invalidation
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:cziegeler@apache.org]
> Sent: 22 August 2018 17:08
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> 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:image001.jpg@01D39C2C.9DA64510
>>
>>
>>
>> www.ascert.com
>>
>> robw@ascert.com
>>
>> SA +27 21 300 2028
>>
>> UK +44 20 7488 3470 ext 5119
>>
>>
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
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:cziegeler@apache.org]
> Sent: 22 August 2018 17:08
> To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
> 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:image001.jpg@01D39C2C.9DA64510
>>
>>
>>
>> www.ascert.com
>>
>> robw@ascert.com
>>
>> SA +27 21 300 2028
>>
>> UK +44 20 7488 3470 ext 5119
>>
>>
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Session invalidation
Posted by Rob Walker <ro...@ascert.com>.
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:cziegeler@apache.org]
Sent: 22 August 2018 17:08
To: dev@felix.apache.org; Rob Walker <ro...@ascert.com>
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:image001.jpg@01D39C2C.9DA64510
>
>
>
> www.ascert.com
>
> robw@ascert.com
>
> SA +27 21 300 2028
>
> UK +44 20 7488 3470 ext 5119
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Session invalidation
Posted by Carsten Ziegeler <cz...@apache.org>.
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:image001.jpg@01D39C2C.9DA64510
>
>
>
> www.ascert.com
>
> robw@ascert.com
>
> SA +27 21 300 2028
>
> UK +44 20 7488 3470 ext 5119
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org