cyphersec A blog about Web Application Security and .NET development best practices

No, SlidingExpiration is not the answer

So the question is, shall we use slidingExpiration and what is the point of using it?
I never had a good feeling with the slidingExpiration, basically i don't like slidingExpiration for two big reasons.

1. The slidingExpiration setting was born as an application measure to reduce the risk of token stealing. when set to false, the specified timeout interval becomes a fixed period of time from the initial login, rather than a period of inactivity. Attackers using a stolen  authentication token have, at maximum, only the specified length of time to impersonate the user before the session times out. Because typical attackers of these Web-based applications have only the token, and don't really know the user's credentials, they can't log back in as the legitimate user, so the stolen authentication token is now useless and the application security threat is mitigated. When sliding expiration is enabled, as long as an attacker makes at least one request to the system every 15 minutes (or half of the timeout interval), the session will remain open indefinitely. This gives attackers more opportunities to steal information and cause other mischief in Web-based applications. (source developerfusion.co.uk)

2. The development side of slidingExpiration can be quite ineffective for business applications. I got the bad idea to rely on slidingExpiration and yep, it wasn't a good one. We have encountered many bugs coming from the testing guys about an unpredicted "Session Expires after 8-9-10-13 mins typing..." bug.

   Basically while testing the "client behavior" we though that completing a form (which can handle around 60 dinamically rendered usercontrols inside an asp.net page) would take around 8~15mins~ of typing like a "real world normal person" would do.
   Debugging cames to nothing. Nothing at all. (We are just using Forms authentication with a "non-common" database as security layer as the authorisation system, so why a Session Issue?). After ten minutes the solution poped up as "the bloody(sorry) slidingExpiration". The property value was 30 minutes.

 
APRESS PRO ASP.NET 3.5 about the slidingExpiration says
"This attribute enables or disables sliding expiration of the authentication cookie. If enabled, the expiration of an authentication cookie will be reset by runtime with every request a user submits to the page. This means with every request the expiration of the cookie will be extended."

But that's not true.

According to msdn slidingExpiration is:

"When the SlidingExpiration is set to true, the time interval during which the authentication cookie is valid is reset to the expiration Timeout property value. This happens if the user browses after half of the timeout has expired.
For example, if you set an expiration of 20 minutes by using sliding expiration, a user can visit the site at 2:00 PM and receive a cookie that is set to expire at 2:20 PM. The expiration is only updated if the user visits the site after 2:10 PM. If the user visits the site at 2:09 PM, the cookie is not updated because half of the expiration time has not passed. If the user then waits 12 minutes, visiting the site at 2:21 PM, the cookie will be expired".

Boom here it was our problem.

Seriously...What's the point of slidingExpiration=true?

About Alessio Marziali

Alessio Marziali (MCTS) is a Security Consultant with 9 years of experience developing secure applications with Microsoft .NET in a variety of sectors in UK and Italy. Published technical author with two ASP.NET books currently available for purchase and OWASP Code Crawler Project Leader.