Session Riding

[Ronnie R]

Hi there

We have recently been the subject of a penetration test that has highlighted
a vunerability in an ASP.NET 2.0 application that is described as the
following...

"The authentication cookie is generated when the user logs into the
application. This cookie is not regenerated the next time a user logs into
the application. A malicious user can abuse this functionality by accessing
the login page and receiving an authentication cookie. The malicious user
then would leave the browser unattended and wait for the next user to login
to the application. When a legitimate user logs into the application, the
malicious user can use the same retrieved authentication cookie to hijack the
user session."

Considering that sessions have a timeout of say 20 mins, isn't this
something that is unavoidable, Ie if someone decides to hover around a
machine withint his 20 second period, grab the cookie and then craft a 'POST'
using this cookie, what is there that can be done to do prevent this. Or
perhaps I'm missing the point here

I have done some reading and implemented
'ViewStateUserKey = Session.SessionID' as recommended here
http://msdn.microsoft.com/en-us/library/ms972969.aspx

If anyone has any thoughts on this I would be very greatful for feeback and
your experiences

Regards

 

[Hector Santos]

Some PCI Auditors can be more "annal" about strict PCI Authentication
and Session Compliance. I too, had an issue with one because there is
really not much you can do about a compromised user. But there is a
point I missed and that is you do want to mitigate the problem by
reducing the potential for exploitation.

We solved it by having two cookies -

Authentication (login) cookie with a X minute life span
Authorization (session) cookie with Y minute timeout

So you have two Authentication and Authorization (AA) cookies. Example
X, Y values may be 2 minutes and 15 minutes.

What is critically important is that the cookies are unique and never
repeatable - the NONCE concept. This generally requires a
cache/storage concept and some management of the cache as well. Some
systems will create a batch of the unique values to be used for AA.
When exhausted, a new batch generated. Some system will dynamically
generate them on the fly and manage them on the fly, like we do.

The goal is to prevent replays of the AA keys and if you can do show
this in your test, it is enough to pass your (PCI?) penetration test.

 

[Ronnie R]

Hi Hector

Thanks for taking the time to reply, and apologies for not replying sooner,
i've been away.

I think I understand your meaning here thanks. What I am having trouble
understanding is how this translates into my application. I read the Pen test
comment "authentication cookie is generated when the user logs into" as being
the standard 20 minute cookie that ASP.NET generates for you to tie you to
your session? (maybe I understood this incorrectly, apologies for my
ignorance). In which case I can reduce this to a smaller value but this would
reduce the lifetime of the session (and hence all the session variables
etc?).

I'm unclear how I can configure such that I differentiate the 'X' from the
'Y', so that the session cookie expires more quickly for Authentiation vs
Authorization, when its the same session cookie that is used for the whole
session. I fear I may have misunderstood this aspect

If you have a moment to point me toward 3 or 4 lines of code this might help
me grasp the issue here. Any help greatly appreciated Hector

 

[Hector Santos]

I'm unclear how I can configure such that I differentiate the 'X' from the
'Y', so that the session cookie expires more quickly for Authentiation vs
Authorization, when its the same session cookie that is used for the whole
session. I fear I may have misunderstood this aspect

One way to do this is for the login forum, create a timer for X
minutes that forces to redirect back to the home page. You can do
that in javascript separate from the ASP.NET session time.

Another way is to set a different session variable with a time stamp
that is checked upon POST.