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

Tom Stripling tstripling at appsecconsulting.com
Tue Jun 8 13:53:02 EDT 2010


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



More information about the websecurity mailing list