Brian Mearns wrote:
On Tue, Jan 27, 2009 at 2:35 PM, Nick Kew <nick@xxxxxxxxxxxx> wrote:On Tue, 27 Jan 2009 14:16:55 -0500 Brian Mearns <mearns.b@xxxxxxxxx> wrote:I'm not concerned right now with security of content, I'm concerned with someone highjacking another person's session.Then Digest Authentication is exactly what you want.Like I said, it's not clear to me how this would solve my problem. Can you elaborate a little?
Maybe first read this : http://en.wikipedia.org/wiki/Http_digest_authentication The point is :Presumably, you do not send a session token to the client, before the client has gone through some authentication procedure (login).
If you use this HTTP Digest authentication, then that particular clienta) will be the only one who knows the "authentication string" to send later to the server to confirm he is the one that previously authenticated. This is sent as a HTTP header with each request, so it is not immediately visible to a would-be miscreant. It is also encrypted, so it is not really obvious what is in it. b) the client will automatically repeat this authentication header when talking to the same server, as long as the URL it is talking to appears sufficiently similar, and as long as the browser is kept open, and as long as the server does not force it to re-authenticate.
So in fact, it could also serve as a replacement for your "token", without need to be included in the URl or in the posted forms or in a cookie. Now, it is up to you if in addition, you still want to send an application token in some other form. But when you get the token, you should anyway first check if the client is authenticated, and only then accept the token.
If someone happened to get hold of your token, and tried to send it to the server to impersonate another client, your application would know that it is a fake, because there is no practical way the fake client could also fake the HTTP Digest header and send it at the same time.
The only real weak spot is the "man in the middle".If another server could convince the client that it is your site, it could ask the client to authenticate in clear (using Basic authentication), then grab the user-id/password of the client, and itself make the call to your real server. Your server would request a Digest authentication to him, thinking he is the real client. Having saved the original client's id/password, he would then enter a proper Digest negotiation with your server, and authenticate. Once it has done that, it receives the server Digest token and your app's token, and can continue to talk to your server on behalf of the original client.
Becoming a man-in-the-middle in that way takes some effort, and the probability of someone making this effort is proportional to the gain to be made by succeeding at it, and inversely proportional to the penalty incurred for trying and being found out.
Whether that is an acceptable risk is your decision. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|