Now Chatting

Hello, can I help you with anything?

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

Specialized Pen Testing

Cross Site Request Forgery (CSRF) Risks

Privilege Escalation

Flash Based GUI Apps

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. 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.

Read More

Valency Networks provides security by giving solution as:

Do not accept session identifiers from Get/Post methods.

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 which set GET / POST variables.

Additionally, session identifiers (SIDs) in query strings enable other risk and attack scenarios;

Cookies are shared between tabs and popped up browser windows. If your system requires to be hit with the same domain ( and ), cookies may conflict with one another between tabs.

Identity Confirmation

This attack can be largely avoided by changing the session ID when users log in. If every "important" request 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". 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.

Store session identifiers in HTTP cookies

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. However, this solution is vulnerable to cross-site request forgery.

Utilize SSL / TLS Session identifier

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. 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.

Regenerate SID on each request

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.

Accept only server-generated SIDs

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.

Logout Functions

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.

Time out old SIDs

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.

Destroy Session if Referrer is suspicious

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.