[agwa]

> There's a second collarary to this: attackers can set your HTTPS cookies too.

If your app uses session ID cookies, then another implication of this is that attackers can set a user's session ID to a value they know, wait for the user to log in, and then use the session ID to hijack the logged-in session. To prevent this make sure you regenerate session IDs when logging a user in. (This isn't the only reason to regenerate session IDs on log in but it's a very compelling one.)

[tptacek]

This is called "Session Fixation". Most modern frameworks prevent it, which is a reason to use your framework's session functionality rather than re-inventing it.

Session fixation used to be a common problem. There were lots of J2EE applications which were not only fix-able, but which would allow an attacker to fix a session ID with a carefully crafted GET URL. It's much rarer now.