[WEB SECURITY] Session attacks, What are the new breeds of attacks ?

Rathnakar Konda rathnakar.k at gmail.com
Tue Jun 8 11:38:13 EDT 2010


Hi Anurag Agarwal,

I could not get your point. Invalidating a session should mean clearing the
existing session data and starting completely a new session. Did I missed
something?


On Mon, Jun 7, 2010 at 11:57 PM, Anurag Agarwal <anurag.agarwal at yahoo.com>wrote:

> One challenge while you do that is to make sure you copy the contents of
> the
> existing session to the new session (if any exists) otherwise you might
> break the functionality. The other solution is to create a unique cookie
> (encrypted) and tie it to that session-id.
>
>
> Thanks,
>
> Anurag Agarwal
> MyAppSecurity Inc
> Cell - 919-244-0803
> Email - anurag at myappsecurity.com
> Website - http://www.myappsecurity.com
> Blog - http://myappsecurity.blogspot.com
> LinkedIn - http://www.linkedin.com/in/myappsecurity
>
>
>
> -----Original Message-----
> From: Jim Manico [mailto:jim at manico.net]
> Sent: Monday, June 07, 2010 11:25 AM
> To: Peter Conrad
> Cc: websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] Session attacks, What are the new breeds of
> attacks ?
>
> Tying a session to a IP address is not reliable for internet-facing
> websites. Invalidate the old session and generate a new session at login
> time. That's the most reliable defensive control when trying to stop the
> threat of session fixation.
>
> - Jim
>
> > Hi,
> >
> > Am Donnerstag, 3. Juni 2010 schrieb Rathnakar Konda:
> >
> >> Session Hijacking: This works when someone takes the session id from
> other
> >> machine and uses it from another machine. To block this kind of hacks,
> >> session-id generation can be tied with the machine ip, user agent (more
> >> deeply tcp sessions). This has now became common practice nowadays
> >>
> >
> > has it? AFAIK this leads to problems with proxies, for example.
> >
> >
> >> Session Fixation: This is where the hackers forces to use the session id
> >> generated by him. Blocking is: Stop accepting user generated or
> suggested
> >> sessions id. this is also common in today's web server configuration.
> >>
> >
> > This is an incomplete fix. The attacker can still have to server
> > generate a session id and forward that to the user.
> > Tieing the session to an ip address would mitigate that, however.
> >
> > Bye,
> >       Peter
> >
>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to
> the confirmation email
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.829 / Virus Database: 271.1.1/2922 - Release Date: 06/07/10
> 02:35:00
>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> To unsubscribe email websecurity-unsubscribe at webappsec.org and reply to
> the confirmation email
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20100608/e6b9fce4/attachment.html>


More information about the websecurity mailing list