On Mon, 2003-11-17 at 14:16, Thomas M. Duffey wrote: > Hi All, > > Sorry if this is common knowledge or regularly discussed; I'm fairly > new to the list. I see quite a few messages on this and other > security lists about session hijacking in Web applications. Isn't it > good defense for a programmer to store the IP address of the client > when the session is initiated, and then compare that address against > the client for each subsequent request, destroying the session if the > address changes? Do many programmers really overlook this simple > method to protect against such an attack? It's not perfect but should > significantly increase the difficulty of such an attack with little or > no annoying side effects for the legitimate user. Would it be useful > to extend the session modules of the common Web scripting languages > (e.g. PHP) to enable an IP address check by default? > > Best Regards, > > - -- > :: t h o m a s d u f f e y > :: h o m e b o y z i n t e r a c t i v e
Defense is not always an objective of programmers. Often they have a goal to "make it work" then apply security as an afterthought. Security is often an added burden in the debugging process too, because when you are troubleshooting data on the wire, its much easier to spot a problem if it is sent unencrypted. There are major packages out there that will restrict a session to an IP (bugzilla.mozilla.org). SourceForge offers an option to "stay in SSL after authentication" which by not letting any other session variables be seen, should also go far towards preserving integrity. At the server side, although initially obvious that basing session information on an IP address makes sense - there are proxies and other methods of load balancing that throw a wrench in that plan. Often just plain keeping a hash string either in the url or in a cookie on the client is the only way to accurately track sessions from a user. Often the tradeoff that is made is to keep session continuity as a priority (thus allowing hijacking by capturing URLs), possibly mitigated by changing that string each time so that a captured URL would no longer be valid after the real user clicks on another page... But then passing the appropriate information (shopping cart for example) to another server or an encrypted session on the same server - but requiring fresh authentication moments before purchasing using stored information. This way a hijacked shopping session does no good without successfully authenticating to the purchasing server. -- Scott Taylor - <[EMAIL PROTECTED]> BOFH Excuse #149: Dew on the telephone lines. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
