Computer Security, Technology, Tutorials

Protecting Web Applications From Session Fixation Attacks

June 2, 2017

Many web developers don’t have the mindset of a hacker which is why numerous web applications illustrate critical security vulnerabilities.

Software development and cyber security proficiency are two independent areas under the IT umbrella, hence insisting on an immaculate security design from your developers is senseless.

The web developer has to collaborate with a security professional to assure that deployed applications are secure.

If you are on your own and don’t have the budget to hire a cyber-security expert to assist, here is how a malicious actor can exploit your system utilizing session fixation attacks and what you can do to prevent them.

Do You Use Sessions In Your Web Applications?

If your web application has a secure, exclusive area where users must log in, then your answer will be “Yes.”

Sessions are distinctive server variables which identify users. They consist of long, alphanumeric values that are particular to the user. Eventually, the session will time out and be removed as a valid token when the user does not require using the application anymore.

Your session can be stored in a number of ways. Some web developers choose to store sessions in cookies while others store them in “hidden form” variables. Some of the users block cookies. Thus the sessions cannot be stored. This results in an issue where the web application is prevented from functioning properly within the user’s browser.

As this is an issue that can’t be restrained from the server’s side, programmers typically decide to store session information in hidden form variables or in URL query strings. This terminates the possibility that users blocking the cookies can’t use the web app.

How Does A Session Fixation Attack Work?

Because developers choose to store session IDs in ways that may be viewed by standard users, the malicious actor can retrieve an assigned session ID by merely logging into the application.

The following actions take place during a session fixation attack:

1. The intruder logs directly into your web application and acquires a valid session ID.

The intruder logs in normally with a valid account consisting of a valid username and password.

You can inspect the credentials in the application as it establishes that they are authentic, and a session ID is allocated to the intruder. The session ID can be stored in a cookie or in a hidden variable. Notably, the adversary is capable of perceiving the value with any storage option. Therefore, you shouldn’t fret about how to store the session. You may deploy it in a query string variable, however, this is less preferred by the majority of developers.

Notably, the adversary is capable of perceiving the value with any storage option. Therefore, you shouldn’t fret about how to store the session. You may deploy it in a query string variable. However, this is less preferred by the majority of developers.

2. The blackhat sends a malicious link to the target.

In nearly all applications, the developer identifies whether a session ID is accessible in a query string to recognize if the user is already logged in the system.

If the session variable is deployed in a form POST method, then the blackhat hacker recognizes this method as well prior sending an email to the target.

The blackhat sends a malicious link to the target dependent on the approach you set up session identification. If it consists of a simple query string method, the blackhat will proceed by sending a malicious link to the target. If it consists of employing a form POST method, the blackhat ought to deceive the user into sending a POST submission to your web application. A POST submission occurs when users click the “Submit button” in your site forms.

In spite of the method, step two in a real life attack always involves deception and sending a phishing email to the target.

3. The target clicks the link to your web application.

To simplify the matter, presume that the session variable is transmitted using a query string variable in a malicious link to the target. The hacker sends a link to the target with his own session ID in the URL. The target is convinced that the URL is real and decides to click on the malicious URL. This is merely the first part of the inevitable successful attack. Your web application finds the session ID to be valid and then proposes the user to log in.

Considering that the targeted victim is on the official website, typically the victim will then log in unwary of any mischievous activity.

4. The hacker now has been granted access to the victim’s account.

With the hacker’s session ID and the victim logged into the system, the hacker can now gladly launch a web browser and discern the victim’s account information.

Obviously, if your system hosts sensitive information, the hacker now has been given access to it.

The malicious actor can also utilize the web application in the same way the victim can. Your application discerns both users as valid and logged in. The application will not discover any security problems, and the victim is completely unmindful that someone else with malicious intentions is browsing his or her data.

Internal enterprise web applications are most vulnerable to these sorts of attacks. Blackhats are driven by financial motives. Thus they desire to gain access to a corporation’s web application in order to view sensitive customer information and steal it.

How Does A Developer Protect From A Session Fixation Attack?

Equipped with an awareness of how session fixation works, you may then design the security area of your website to stop these attacks.

You are aware that the malicious intruder genuinely logs into the system, but the security defect in your workflow is the important fact that you are using a session ID without substantiating its validity.

Let’s first examine an example URL a blackhat would send to an incautious target:

The target clicks the aforementioned link and opens your web application. The victim now has to log in.

What we must do first in stopping a session fixation attack is to first invalidate the current session ID. You invalidate the session ID right after the victim logs in. After the victim logs in, you then distribute a new session ID to the connection. This kind of coding shields the user after he or she logs in particularly if the target doesn’t recognize the malicious activity.

The target is still capable of logging in, but the hacker’s session is no longer valid which indicates that the attack has been stopped.

It is recommended that the server administrator prescribes a defined amount of time for a session to time out.

Every application is distinct. Some applications like banking software will clearly time out quickly since leaving it open for extended time periods renders it to greater security threats.

More sympathetic applications keep sessions open for many hours or even days.

The amount of time that is left open for a session timeout has an impact on the success of session fixation. Short timeout sessions will stop session fixation attackers due to the hacker not having enough time to log in and deceive the victim into clicking the URL.

The timeout period ought to be set long enough to permit the user to freely utilize the application. However, there must be a balance where it is not long enough to let session fixation to occur.

Amalgamating session timeouts with invalidating session IDs during the login process is the best way to defend against these sorts of attacks.

Developers usually leave the session ID in the query string because it is convenient. This convenience also opens up a security flaw. Instead of situating the string in a URL, employ a form’s hidden variables or cookies. Nonetheless, this still doesn’t end the halt the attacker from deploying these methods, but it renders them to devise further tactics to trick the target.

For example, the malicious actor may create a phishing website that retrieves the session ID, places a cookie and then deceives the target into logging into the real application. This is an additional step that could notify the user to the scam which makes it much more arduous on the blackhat.

When strategies are implemented to make it more difficult for the intruder, he will usually want to find an easier and less secure web application.

Other Methods To Defend Against Cyber Attacks

Users don’t grasp session fixation. Hence it’s probable that they will click on any clicks sent to their email. Nevertheless, you may still enlighten users by adding some educational material to your website that informs them of the typical dangers and red flags associated with cyber attacks.

Informed users drastically reduce the risk involved in hosting a web application.

It is recommended that you also set up an email address or customer service hotline/form where a susceptible user may report a possible phishing attempt. There is a real possibility that the malicious actor targets many of your users and not merely one.

The adversary has a higher success rate if hundreds of the users receive the malicious URL instead of only one person receiving it. Employees are also subject to session fixation attacks, hence make use of email filters that block dubious emails. It’s also vital to enlighten employees about the potential perils of clicking dubious links in emails. The criminal typically sends a short message accompanied by a URL.

Some adversaries even hack email accounts and utilize them to send out harmful phishing emails. When the email originates from a trusted source, the attack yields a higher success rate.

Remember To Always Code With Security As A Priority Concern

We know that not all programmers are security experts. Therefore we shouldn’t carry the expectation that they know all of the attacks in the wild.

Malware is regularly released into the wild every day. Thus, programmers must keep up-to-update on the most recent attack vectors to protect the web application.

As with any web application, collaboration with a cyber security expert on penetration testing various modules and assure that it isn’t susceptible to session fixation. Make sure to log all events where security is a problem including login attempts. With the correct security reviewer and programmer education, a web application has a significantly lesser chance of falling victim to session fixation attacks.

You Might Also Like

Back to top
%d bloggers like this: