This article includes a list of general references, but it lacks sufficient corresponding inline citations .(April 2012) |
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.
Alice has an account at the bank http://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.
Straightforward scenario:
http://unsafe.example.com/
accepts any session identifier, accepts session identifiers from query strings and has no security validation. http://unsafe.example.com/
is thus not secure.http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID
". Mallory is trying to fixate the SID to I_WILL_KNOW_THE_SID
.http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID
. The usual log-on screen pops up, and Alice logs on.http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID
and now has unlimited access to Alice's account.A misconception is that if a server only accepts server-generated session identifiers, it is safe from fixation. This is false.
Scenario:
http://vulnerable.example.com/
and checks which SID is returned. For example, the server may respond: Set-Cookie: SID=0D6441FEA4496C2
.http://vulnerable.example.com/?SID=0D6441FEA4496C2
."SID=0D6441FEA4496C2
.http://vulnerable.example.com/?SID=0D6441FEA4496C2
and now has unlimited access to Alice's account.This type of attack is similar to a cross-site cookie attack except that, it does not rely on the vulnerability of the user's browser. Rather, it relies on the fact that wildcard cookies can be set by a subdomain and, that those cookies may affect other subdomains.
Scenario:
www.example.com
hands out subdomains to untrusted third partiesevil.example.com
, lures Alice to his siteevil.example.com
sets a session cookie with the domain .example.com
on Alice's browserwww.example.com
this cookie will be sent with the request and Alice will have the session specified by Mallory's cookie.When this attack is complete, Mallory can gain access to www.example.com
as Alice.
It is not essential that a user login to exploit session fixation attacks [1] and, although these unauthenticated attacks are not constrained to cross-sub-domain cookie attacks, the implications of sub-domain attacks are relevant to these unauthenticated scenarios. For example, Mallory may provide a URL from their evil site, fixating a session into an unauthenticated scenario, and use those techniques to exploit their target. This includes scenarios exploiting both the unauthenticated scenarios (e.g. forms or registration) as well as the ability to feed the user an established session to bypass the login completely.
Consider, for example, that Mallory may create a user A1ice on www.example.com and login that user to capture a current, valid session identifier. Mallory then entraps Alice with a URL from evil.example.com which fixates that session cookie in Alice's browser (as described above) and redirects to www.example.com for finalizing a particular transaction (or, in fact, broader use). Mallory is thus able to ghost the session from their original login, scraping data and executing operations as 'A1ice' on 'www.example.com'. If Alice was successfully duped and saved her credit card to the account, Mallory might then make purchases using that card.
Session 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.
This 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.
The 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 ] However, this solution is vulnerable to cross-site request forgery, and it does not meet the statelessness requirement of REST.
When 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.
A 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:
OLD_SID
from HTTP request.OLD_SID
is null, empty, or no session with SID=OLD_SID
exists, create a new session.NEW_SID
with a secure random number generator.NEW_SID
(and no longer by SID=OLD_SID
)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_SIDHTTP/1.1Host: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.1200OKSet-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.
One 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.
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;
A 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.
if(logout){session_destroy();// Destroy all data in session}
This 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.
When visiting a page, most web browsers will set the Referrer header – 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, http://vulnerable.example.com/
could employ the following security check:
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
One 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:
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.
For some sites, the added security outweighs the lack of convenience, and for others it does not.
Browsers 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.
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.
But User Agent may change legally in few cases. Following examples are the same users.
Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 854X480 motorola DROID2
Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID2 Build/VZW) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 480X854 motorola DROID2
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/0.0.5; +http://flipboard.com/browserproxy)
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (FlipboardProxy/1.1; +http://flipboard.com/browserproxy)
This section possibly contains original research .(July 2019) |
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:
HTTP referrers are not passed with SSL/TLS (HTTPS).
The following PHP script demonstrates several such countermeasures combined in a defense in depth manner:
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.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.
The World Wide Web is an information system that enables content sharing over the Internet through user-friendly ways meant to appeal to users beyond IT specialists and hobbyists. It allows documents and other web resources to be accessed over the Internet according to specific rules of the Hypertext Transfer Protocol (HTTP).
A web browser is an application for accessing websites. When a user requests a web page from a particular website, the browser retrieves its files from a web server and then displays the page on the user's screen. Browsers are used on a range of devices, including desktops, laptops, tablets, and smartphones. By 2020, an estimated 4.9 billion people had used a browser. The most-used browser is Google Chrome, with a 66% global market share on all devices, followed by Safari with 18%.
Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. During the second half of 2007, XSSed documented 11,253 site-specific cross-site vulnerabilities, compared to 2,134 "traditional" vulnerabilities documented by Symantec. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.
In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.
In computer science and networking in particular, a session is a time-delimited two-way link, a practical layer in the TCP/IP protocol enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, automated systems, or live active users. A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically stateful, meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.
In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>
, where <credentials>
is the Base64 encoding of ID and password joined by a single colon :
.
In computing-mobile, the same-origin policy (SOP) is a concept in the web-app application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's (DOM).
Web analytics is the measurement, collection, analysis, and reporting of web data to understand and optimize web usage. Web analytics is not just a process for measuring web traffic but can be used as a tool for business and market research and assess and improve website effectiveness. Web analytics applications can also help companies measure the results of traditional print or broadcast advertising campaigns. It can be used to estimate how traffic to a website changes after launching a new advertising campaign. Web analytics provides information about the number of visitors to a website and the number of page views, or creates user behavior profiles. It helps gauge traffic and popularity trends, which is useful for market research.
Session poisoning is a method to exploit insufficient input validation within a server application. Typically a server application that is vulnerable to this type of exploit will copy user input into session variables.
Cross-site cooking is a type of browser exploit which allows a site attacker
to set a cookie for a browser
into the cookie domain of another site server
.
In computer science, session hijacking, sometimes also known as cookie hijacking, is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many websites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer. After successfully stealing appropriate session cookies an adversary might use the Pass the Cookie technique to perform session hijacking. Cookie hijacking is commonly used against client authentication on the internet. Modern web browsers use cookie protection mechanisms to protect the web from being attacked.
HTTP cookies are small blocks of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session.
The Public Suffix List (PSL) is a community-maintained list of rules that describe the internet domain name suffixes under which independent organisations can register their own sites. Entries on the list are referred to as effective top-level domains (eTLDs), and contain commonly used suffixes like com, net and co.uk, as well as private suffixes like appspot.com and github.io.
Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.
HTTP Strict Transport Security (HSTS) is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone. HSTS is an IETF standards track protocol and is specified in RFC 6797.
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.
Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. It is a Candidate Recommendation of the W3C working group on Web Application Security, widely supported by modern web browsers. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features.
Browser security is the application of Internet security to web browsers in order to protect networked data and computer systems from breaches of privacy or malware. Security exploits of browsers often use JavaScript, sometimes with cross-site scripting (XSS) with a secondary payload using Adobe Flash. Security exploits can also take advantage of vulnerabilities that are commonly exploited in all browsers.
Secure cookie is a type of an HTTP cookie that has the Secure attribute set, which limits the scope of the cookie to "secure" channels. When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel. Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity. This issue is officially referred to as Weak Integrity. However, some browsers, including Chrome 52 and higher and Firefox 52 and higher, forgo this specification in favor of better security and forbid insecure sites (HTTP) from setting cookies with the Secure
directive.