Forgive the ignorance, but if we were using SSL, and assuming we're content that this can't easily be broken, is there still a point in using the functionality of this class? I mean, the way SSL works, are session IDs and fixation still issues or are they only issues if the SSL can be broken (after which all bets are then off)? I think the latter, but wonder if there are still issues in some circumstances of certain user browser options.
Vagharshak Tozalakyan - 2012-05-21 17:01:12 - In reply to message 1 from Jonathan Wood
1. Session hijacking is when the attacker uses packet sniffing to read network traffic between two sides of communication to steal the session cookie. When you pass encrypted data between the parties that will prevent sniffing-style attacks. However, it could still be possible to hijack the session. For example, by making some kind of man-in-middle SSL attack.
2. Session fixation is when the attacker attempts to exploit the vulnerability of a system which allows one person to "fixate" (set) another personís session ID. There are different types of fixation attacks, but the simplest way is to provide a valid user with a link http://somesite.com/login/?SID=123456 and when the user clicks that link she will use the session ID created by attacker. Then she login with her password and the attacker gets full access over her account. SSL encryption will not help this case. Utilizing SSL/TLS Session identifier could be a secure solution, but that is very rarely used technique in practice.
BTW, the methods performed in this Secure Session class does not completely prevent session attacks, it is just an additional level of protection.