Netcraft: Cookie Hijacking Security Hole Still Prevalent

Discussions

News: Netcraft: Cookie Hijacking Security Hole Still Prevalent

  1. According to a new survey by Web server information firm Netcraft, many java-based websites have yet to plug a year-old security hole that allows malicious users to hijack another user's identity by manipulating cookie session IDs. Sites using java appservers based on Suns' reference implementation of the Java Server Developers Kit (JSDK 2.0). Websphere and ATG are among those affected.

    Read Netcraft says many e-commerce sites ignore Java server hole.
  2. Joris Evers' article missed a few things that other readers might want to know.

    1) A direct link to the referenced story, namely netcraft.com/survey/

    2) A link to the original advisory, namely www.netcraft.com/security/public-advisories/2001-01.1.html

    3) The vulnerability is not limited to JSPs, but to servlets in general. The Netcraft survey itself contributes to the confusion by addressing the prevalence of JSP-based sites, while not mentioning that the vulnerability is servlet-based.

    4) The cookies can be, and often are, in-memory cookies. Although these are not stored to the disk, they are still vulnerable.

    The original advisory is interesting reading.
  3. They claim that it works against SSL, but they don't explain how. With URL rewriting disabled, the session ID should be part of the encrypted headers, and should therefore be safe. Session ID's aren't really supposed to be a security mechanism, anyway. For example, they do nothing to gurantee the identity of the server to the browser.
  4. The attack is based on guessing another users session id. SSL is not a defense as the attack does not rely on observing the traffic of another user.
  5. The issue I think is solved already. At least Tomcat and Caucho Resin use significant random components together with client IP, timestamp, session count etc.

    On the other hand, I don't see why this is a problem only for servlet engines and not for MS Site Server session IDs for example. Any web application server that needs to store session information could be vulnerable if the session IDs are allocated in a predictable manner.
  6. My question is: why are any enterprises running JSDK, or commercial servers based on JSDK, on production???