Cookie stealing and replay in a corporate single sign on environment

["Willard Fernortner" <fernortner () hotmail com>]

I'm wondering if anyone else has given thought to cookie replay attacks when 
using a web single sign-on solution on a corporate network.  Here are my 
concerns:

-- Web single sign-on typically works using a shared cookie that is passed 
to all intranet web sites in the corporate domain (e.g. *.myintranet.com).  
Because these cookies are passed to ALL internal web sites, there are plenty 
of opportunities for these cookies to be stolen:

  a) They can be harvested by employees, contractors, or anyone else that 
is allowed to publish a web page to ANY corporate web site (through server 
log files or through JavaScript on published web pages)
  b) They can be stolen using a cross site scripting flaw on ANY web site 
in the corporate domain

-- Once an SSO cookie is stolen, the attacker can use that cookie to 
impersonate the victim to HR, financial, or other sensitive web applications 
that the victim has access to.  The implications could be huge.

-- Most people I've talked to appear to be clueless that a problem exists.  
I often hear "we use SSL" when bringing up the issue.  SSL doesn't matter.  
Cross site scripting can be used to steal cookies regardless of SSL use.  
Similarly, I often hear "the SSO cookie is encrypted".  That doesn't matter
either.  I just need to replay the encrypted cookie "blob" in an attack.

Aside from "don't use single sign on" and "use certificates" (neither are 
options for us for several reasons), what can be done to mitigate the risks? 
 I've considered the following:

-- Track the IP address of the legitimate user when they authenticate, then 
validate that the user is coming from the same IP address for each 
subsequent request to the SSO environment.  Most SSO vendors support this 
out of the box.  However, IP addresses can be spoofed (it's not hard to 
spoof your bosses IP address when you are on the same subnet), and IP 
validation doesn't work in NAT environments.  Still, I think this is 
probably the most feasible option.

-- Use timeout values to force periodic re-authentication.  However, 
reauthenticating too often defeats the purpose of SSO.

-- Use some sort of nonce so that cookies can only be used one time.  This 
probably wouldn't work well in an SSO environment when a user might want to 
have multiple web applications open at once though.

-- Put sensitive applications into a separate sub-domain (e.g. 
*.secure.myintranet.com), then use a separate SSO cookie for that specific 
domain.

Any other thoughts?  Has anyone else here implemented SSO on a corporate 
network, and if so, are you doing anything to prevent cookie stealing and 
replay?  If you aren't doing anything, is it due to ignorance, or have you 
specifically decided not to address the problem?  Why?

Thanks
WF