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.
This archive was generated by hypermail 2b30 : Thu Aug 30 2001 - 10:24:40 PDT