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

mhellman at taxandfinance.com mhellman at taxandfinance.com
Wed Jun 9 08:53:24 EDT 2010


This is not just limited to AOL. I see this happening from a lot of mobile
devices too(which suggests this may be getting more common), and we
already have seen a couple other examples on the list. Bottom line, there
are a number of edge cases where if you do this you could really frustrate
users.

If you think about this from the perspective of the "layers" involved, it
does seem a little presumptuous of developers to assume the ability to tie
sessions to IP addresses.

> Proof that AOL users don't count :)
>
> http://botsosphere.blogspot.com/2007/08/reverse-proxies-are-menace-to-web.html
>
> -
> Mike Adewole
> www.botslist.ca
>
> ----- Original Message -----
> From: "Bil Corry" <bil at corry.biz>
> To: "Rathnakar Konda" <rathnakar.k at gmail.com>
> Cc: "Jim Manico" <jim at manico.net>; "Peter Conrad" <conrad at tivano.de>;
> <websecurity at webappsec.org>
> Sent: Tuesday, June 08, 2010 3:00 PM
> Subject: Re: [WEB SECURITY] Session attacks, What are the new breeds of
> attacks ?
>
>
>> AOL had a proxy system that sent requests from multiple IP addresses;
>> each
>> request could potentially come from a different IP.  Here's the
>> historical
>> document explaining it:
>>
>> http://web.archive.org/web/20071013115223/http://webmaster.info.aol.com/proxyinfo.html
>>
>> There are probably other ISPs that still provide a similar proxy system.
>>
>>
>> - Bil
>>
>> Rathnakar Konda wrote on 6/8/2010 8:34 AM:
>>> Im not 100% sure but I heard that few of the ISPs in USA changes the
>>> user-ip
>>> every 'x' amount of time. In this case, tying session-id to user-ip
>>> causes
>>> painful problems. Someone pls confirm this.
>>>
>>> On Mon, Jun 7, 2010 at 8:54 PM, Jim Manico <jim at manico.net> wrote:
>>>
>>>> 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
>>
>
>
> ----------------------------------------------------------------------------
> 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
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


----------------------------------------------------------------------------
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



More information about the websecurity mailing list