On Tue, 2009-01-27 at 14:16 -0500, Brian Mearns wrote: > I'm not concerned right now with security of content, I'm concerned > with someone highjacking another person's session. I send a session > token, and the client sends it back, either in cookie data or in the > URL. Either way, it's plain text on the net, so anyone can just grab > it and send it to my server, which won't have anyway of knowing if > it's the original session creator or not. IIUC, with HTTP digest authentication, the user enters his/her username and password into the browser, and for each request, the browser calculates a new, unique token from the username, password, and request URL. The server won't allow the same token to be used more than once, so someone who snoops a token can't reuse it. This provides decent security against eavesdroppers. What I was pointing out is that an active attacker with control of the network can modify the body of a POST request in transit and the server will still accept the request as having a valid token, so different data will be saved than the client intended. Digest authentication has an "auth-int" mode that would prevent this, but it is unimplemented in Apache. Again, I would recommend https because it gives you full security against any kind of attacker on the network (assuming your users aren't in the habit of clicking through certificate warnings). -- Matt --------------------------------------------------------------------- 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
|