httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] IP-address spoofing a concern?
Date Tue, 27 Jan 2009 21:00:03 GMT
Brian Mearns wrote:
> On Tue, Jan 27, 2009 at 2:35 PM, Nick Kew <nick@webthing.com> wrote:
>> On Tue, 27 Jan 2009 14:16:55 -0500
>> Brian Mearns <mearns.b@gmail.com> 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 client
a) 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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message