Straightforward scenario: A misconception is that if a server only accepts server-generated session identifiers, it is safe from fixation.
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.
Mallory is thus able to ghost the session from their original login, scraping data and executing operations as 'A1ice' on 'www.example.com'.
It may be required to send the session identifier on the URL in order to overcome this limitation.
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.
[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.
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.
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.
Store a session variable containing a time stamp of the last access made by that SID.
However, if the originating request is from a HTTPS page, then the referrer will be stripped, so you cannot depend on this security system.
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.
A web application might make use of User-Agent detection in attempt to prevent malicious users from stealing sessions.