RE: Regeneration of Session Tokens (from the OWASP Guide)

["M. Burnett" <mb () xato net>]

Pilon, you are correct. Basically what you are talking about is using XSS or
something like it as a form of session fixation. But changing the token
after a transaction doesn't improve the situation enough. It would take a
careful, well-planned implementation to really be effective. 

I have never agreed with the OWASP guide or similar recommendations by
others to regenerate tokens. Most of the techniques I have seen are not
effective, are too complicated, or simply not practical. What happens if a
user has multiple browser windows open for different parts of your web site?
When you regenerate a token, you are doing that based on a previous token,
one that an attacker might have, what keeps attackers from using that token
to regenerate one for themselves? If you regenerate a token, do you
invalidate all previous tokens? How can you be sure that you are
regenerating the token for the real user not the attacker?

My own recommendation is to keep the same session token throughout the
entire session and use other well-known techniques to prevent or at least
significantly reduce exposure to token brute force attacks or replay
attacks. Avoid placing the token on the URL and make sure you properly
implement session cookies. Use a large keyspace for tokens so that it is
simply not possible to brute-force the token in a few hours and protect your
tokens with HMAC codes or some kind of checksum to help ensure authenticity.
Don't accept user-supplied tokens and use a strong random number generator
when you create tokens. Use other techniques to strongly bind the token to
the client. And of course, take care of any XSS issues and have some
mechanism to identify unusual activity.

Tokens should have relative timeouts (time since the last use) as well as
absolute timeouts (time since the first use). You should also expire a token
after a preset number of uses, say 500-1000 hits depending on the nature of
your web application. When you expire a token, don't automatically
regenerate a new one, expire the session and force a new login. If you do
prefer to auto-regenerate tokens, make sure you can still enforce these
absolute limits. 

If you really want to protect a critical transaction, say a major financial
transaction, you can simply invalidate the current session and force the
user to login as part of the transaction. CAPTCHA's also limit exposure to
some types of attacks. 


Mark Burnett




> -----Original Message-----
> From: Pilon Mntry [mailto:pilonmntry () yahoo com] 
> Sent: Monday, May 01, 2006 6:29 AM
> To: webappsec () securityfocus com
> Subject: Regeneration of Session Tokens (from the OWASP Guide)
>
>
>  In the great owasp guide there's a sub-topic on session 
> management, and it goes like;
>
> "
> ...
> To reduce the risk from session hijacking and brute force 
> attacks, the HTTP server can seamlessly expire and regenerate 
> tokens. This shortens the window of opportunity for a replay 
> or brute force attack.
> ...
> How to protect yourself
> This control is suited for highly protected sites.
> Token regeneration should be performed:
>  . prior to any significant transaction
> ...
> "
>
> I'm aware that in the guide, regenerating the session id is 
> meant to solve another problem: "to shorten the window of 
> opportunity for a replay or brute force attack". 
>
> But I just wanted to share this:
>
> If I understand the word "prior" correctly, this may result 
> in another way to steal session ids in an xss vulnerable application.
>
> If the attack code can't get the cookie via "document.cookie" 
> (HttpOnly), it may use XST. 
>
> If the attack code can't get the cookie via XST (TRACE closed 
> on servers and on proxies), then it may employ
> (XMLHTTPRequest) GET request with a "significant action form" 
> as the target URL. Then application returns the new sessionid 
> prior the significant action and attack code grabs the session id.
>
> So, alternatively, we may regenerate sessionid "immediately 
> after" the critical action for which another password is 
> being asked in the "critical action form".
>
> -pilon
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>
> --------------------------------------------------------------
> -----------
> Sponsored by: Watchfire
>
> The Twelve Most Common Application-level Hack Attacks Hackers 
> continue to add billions to the cost of doing business online 
> despite security executives' efforts to prevent malicious 
> attacks. This whitepaper identifies the most common methods 
> of attacks that we have seen, and outlines a guideline for 
> developing secure web applications. 
> Download this whitepaper today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=70130
0000007t9r
> --------------------------------------------------------------
> ------------


-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------