Many web sites are designed to authenticate and track a user when

communication is first established. To do this, users must prove their

identity to the web site, typically by supplying a username/password

(credentials) combination. Rather than passing these confidential

credentials back and forth with each transaction, web sites will

generate a unique "session ID" to identify the user session as

authenticated.  Subsequent communication between the user and the

web site is tagged with the session ID as "proof" of the authenticated

session. If an attacker is able predict or guess the session ID of

another user, fraudulent activity is possible.

Example

Many web sites attempt to generate session IDs using proprietary

algorithms. These custom methodologies might generation session

IDs by simply incrementing static numbers. Or there could be more

complex procedures such as factoring in time and other computer

specific variables.

The session ID is then stored in a cookie, hidden form field, or URL. If

an attacker can determine the algorithm used to generate the session

ID, an attack can be mounted as follows:

1)  attacker connects to the web application acquiring the current

session ID.

2)  attacker calculates or Brute Forces the next session ID.

3)  attacker switches the current value in the cookie/hidden form 

field/URL and assumes the identity of the next user.

References

 iDefense: Brute Force Exploitation of Web Application Session ID's ,

By David Endler   iDEFENSE Labs

http://www.cgisecurity.com/lib/SessionIDs.pdf

 Best Practices in Managing HTTP Based Client Sessions , Gunter

Ollmann   X Force Security Assessment Services EMEA

15

Copyright 2004, Web Application Security Consortium. All rights reserved.