session fixation

In computer network security, session fixation attacks attempt to exploit the vulnerability of a system that allows one person to fixate (find or set) another person's session identifier. Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.

In computer network security, session fixation attacks attempt to exploit the vulnerability of a system that allows one person to fixate (find or set) another person's session identifier. Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data. Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank, http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID ". Mallory is trying to fixate the SID to I_WILL_KNOW_THE_SID . Alice is interested and visits http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID . The usual log-on screen pops up, and Alice logs on. Mallory visits http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account. Mallory visits http://vulnerable.example.com/ and checks which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2 . Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank, http://vulnerable.example.com/?SID=0D6441FEA4496C2 ." Alice logs on, with fixated session identifier SID=0D6441FEA4496C2 . Mallory visits http://vulnerable.example.com/?SID=0D6441FEA4496C2 and now has unlimited access to Alice's account. Note: Cookies are shared between tabs and popped up browser windows. If your system requires to be hit with the same domain (www.example.com/?code=site1 and www.example.com/?code=site2 ), cookies may conflict with one another between tabs. It may be required to send the session identifier on the URL in order to overcome this limitation. If possible use site1.example.com or site2.example.com so there are no domain conflicts in the cookies. This may incur costs with extra SSL certificates. This behavior can be seen on many sites by opening another tab and trying to do side by side search results. One of the sessions will become unusable. Session identifiers in GET and POST were deprecated in PHP 8.4 and will be removed in PHP 9.0. If OLD_SID is null, empty, or no session with SID= OLD_SID exists, create a new session. Generate new session identifier NEW_SID with a secure random number generator. Let session be identified by SID= NEW_SID (and no longer by SID= OLD_SID ) Transmit new SID to client. Example: If Mallory successfully tricks Alice into visiting http://victim.example.com/?SID=I_KNOW_THE_SID , this HTTP request is sent to victim.example.com : GET /?SID=I_KNOW_THE_SID HTTP/1.1 Host: victim.example.com victim.example.com accepts SID=I_KNOW_THE_SID , which would normally be bad. However, victim.example.com is secure because it performs session regeneration. victim.example.com gets the following response: HTTP/1.1 200 OK Set-Cookie: SID=3134998145AB331F Alice will now use SID=3134998145AB331F that is unknown to Mallory, and SID=I_KNOW_THE_SID is invalid. Mallory is thus unsuccessful in the session fixation attempt. Unfortunately session regeneration is not always possible. Problems are known to occur when third-party software such as ActiveX or Java applets are used, and when browser plugins communicate with the server. Third-party software could cause logouts, or the session could be split into two separate sessions. If the implementation of sessions includes transmitting the SID through GET or POST variables, then this might also render the "back" button in most browsers unusable, as the user would then be using an older, invalid, session identifier from a previous request. if (!isset($_SESSION['SERVER_GENERATED_SID'])) { session_destroy(); // Destroy all data in session } session_regenerate_id(); // Generate a new session identifier $_SESSION['SERVER_GENERATED_SID'] = true; if (logout) { session_destroy(); // Destroy all data in session } if (strpos($_SERVER['HTTP_REFERER'], 'http://vulnerable.example.com/') !== 0) { session_destroy(); // Destroy all data in session } session_regenerate_id(); // Generate a new session identifier if ($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) { session_destroy(); // Destroy all data in session } session_regenerate_id(); // Generate a new session identifier $_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR']; However, there are some points to consider before employing this approach. Several users may share one IP address. It is not uncommon for an entire building to share one IP address using NAT. One user may have an inconsistent IP address. This is true for users behind proxies (such as AOL customers). It is also true for some mobile/roaming users, as well as users that are behind load balanced Internet connections. Users with IPv6 Privacy Extensions enabled may also change their IPv6 privacy addresses at any time. It will not work reliably with dual stack clients as requests will move between IPv4 and IPv6. It will not work reliably with mobile users, as mobile users roam between addresses as well. For some sites, the added security outweighs the lack of convenience, and for others it does not. if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) { session_destroy(); // Destroy all data in session } session_regenerate_id(); // Generate a new session identifier $_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT']; However, there are some points to consider before employing this approach. Several users may have same browser User Agent in Internet café. Several users may have same default browser (ex: Internet Explorer 6 in Windows XP SP3 or mini browser in mobile phone). But User Agent may change legally in few cases. Following examples are the same users. A smartphone whose screen rotated since the last request Internet Explorer compatibility mode: A user accessing a web site through a proxy distributed across multiple servers, not all of which are upgraded to the latest version of the proxy software if (isset($_GET['LOGOUT']) || $_SERVER['REMOTE_ADDR'] !== $_SESSION['PREV_REMOTEADDR'] || $_SERVER['HTTP_USER_AGENT'] !== $_SESSION['PREV_USERAGENT']) { session_destroy(); } session_regenerate_id(); // Generate a new session identifier $_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT']; $_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR']; Note that this code checks the current REMOTE_ADDR (the user's IP address) and User-agent against the REMOTE_ADDR and User-agent of the previous request. This might be inconvenient for some sites as discussed above. ==References==

Text derived from https://en.wikipedia.org/w/index.php?oldid=1373086150 under CC BY-SA 4.0; modifications have been made.