词条 | 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. Attack scenariosAlice has an account at the bankhttp://unsafe.example.com/ Mallory intends to target Alice's money from her bank. Alice has a reasonable level of trust in Mallory, and will visit links Mallory sends her. A simple attack scenarioStraightforward scenario:
Attack using server generated SIDA misconception is that if a server only accepts server-generated session identifiers, it is safe from fixation. This is false. Scenario:
Attacks using cross-subdomain cookieThis is like cross-site cookie, except that it does not rely on browser vulnerabilities. Rather, it relies on the fact that wildcard cookies can be set by one subdomain that affect other subdomains. Scenario:
Each of these attack scenarios has a result where Mallory has successfully gained access to the functions and data normally reserved for Alice. An alternative attack scenario does not require Alice to log into a site. Rather, simply by fixing the session, Mallory may be able to spy on Alice and abuse the data she enters. For example, Mallory may use the above attacks to give Alice her own authenticated session—so Alice will start using the site with all the authentication of Mallory. If Alice decides to purchase something on this site and enters her credit card details, Mallory might be able to retrieve that data (or other confidential data) by looking through the historical data stored for the account. This type of Session Fixation exploitation differs from the "classic" exploitation scenarios, since it happens in the unauthenticated part of an application or reverses the authentication (attacker logging victim in).[1] CountermeasuresDo not accept session identifiers from GET / POST variablesSession identifiers in URL (query string, GET variables) or POST variables are not recommended as they simplify this attack – it is easy to make links or forms that set GET / POST variables.
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 is 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. Best solution: Identity confirmationThis attack can be largely avoided by changing the session ID when users log in. If every request specific to a user requires the user to be authenticated with ("logged into") the site, an attacker would need to know the id of the victim's log-in session. When the victim visits the link with the fixed session id, however, they will need to log into their account in order to do anything "important" as themselves. At this point, their session id will change, and the attacker will not be able to do anything "important" with the anonymous session ID. A similar technique can be used to solve the phishing problem. If the user protects their account with two passwords, then it can be solved to a great extent. This technique is also useful against cross-site request forgery attacks. Solution: Store session identifiers in HTTP cookiesThe session identifier on most modern systems is stored by default in an HTTP cookie, which has a moderate level of security as long as the session system disregards GET/POST values.{{Citation needed|date=August 2010}} However, this solution is vulnerable to cross-site request forgery, and it does not meet the statelessness requirement of REST. Solution: Utilize SSL / TLS session identifierWhen enabling HTTPS security, some systems allow applications to obtain the SSL / TLS session identifier. Use of the SSL/TLS session identifier is very secure, but many web development languages do not provide robust built-in functionality for this. SSL/TLS session identifiers may be suitable only for critical applications, such as those on large financial sites, due to the size of the systems. This issue, however, is rarely debated even in security forums.{{Citation needed|date=July 2011}} Regenerate SID on each requestA countermeasure against session fixation is to generate a new session identifier (SID) on each request. If this is done, then even though an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID. Implementation of such a system is simple, as demonstrated by the following:
Example: If Mallory successfully tricks Alice into visiting Host: victim.example.com
Set-Cookie: SID=3134998145AB331F Alice will now use 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. Accept only server-generated SIDsOne way to improve security is not to accept session identifiers that were not generated by the server. However, as noted above, this does not prevent all session fixation attacks. } session_regenerate_id(); // Generate a new session identifier $_SESSION['SERVER_GENERATED_SID'] = true; Logout functionA logout function is useful as it allows users to indicate that a session should not allow further requests. Thus attacks can only be effective while a session is active. Note that the following code performs no Cross-site request forgery checks, potentially allowing an attacker to force users to log out of the web application. Time-out old SIDsThis defense is simple to implement and has the advantage of providing a measure of protection against unauthorized users accessing an authorized user's account by using a machine that may have been left unattended. Store a session variable containing a time stamp of the last access made by that SID. When that SID is used again, compare the current timestamp with the one stored in the session. If the difference is greater than a predefined number, say 5 minutes, destroy the session. Otherwise, update the session variable with the current timestamp. Destroy session if Referrer is suspiciousWhen visiting a page, most browsers will set the Referrer – the page that contained the link that you followed to get to this page. When the user is logged into a site that is not likely to be linked to from outside that site (e.g., banking websites, or webmail), and the site is not the kind of site where users would remain logged in for any great length of time, the Referrer should be from that site. Any other Referrer should be considered suspicious. However, if the originating request is from a HTTPS page, then the referrer will be stripped, so you cannot depend on this security system. For example, } session_regenerate_id(); // Generate a new session identifier Verify that additional information is consistent throughout sessionOne way to further improve security is to ensure that the user appears to be the same end user (client). This makes it a bit harder to perform session fixation and other attacks. As more and more networks begin to conform to RFC 3704 and other anti-spoofing practices, the IP address becomes more reliable as a "same source" identifier. Therefore, the security of a web site can be improved by verifying that the source IP address is consistent throughout a session. This could be performed in this manner: } 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.
For some sites, the added security outweighs the lack of convenience, and for others it does not. User AgentBrowsers identify themselves by "User-Agent" HTTP headers. This header does not normally change during use; it would be extremely suspicious if that were to happen. A web application might make use of User-Agent detection in attempt to prevent malicious users from stealing sessions. This however is trivial to bypass, as an attacker can easily capture the victim's user-agent with their own site and then spoof it during the attack. This proposed security system is relying on security through obscurity. } 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.
But User Agent may change legally in few cases. Following examples are the same users.
Defense in depth{{Main|Defense in depth (computing)}}Defense in depth is to combine several countermeasures. The idea is simple: if one obstacle is trivial to overcome, several obstacles could be very hard to overcome. A defense in depth strategy could involve:
It should be noted that HTTP referrers are not passed with SSL/TLS (HTTPS). The following PHP script demonstrates several such countermeasures combined in a defense in depth manner: $_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. See also
References1. ^"Article about unauthenticated Session-Fixation attacks" External links
1 : Web security exploits |
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。