Web developers don’t always think like hackers, which is why so many common cloud applications suffer from security flaws. Software development and security expertise are two separate fields under the IT umbrella, so demanding a flawless security design from your developers is unreasonable. The developer must work with a security expert to ensure that deployed applications are secure. If you’re on your own and don’t have a security expert to help, here is how a hacker can exploit your system using session fixation and how you can stop it.
Do You Use Sessions in Your Application?
If your system has a secure, private area where users must log in, the answer to this question is “Yes.” Sessions are unique server variables that identify users. They are long, alphanumeric values that are unique to the user. Once the user no longer needs to use the application, the session times out and it’s removed as a valid token.
You can store your session in a variety of ways. Some developers store sessions in cookies and others store them in hidden form variables. Some users block cookies, which means that sessions can’t be stored. This problem stops the application from running properly in the user’s browser. Since this is a problem that can’t be controlled from the server’s side, coders usually choose to store session information in hidden form variables or in URL query strings. This eliminates the chance that users blocking cookies can’t use the application.
How Does a Session Fixation Attack Work?
Since developers store session IDs in ways that can be viewed by standard users, the attacker can get an assigned session ID by just logging into your system. The following steps occur during a session fixation attack.
1. The attacker logs into your application and obtains a valid session ID.
The attack starts off innocently enough. The attacker logs in with a valid username and password. You check the credentials in your application, it determines that they are legitimate, and a session ID is assigned to the attacker. This session ID can be stored in a cookie or in a hidden variable. The attacker can see the value with any storage option, so you shouldn’t worry about how you store the session. You can also use it in a query string variable, although this is the less desirable option for most developers.
2. The attacker sends a malicious link to the target victim.
In most applications, the developer detects if a session ID is available in a query string to identity if the user is already logged in. If the session variable is used in a form POST method, then the attacker identifies this method too before sending an email to the victim. The attacker sends a malicious link to the victim depending on the way you set up session identification. If it’s a simple query string method, the attacker sends a malicious link to the victim. If it’s using a form POST method, the attacker must trick the user into sending a POST submission to your cloud application. A POST submission happens when users click the “Submit” button in your website forms. Regardless of the method, step two in an attack is always sending a phishing email to the user.
3. The victim clicks the link to your web application For simplicity, assume that the session variable is sent using a query string variable in a malicious link to the user. The attacker sends a link to the victim with his own session ID in the URL. The user clicks the malicious URL, and this is the first part of the attack. Your application detects the session ID as valid and then asks the user to log in. Since the user is on the official website, usually the user will then log in unsuspecting of any malicious activity.
4. The attacker now has access to the user’s account. With the attacker’s session ID and the user logged into the application, the attacker can now open a web browser and see the user’s account information. Of course, if your application hosts sensitive information, the attacker now has access to it.
The attacker can also use the application in the same way the user can. Your application sees both users as valid and logged in. Your application won’t detect any security issues and the user is completely unaware that someone else is browsing his data.
Internal corporate cloud applications are the most susceptible to these attacks. Hackers want to gain access to a company’s cloud application so that they can view customer information and steal it.
What Can a Developer Do to Protect from an Attack?
With the knowledge of how session fixation works, you can then design the security section of your site to stop these attacks. You know that the attacker legitimately logs into the application, but the security flaw in your workflow is that you use a session ID without validating its validity.
First, take a look at an example URL a hacker would send to an unsuspecting victim.
The user clicks the link and opens your application. The user now needs to log in. The first way to stop a session fixation attack is to first invalidate the current session ID. You invalidate the session ID directly after the user logs in. After the user logs in, you then assign a new session ID to the connection. This type of coding protects the user after he logs in especially if he doesn’t detect the malicious activity. The user is still able to log in, but the attacker’s session is no longer valid and the attack is stopped.
The server administrator should also set a specific amount of time for a session to time out. Each application is different. Some applications such as banking software times out quickly, because leaving it open is a security threat. More benign applications keep sessions open for hours or even days.
The amount of time you leave open for a session timeout has an effect on session fixation success. Short timeout sessions stop session fixation attacks, because the attacker doesn’t have enough time to log in and trick the victim into clicking the URL. The timeout period should be set long enough to allow the user to freely use the application, but not long enough to allow session fixation to happen. Combining session timeouts with invalidating old session IDs during the login process is the best method to defend against these types of attacks.
Finally, it’s common for developers to leave the session ID in the query string. It’s convenient, but it’s also a security flaw. Instead of placing the string in a URL, use a form’s hidden variables or cookies. It still doesn’t stop the attacker from using these methods, but it causes them to take extra steps to trick the user. For instance, the attacker could create a phishing website that obtains the session ID, places a cookie and then tricks the user into logging into the real system. This is one extra step that could alert the user to the scam, so it makes it much more difficult on the attacker. Making it more difficult sometimes persuades the attacker to choose an easier, less secure application.
Other Ways to Defend Against Cyber Attacks
Users don’t understand session fixation, so it’s likely that they will click any link sent to their email addresses. However, you can still educate users by adding some content to your site that warns them of the common dangers and red flags surrounding cyber attacks. Educated users greatly reduce the risk involved in hosting a cloud application.
You should also set up an email address or customer service contact form where a user can report a possible phishing attack. Chances are that the attacker targets several of your users and not just one. The hacker has a better chance of success if 100 users receive the malicious URL rather than just sending it to one person.
Employees can fall victim to session fixation attacks, so use email filters that block suspicious emails. It’s also important to educate employees about the dangers of clicking suspicious links in email. The attacker usually sends a short message with the URL.
Some attackers even hack email accounts and use them to send the malicious phishing emails. Since the email comes from a trusted source, the attack has a higher chance of success.
Always Code with Security in Mind
Coders aren’t security experts, so they can’t be expected to know every attack in the wild. Malware is released into the wild everyday, so coders must keep up-to-date on the latest attack methods to protect the application.
With any cloud application, work with a security expert to penetration test different modules and ensure that it isn’t vulnerable to session fixation. Log any events where security is an issue including login attempts. With the right security review and coder education, a cloud application has a much smaller chance of becoming a victim of session fixation.