I can't put the whole thing together off the top of my head, and I'm a little busy this week, but I think the risks include the following:
- guessing a session ID - replaying a session ID - accidentally generating a duplicate session ID The server should take a unique session ID, a per-request datum (such as a use count), and a secret generated server-side, and compute a cryptographic hash of the three elements. The session ID, use count and hash can then be stored on the browser in either the URL or a cookie. As long as the per-request datum changes with each request in a predictable way, the server can verify that the browser-stored ID has not been forged, and should not be subject to replay or guessing. This still isn't right, but it's moving in the right direction.
