WebApp Sec mailing list archives
Re: Tying a session to an IP address
From: Rogan Dawes <discard () dawes za net>
Date: Mon, 10 May 2004 17:14:29 +0200
Actually, it is not so trivial to spoof a TCP connection long enough to get something useful from it. Especially an HTTP connection.
The original fear with spoofed connections was rlogin/rsh, which used IP addresses as authentication. The mechanism for exploitation was usually something like:
Send SYN packet from "authenticated/permitted" IP address. Do not receive the SYN/ACK. Send ACK packet, with a payload of something like "echo '+ +' >> .rhosts" Even if you do not receive a response, you have cracked the box.This is still possible from some web apps, particularly those that allow you to execute admin functions if you come from a specific IP address, and don't use session cookies, etc.
BUT, the majority of apps on the Internet now require you to go through multiple levels in order to actually achieve something.
e.g. submit a GET to get a form to fill in, submit a POST with the values, submit a POST as a confirmation, etc.
It is not a simple as the rsh attack described above.Personally, I think that tracking the IP address CAN add some value. It is not foolproof, and can cause problems in certain circumstances, but it helps to raise the bar where those circumstances do not apply to you.
Rogan exon wrote:
Paul Johnston wrote:I'd say it doesn't do diddly squat to add to security, since it's trivial to spoof ones address.Hi,I'm interested in the merits of restricting a session to an IP address. I realise this isn't great security as often many users will appear to come from the same IP address (NAT, proxies, etc.) However, if you consider the case where an attacker uses an XSS vulnerability to steal the session ID, then the IP address restriction raises the bar considerably for an arbitrary remote attacker to exploit this. I'm worried that the IP address restriction wouldn't work for all users - e.g. if their ISP uses load-balanced web caches. Does anyone know how common such arrangements are in practice? Perhaps something to be done then is just check the top 16 bits of the IP address. This is likely to work for all such network arrangements and still raises the bar a lot for remote attacks.Does anyone here already restrict sessions by IP address? Regards, Paul
-- Rogan Dawes *ALL* messages to discard () dawes za net will be dropped, and added to my blacklist. Please respond to "lists AT dawes DOT za DOT net"
Current thread:
- Tying a session to an IP address Paul Johnston (May 10)
- Re: Tying a session to an IP address exon (May 10)
- Re: Tying a session to an IP address Rogan Dawes (May 10)
- Re: Tying a session to an IP address exon (May 10)
- Re: Tying a session to an IP address Rogan Dawes (May 10)
- Re: Tying a session to an IP address Chris Burton (May 10)
- Re: Tying a session to an IP address Imre Kertesz (May 10)
- Re: Tying a session to an IP address [summary] Paul Johnston (May 12)
- <Possible follow-ups>
- RE: Tying a session to an IP address Mike Randall (May 10)
- RE: Tying a session to an IP address Imperva Application Defense Center (May 10)
- Re: Tying a session to an IP address T.J. (May 10)
- Re: Tying a session to an IP address Adam Tuliper (May 10)
- RE: Tying a session to an IP address Steve McCullough (May 11)
- RE: Tying a session to an IP address Wolf, Yonah (May 10)
(Thread continues...)
- Re: Tying a session to an IP address exon (May 10)