This content has been marked as final.
Show 6 replies
-
1. Re: moving SecurityAspect to be an interceptor
timfox Feb 7, 2008 6:28 AM (in response to ataylor)That would be exploitable since a rogue client could just send (guess) someone else's user id.
Instead you could maintain a map of packet target id to user id in the server side filter and use that. -
2. Re: moving SecurityAspect to be an interceptor
ataylor Feb 7, 2008 6:34 AM (in response to ataylor)That would be exploitable since a rogue client could just send (guess) someone else's user id.
Is that different from how the createconnectionrequest works now.Instead you could maintain a map of packet target id to user id in the server side filter and use that.
That was my first solution but the interceptors wouldnt get called if the connection was removed by the server and we would end up with an ever growing map. -
3. Re: moving SecurityAspect to be an interceptor
timfox Feb 7, 2008 6:38 AM (in response to ataylor)"ataylor" wrote:
That would be exploitable since a rogue client could just send (guess) someone else's user id.
Is that different from how the createconnectionrequest works now.
Yes.
Creat connection request takes a user id, *and* a password. The password is hard to guess.
If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point. -
4. Re: moving SecurityAspect to be an interceptor
ataylor Feb 7, 2008 7:26 AM (in response to ataylor)Yes. Creat connection request takes a user id, *and* a password. The password is hard to guess. If you authenticate and then allow the same user id to be used in subsequent operations without a password, then that's exploitable, since authentication is already done by that point.
of course!Instead you could maintain a map of packet target id to user id in the server side filter and use th
at.
Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map. -
5. Re: moving SecurityAspect to be an interceptor
timfox Feb 7, 2008 7:30 AM (in response to ataylor)"ataylor" wrote:
Ok, so adding and removing the users from the map on creating a connection and closing a connection is fine. If the server closes the connection via the connection manager on client fail, the interceptor wouldn't get called and the user would remain in the map.
Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO. -
6. Re: moving SecurityAspect to be an interceptor
ataylor Feb 7, 2008 7:35 AM (in response to ataylor)Good point. When I think about it, I don't really see what's wrong with having the username/password on the ServerConnectionEndpoint. After all they're just attributes, as long as the security logic itself is not there but in the interceptor then that should be ok IMHO.
Can you clarify! I'm not sure i follow, the interceptor has no access to the ServerConnectionEndpoint.