A common finding in web applications we test is ‘Application Supports Simultaneous Logins’. This finding occurs when both of the following conditions are met:
The application allows for multiple sessions at the same time, from different devices, browsers, etc.
The application does not alert the user to the multiple sessions through:
Email notification,
Notification inside the application, or
A session management page inside the application.
Essentially, this boils down to the user being allowed to have multiple sessions without a way to manage them or see other active sessions through notifications or otherwise.
What does this look like?
In practice, we look in several locations for the functionality to manage sessions, but the most common place we find it is in profile sections or settings. When these are not available, we’ll log in on two separate browsers — or on two devices — and navigate them both to the settings page, checking for notifications or other session management abilities. An example of multiple sessions without notification to the user in a popular online platform is shown below:
Why does this matter?
Allowing simultaneous sessions seems innocuous at first. I mean, we mostly all have multiple devices that we log in through, right? True, but the lack of insight into your account’s session management becomes a problem if your session is somehow stolen, credentials are obtained, or your account is otherwise compromised through other vulnerabilities. If multiple sessions are allowed without notification to the user, there is no way for the user to know that their account has been compromised or to terminate the active sessions that have been compromised.
Remediations
In today’s world, disallowing multiple sessions is likely not realistic due to business constraints. Most people have several devices themselves, and logging in to an application on multiple is common, so this likely needs to be a feature in your application. However, alerting the user or allowing them to view their active sessions is important so they can maintain control of their account in the event of a breach. There are several ways to do this, with varying functionality, including:
Showing users active sessions with details about the session
Allowing users to terminate specific sessions
Providing functionality to log out the user from all other devices
Combine any of the above when the account password is changed
These are all valid approaches, but the specific one you choose to implement will depend on your application’s use cases, business constraints, and design. In our Raxis One application, we provide the user both with details about their active sessions, functionality for terminating specific sessions, and a session history that includes IP Address and location details, as shown in below:
People are often surprised to find that a hacker doesn’t only attack a website through the authentication process. Our team members are experts at demonstrating why just enforcing password policies and lockout times doesn’t fully protect applications.
In this article, we’re going to pull back the curtain and show you how hackers use web proxy tools to help exploit applications in ways you might never expect.
How the Proxy Tool Works
The proxy tool is software that follows the path data takes step-by-step from your device to the application server. Several such tools exist, but Burp Proxy (included in all versions of Burp Suite) is one of the most popular. Using Burp Proxy, hackers can bypass the user interface – the page you see when entering data – and change the information before it is sent to the application server. This makes it possible to avoid client-side controls, such as those that check that a phone number is only numeric or that an email address is formatted correctly. If the application server expects the client-side controls to have already validated data, the server code may not have all of the proper protections in place.
In the image below, Burp Proxy, in “Intercept” mode, shows each step along the path that data follows from your device to an application server. The tool allows a user to tab from step to step and change the data that was input originally. If security features are built into the client (the interface you see) but not present on the application server, the proxy enables hackers to enter compliant data first, but change it however they want before it reaches the server.
One example of how hackers exploit this setup is through the commonly used buttons or checkboxes found in many apps. Most app developers are cautious about user input fields, but, because buttons, checkboxes, and radio buttons apparently limit data entry to “on-off” or “yes-no” choices, they often see little inherent risk. The problem is that, even though the user options are limited at the interface (client-side), they may not be limited by the code on the server itself (server-side).
How a Proxy Tool can Reveal a Vulnerability
The three illustrations below show how even a simple “submit” button can present opportunities for hackers.
The choice here seems straightforward — either you click the button or you do not. But that choice masks what happens after you click “submit.”
“Submit” is really just a request being sent to the server. Here, using Burp Proxy to intercept the data, we can see the request as it will appear to the application server.
Now, rather than a simple yes-or-no choice, a user can modify the data any way they’d like and enter it by pressing the “Forward” command.
How Hackers Turn the Exploit into an Attack
With the ability to effectively bypass safeguards on the client-side interface, hackers can send information directly to the application server. Here are a couple of examples of the types of attacks they can execute if the application server is not secure. (For clarity, we’ll use text-based fields, rather than check-boxes in these examples.)
Example 1: Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is a reflected attack that injects malicious client-side executable code into web application parameters to be returned by the application output and ultimately executed by the browser. Because it appears that the script is from a trusted source, the end-user’s browser accepts it and runs the script, permitting the attacker to take actions on the application’s behalf, such as accessing cookies and session tokens as well as other sensitive data. (Source: Raxis Glossary).
The following walk-through demonstrate how a simple guestbook submission form request works normally and then how an attacker can use a web proxy to insert malicious code.
This is the submission form as it appears to users:
Our Burp Proxy tool reveals the actual request sent to the application server:
Here the attacker enters an innocuous submission that should not be caught by client-side injection controls:
And now the attacker captures the entry using Burp Proxy:
Before allowing the proxy tool to move to the next step, the attacker replaces the original harmless data with a malicious script:
The application server, without server-side controls to stop it, accepts the script and returns the payload to the browser. This is what the attacker sees in Burp Proxy:
And here we see the successful cross-site scripting result in the browser:
Example 2: SQL Injection (SQLi)
In this attack, a SQL query is injected into the application via input parameters. A successful attack could read sensitive data from the database, modify data in the database, execute operations on the database (including administrative operations), recover files on the DBMS file system, or issue commands to the operating system. (Source: Raxis Glossary)
Here we demonstrate how a user ID field can be manipulated to enable a SQLi attack.
We start with a simple user ID entry field with a submit button where we enter a name and submit:
Again the attacker intercepts the submission using Burp Proxy en route to the application server.
As above in the XSS exploit, the attacker then modifies the data in Burp Proxy, this time to include escape characters and a SQL query:
With no server-side controls in place to stop the attack, the server returns the data requested in the SQL database query. This is what the attacker sees in Burp Proxy:
And here we see the successful SQL injection result in the browser:
Summary
It’s tempting here to focus on the Burp Proxy tool and its capabilities, but the more important point is to recognize that vulnerabilities can exist in places we as users might not think. Something that seems innocuous, like a simple submit or on/off button, can be manipulated by a hacker with relative ease. The same is true for any field, button, or widget that sends a request to an application server.
Remember that the mindset of a hacker is always to look at something as it’s expected to be used, then attempt to use it differently. That’s why pentesting by skilled professionals is so important. It takes trained, ethical hackers to prevent the work of their malicious counterparts.
Would you like to learn how Raxis can help your organization? Reach out. We have a guaranteed, no-pressure approach, and – after all – we’re all on the same side.
