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

Erlend Oftedal erlend at oftedal.no
Wed Jun 9 02:13:17 EDT 2010


Yes the ASP.NET framework takes this approach. Upon login it generates an
.ASPXAuth cookie that bascially contains the user id and timestamps.

There are a couple of problems with ASP.NET's approach:
- The session does not change when visiting the site after expiry. This 
fits the shopping cart scenario well.

The session id can even be set to anything as long as the length is valid. 
If a session with the given ID does not exist, ASP.NET will simply 
generate a new empty session with that ID. So session fixation definitely 
exists.

If you steal someone's session cookie, even though you need the .ASPXAuth 
cookie, there is nothing connecting the two. So if as an example, the role 
of the user is cached in the session, and I steal that session and login, 
I will have that role.

And old blogpost about the .NET cookies: 
http://erlend.oftedal.no/blog/?blogid=41


- The second problem of ASP.NET is that there really is no way to log out.
Logging out simply deletes the ASPXAuth cookie from the browser. It still
remains valid untill the timestamp within it expires. This is also a 
classic problem with normal sessions. The session must be cleared and 
invalidated upon logout.


If you are going to use a session x + cookie y approach, I think it would 
be a good idea to stick the username or value of cookie y in the session,
and check it on each request. That would avoid the first problem.
The logout problem can be solved by maintaining a list of valid cookies, 
and checking that on each request as well.


Best regards,
Erlend Oftedal


On Tue, 8 Jun 2010, Tom Stripling wrote:

> If it helps illustrate the point, this is an approach I've seen people take
> in .Net applications using forms authentication.  The framework assigns the
> ASP.Net_SessionId as soon as the user hits the first page in the
> application.  When the user logs in, the framework will assign a forms
> authentication cookie, but will not change the value of the
> ASP.Net_SessionId by default.  This typically results in a type of Session
> Fixation.
>
> By tying the ASP.Net_SessionId (which is assigned prior to login) to the
> forms authentication cookie (which is only created at login, never before),
> it is possible to prevent Session Fixation attacks.  This is often done by
> associating the user ID and other private information with both cookies and
> comparing the values on every request.  This would be the third scenario
> Anurag described:
>
> Before Login - Session id x
> After Login - Session id x + Cookie y
> = not vulnerable to Session Fixation
>
> I'm not saying this approach is better or worse than other approaches, just
> that it prevents session fixation.
>
> - Tom
>
>
> -----Original Message-----
> From: Anurag Agarwal [mailto:anurag.agarwal at yahoo.com]
> Sent: Tuesday, June 08, 2010 12:20 PM
> To: 'SneakySimian'; websecurity at webappsec.org
> Subject: RE: [WEB SECURITY] Session attacks, What are the new breeds of
> attacks ?
>
>> The other solution is to create a unique cookie (encrypted) and tie it to
> that session-id.
>
>>> I'm not sure I follow. How would this solve the problem? Regardless of
>>> whether or not it is encrypted, you are still have what is effectively
>>> a session cookie all over again. If I'm misunderstanding what was
>>> meant here, please explain. :)
>
> It's simple. If I create a unique cookie and tie it to a session, the
> application is not solely relying on session id now as it is also looking
> for the cookie and hence its not vulnerable to session fixation.
>
>
> Before Login - Session id x
> After Login - Session id x
> = vulnerable to Session Fixation
>
> Before Login - Session id x
> After Login - Session id y
> = not vulnerable to Session Fixation
>
> Before Login - Session id x
> After Login - Session id x + Cookie y
> = not vulnerable to Session Fixation
>
> Hope this helps.
>
>
> 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: SneakySimian [mailto:sneaky.simian at gmail.com]
> Sent: Tuesday, June 08, 2010 3:27 AM
> To: websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] Session attacks, What are the new breeds of
> attacks ?
>
> If you tie sessions to IP addresses, not only do you have a problem
> with proxies, but what about those that use PAT on their networks? Now
> you've created a problem where anyone behind that PAT can get hold of
> that session, even unintentionally.
>
> I see session fixation as a two-step fix:
>
> 1. Don't allow users to specify their own session ID. Does the
> application really need to allow a user to do that?
>
> 2. Change the session ID between logged in and logged out and when
> switching user levels.
>
>> So this is also related to session-id that works across machines which is
> again controlled by web server configs.
>
> I'm sorry, but this is incorrect. The web server configuration has
> nothing to do with sessions. Yes, there are language configurations
> (php.ini, web.config, web.xml, etc.), but those are independent of the
> web server configuration and can be moved from web server to web
> server. I understand what you mean now, and I don't mean to nitpick,
> but this is an important distinction.
>
> Even so, the language configurations typically wouldn't control
> sessions in the way we are talking, at least from what I've seen. I'll
> use PHP, as that's what I'm most familiar with.
> http://www.php.net/manual/en/session.configuration.php. While there
> are a few settings in there that might be useful, none of them will
> really protect you against any of these attacks. I'd love to hear
> about the .NET languages and Java, so if anybody has any insight in to
> those, please share.
>
> In PHP, to regenerate a session ID, such as when logging in, you have
> to call session_regenerate_id. This is something the developer needs
> to do. http://phpsec.org/projects/guide/4.html has some good, albeit
> outdated, information as well.
>
> The problem comes in when developers do not use the built-in session
> functionality in the languages. There are a number of reasons for
> this, such as wanting to store in a database or on a memcache for load
> balancing, or whatever. So even if there were configurations available
> in each of the languages, they would be useless when developers build
> their own (or use someone else's).
>
>> The other solution is to create a unique cookie (encrypted) and tie it to
> that session-id.
>
> I'm not sure I follow. How would this solve the problem? Regardless of
> whether or not it is encrypted, you are still have what is effectively
> a session cookie all over again. If I'm misunderstanding what was
> meant here, please explain. :)
>
> ----------------------------------------------------------------------------
> 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/2924 - Release Date: 06/08/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
>
>
>
> ----------------------------------------------------------------------------
> 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



More information about the websecurity mailing list