Re: Web session tracking security prob. Vulnerable: IIS and ColdFusion (maybe others)

[Marc Slemko <marcs () znep com>]

On Wed, 29 Aug 2001, Jeff Jancula wrote:

> IIS and ColdFusion do a pretty good job of generating random session values, so that users can't guess each other's 
> session values. However, an attacker could force a predictable cookie value, by using JavaScript or an <META 
> HTTP-EQUIV> tag to override the relevant cookies:
>
>  document.cookie = "ASPSESSIONID=BBBBBBBBAAAAAAAAAAAAAAAA";
>
> or,
>
>  <META HTTP-EQUIV="Set-Cookie" Content="CFID=123; path=/">
>  <META HTTP-EQUIV="Set-Cookie" Content="CFTOKEN=1111111; path=/">
>
> Of course, the hard part is getting the JavaScript or META tag to the victim's browser (that's were cross-site 
> scripting comes in - a subject covered elsewhere).

If a user can set the cookie via a cross site scripting attack,
then they could also read the cookie that is "really" set by the
server just fine using that same attack, so the added exposure from
simply being able to do that is very minimal.

However, this _widens_ the range of servers that can be used for
such an attack.  If Good Practices are followed, then cookies may
normally, for example, be set to be sent only to secure.example.com
instead of .example.com and may be set with the secure-only flag
on.  That means any cross site scripting vulnerabilities on
sillyoldbox.example.com won't matter.

However, if what is stated here holds true, then an attacker could 
set their own .example.com cookie using a vulnerable server in example.com
and secure.example.com will accept it and use it.


> ColdFusion makes this attack even easier, because it allows its session tracking variables to be specified on the URL 
> line. So, an attacker could force a predictable cookie value by passing a user a link, via e-mail, another web site, 
> or as a bookmark. For example:
>
>  http://www.MyColdFusion.net?CFID=123&CFTOKEN=1111111
>
> Regardless of the method used, the browser will send the modified ASPSESSIONID or CFID/CFTOKEN values for all future 
> requests to the web server. The problem is, the web server honors the modified session values - as if the server 
> actually issued them!

If the server actually takes the tokens passed to it on the URL and 
sets them into cookies, that does indeed open up a further vulnerability 
by allowing this to be exploited without any cross site scripting 
vulnerabilities.

This is a real problem, however, like cross site scripting attacks, it
typically gets little attention because it has to be exploited on a client
by client basis.