Web applications are often targeted by malicious attackers. These applications are publicly accessible—or at least, their login pages are—and it’s not difficult for a determined attacker to find sites with security flaws. Attackers often try to exploit login page security vulnerabilities in a web application to cause excessive load and potentially bring the site down.
One such vulnerability can be found in the security question page which is part of many login flows. In this post, we’ll look at this scenario, examine why it’s an issue, and provide guidance on how to mitigate that security risk.
The Login Page with a Blank Security Question
Login page security vulnerabilities are more common than you might think. In the login process for many websites and applications, an additional verification safeguard extends the traditional username/password step for increased security. Imagine a two-step login flow. In the first step, the site asks you for a username and password combination. If you enter these credentials correctly, then the second step asks you to answer a security question (which you specified when you first set up your account).
This second step is typically built from a page view template that inserts the security question based on the user who has successfully completed the first step. The entire two-step login flow basically works like this:
- Alice visits the login page at https://www.example.com/login.
- Alice submits a username and password combination.
- The server verifies the submitted credentials.
- Because the credentials were correct, the server redirects the browser to the follow-up page at https://www.example.com/login2, including a unique token in the request header to verify that Alice has passed the first step of the login flow.
- The server renders this page based on a template, inserting the fetched security question for Alice, alongside the text input for a response and a submit button.
- Alice submits the response to her security question.
- The server verifies that Alice answered her security question correctly and then logs her in.
Let’s focus on that second page of the flow, at https://www.example.com/login2. Imagine what might happen if you visited that page directly in your browser, without going through the first step.
In one scenario, it’s possible that the server checks to see if there is no valid token in the request header (meaning you did not successfully pass the first step of the login flow), and it simply redirects you back to https://www.example.com/login in order to start over.
However, in another possible scenario, the server still renders the page based on the template. Unable to find a corresponding security question for the user (since there’s no token that tells the server which halfway-authenticated user this is), the resulting page might look like this:
You’re left with an awkward security question page that has… no security question. Talk about a pointless page.
Pointless, yes. But harmless? Don’t be so sure.
The Security Implications
Continuing with this scenario, what would happen when you (or a person more malicious than you) submit an answer to this “security question”? The server will devote CPU cycles to evaluate your answer. It will process the text input, look for the unique token in the request header, and possibly even execute a database query in an attempt to validate your answer.
A login page with a blank security question might seem minor (What’s wrong with a few wasted CPU cycles here and there?), but it can lead to serious security issues.
- Wasted backend processing resources: Processing pointless form submissions consumes networking and computing resources—and possibly database resources, too.
- Potential for denial of service (DoS) attacks: An attacker could set up a botnet to send form submissions repeatedly, overloading the system.
- Increased vulnerability: A successful DoS attack could bring down your entire system.
If attackers can exploit this weakness to waste a server’s processing power, they could potentially disrupt services for legitimate users and expose the system to further attacks.
Not so harmless after all.
Let’s look at how to address vulnerabilities like these in order to maintain the security and reliability of your applications.
How to Defend
For this specific scenario, the server that handles the login2 endpoint should verify the existence of a valid token in the request header. Without a proper token, no further processing should take place, and the user should be redirected to the first step of the login flow. This way, you minimize the resources used to handle the request gracefully, much like you for a 404 or a 401.
However, this scenario highlights a more general security concern that you should look out for: repeated requests which burden your server with an excessive load. Certainly, exploiting a pointless login page with a blank security question can overload your server more quickly because of the amount of processing resources used. But a botnet can also hit your perfectly normal username/password login page with excessive requests too.
To protect your web applications from these kinds of attacks, implement the following measures:
- Use a web application firewall (WAF): A WAF can provide DoS protection and detect and block malicious bots, reducing the risk of automated attacks. Linode’s marketplace of apps includes the Haltdos Community WAF which could help you with this.
- Implement rate limiting: Limit how many requests a single IP address can make within a given window of time. With rate limiting, you’ll prevent attackers (and bots) from flooding your system with requests.
- Enable monitoring and alerting: Continuous monitoring tools can be on the lookout for suspicious request patterns, alerting you in real time to potential attacks. When you’re notified immediately, you can respond and mitigate an issue quickly.
Conclusion
We’ve looked at the case of a login page with a blank security question. At first glance, it looks like a strange edge-case page that’s ultimately pointless. But attackers can exploit vulnerabilities like these to waste your resources and potentially bring down your system. The security question page is just one example of such a vulnerability.
If you design your applications with security in mind and adopt secure coding practices, then you’re off to a good start. However, your applications also need security measures implemented at the system and infrastructure level—such as using a WAF, rate limiting, continuous monitoring, and alerts. With the proper security measures in place, you can significantly reduce your risk of being targeted by such attacks.
For more guidance and tips on securing your applications, check out the Linode docs, with its rich library of security-related guides. There, you’ll find helpful resources to direct you in how to protect your systems and your users.
Comments