Security Question about Object Ids

[kwaclaw]

I recently had our new Security Architect review Ice, as I had proposed it for certain scenarios in our Architecture Blueprint.

He seems to have just one concern, and that is about protection of object ids (he calls them session ids, based on his past experience with servlets). Mainly, the concern is about hijacking someone else's object by somehow guessing or intercepting (internal attack) the object id.

I could not really answer his concerns other than stating that Ice has utilities to auto-create GUID-type object ids, if the programmer uses them. As to how to avoid internal attacks I could not answer him.

[matthew]

Object ids are not session ids, and should not be compared. With respect to securing object ids, you can no more secure your server via object ids, than you can secure your website with a URL. It would be akin to securing your house through your address, or the number on your door. Just as you secure your house with locks and alarms, you secure your distributed communications with encryption and authentication.

That being said, Glacier2 does in fact have some object id protection built right in. It is not a substitute for encryption and authentication, but it is additional protection for your server back end. Please see section 39.5 of the Ice manual for more information on router security. In particular, the category filtering can be of use, if you've architected your application to take advantage of it. If you need more information on how this all works, please ask.

[kwaclaw]

Object ids are not session ids, and should not be compared.

What would you consider the equivalent in Ice for a session?

From a conceptual point of view a session just represents client-specific (conversational) state on the server, so I thought a set of stateful Ice objects associated with a specific client would represent the same concept, though implemented differently.

With respect to securing object ids, you can no more secure your server via object ids, than you can secure your website with a URL. It would be akin to securing your house through your address, or the number on your door. Just as you secure your house with locks and alarms, you secure your distributed communications with encryption and authentication.

I think my attempt to communicate our architect's concerns is not well-phrased. I am doing this on his behalf, as he showed not much interest spending time on your web site. Let me try again:

I know that well-known objects are exposed like URL's, but client-specific objects (returned as the result of a method call) usually are not. It is about securing these that the concern was about.

To give you more background, our security architect thinks that client authentication through certificates (at least on a web scale) is impractical, as certificates are expensive. So, given just server-authenticated SSL connections, it used to be possible with some Java based web frameworks to guess some-one else's session id, as session id generation was to some degree predicable. The architects thinks the same might be possible with Ice.

I'll just forward your reply - if any - to him and will keep myself out of the loop, as I am not a security expert.

[matthew]

What would you consider the equivalent in Ice for a session?

Ice itself has no concept of a session. You can add the concept of a session using some application defined semantics, as implemented by Glacier2. However, sessions have no semantic meaning at the Ice level.

...it used to be possible with some Java based web frameworks to guess some-one else's session id, as session id generation was to some degree predicable. The architects thinks the same might be possible with Ice.

I'll just forward your reply - if any - to him and will keep myself out of the loop, as I am not a security expert.

If you use Glacier2 with per user category filters in conjunction with Glacier2 sessions, then while it is theoretically possible to guess the id (although highly unlikely!) of another users glacier2 session, it is not possible to call on the other sessions since Glacier2 will reject the requests.

[matthew]

After reviewing the Glacier2 code, its not even realistically possible to guess another users session id. The sessions keys are 20 byte random values (each value being one of 93 possible values). In addition, we do not use a pseudo-random number generator; we use crypto functions under Windows and /dev/urandom on POSIX systems. It is impossible to guess these values.

In summary, its not possible to guess another users session id. If a session id was somehow hijacked from another session (which, assuming the communications are SSL protected should also not be possible), Glacier2 would not permit any calls on that session, since, if correctly configured, it rejects any calls on a session except from the connection which originated the session.

[kwaclaw]

Posted on behalf of my security architect:

Object ids are not session ids, and should not be compared. With respect to securing object ids, you can no more secure your server via object ids, than you can secure your website with a URL. It would be akin to securing your house through your address, or the number on your door. Just as you secure your house with locks and alarms, you secure your distributed communications with encryption and authentication.

I perfectly agree with this statement and that is the reason for my concern. Here is the issue. While I don’t know exact terminology used in the framework, I will try to explain in simple terms what the issues, threats, and concerns are.


Let’s look at the scenario where two authenticated clients are accessing server through the same SSL protected pipe.
The server will get messages from each of the two clients in a random order and it will have to know which message is coming from which client.
Unless the protocol is entirely stateless, there will be information about the state of the client kept either on the server side or sent with every message.
Once identified and authenticated, the client is assigned some kind of identifier that is used to identify its messages.
Assuming that we might have other legitimate but malicious user there are at least two attack scenarios that can happen if the identifier is not protected (btw encryption alone might not be enough).
Malicious user can guess the other user’s identifier and spoof him / her by putting that identifier in false messages he forges. This is difficult / impossible if the identifier is a long random number.
Otherwise the malicious user can simply monitor network traffic (he is within same SSL pipe as the other guy), and see the identifier of the other client. Long random number doesn’t protect.
Both these two and some other similar scenarios are collectively known as “Session Hijacking” attacks.


Session hijacking is one of ten most common security vulnerabilities. To prevent these types of attacks, strong uninterrupted linkage is needed from the initial authentication to each message sent by the client. Btw SSL has that mechanism built in the protocol.

Finally, my question is, how we can protect one user / client from another malicious one?

Regards,
Miroslav

My apologies if I didn’t use the exact terminology used in the framework.

[matthew]

Glacier2 security does not rely on session ids at all. Instead it relies on the assumption that an SSL connection cannot be hijacked.

Let’s look at the scenario where two authenticated clients are accessing server through the same SSL protected pipe.

With Glacier2, this is not possible. Each authenticated client always has its own bi-directional connection.

In re-reading what I wrote below, I also need to correct myself.

In summary, its not possible to guess another users session id. If a session id was somehow hijacked from another session (which, assuming the communications are SSL protected should also not be possible), Glacier2 would not permit any calls on that session, since, if correctly configured, it rejects any calls on a session except from the connection which originated the session.

When I was earlier referring to "session ids" I was both wrong and confusing.

This unique id mentioned above is for reverse routing of callbacks from the server to the client through Glacier2, and is both unique and very long. The uniqueness of the identity is important to ensure correct reverse routing, but is not really important from a security point of view.

Separate from that is the identity of the Glacier2 session object. For access control for authenticated clients, it is often useful to use category filters. See section 39.5.2 of the Ice manual for full information. In short, Glacier2 has built in support for a category filter based on the id of the user (either the user id for username/password authentication, or the DN if using SSL certificates). This is controlled using the "Glacier2.Filter.Category.AcceptUser" property. If you want to use this filtering, then you need to set the object id category of the glacier2 session to the identity of the user. The Glacier2 session objects are created by application code by implementing the Glacier2::SessionManager interface.