Re: defense against session hijacking

[Scott Taylor <security () 303underground com>]

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 - <security () 303underground com> 

BOFH Excuse #149:

Dew on the telephone lines.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html