Security.com

Common web application login security weaknesses and how to fix them

By Kevin Beaver

Web applications are at the core of enterprise IT assets, functionalities and business workflows. From ERP systems to online banking to electronic health records systems, there's a critical web application that's hosted on premises or in the cloud in virtually every enterprise.

At some point, many of these web applications end up with flaws such as cross-site scripting and SQL injection. These are regularly found and, presumably, resolved. But there's one set of weaknesses in particular that's taken for granted and often overlooked during typical vulnerability scanning and penetration testing exercises. Those weaknesses are associated with the application login mechanism.

Here are some common flaws with application login security that come up in every web security assessment and issues for which enterprises need to be on the lookout:

• Lack of intruder lockout. This flaw enables attackers to attempt to crack passwords using any number of automated tools or manual processes. The common argument against intruder lockout is the time and effort associated with legitimate user lockouts. This is a problem, but why not just develop a process and code that can automate the password reset function?

  Many applications still approach this the old-fashioned way and require users to call into the help desk, which is a bad idea. As long as password reset questions cannot all be set to the same question-answer combination -- something that happens often -- or the process isn't easily abused otherwise, the business benefits of intruder lockout are much greater than any confirmed or perceived risks.

• Descriptive error messages. These error messages are displayed when incorrect application login credentials are entered.

  Building on the lack of intruder lockout, if web developers provide details on what, exactly, they entered incorrectly, such as "You've entered an incorrect user name" or "You've entered the wrong password associated for this account," it gives attackers a leg up on what to try and what not to try during their password cracking attempts.

• Weak password requirements. Further facilitating password cracking are weak password requirements. Some web applications still allow passwords such as 111111 and abc123. Look at any of the security studies that come out every year and you'll see that weak passwords are a top contributor to security incidents and breaches.

  Why is this still an issue? It's possible that it's politics -- management (in most cases) kowtowing to users. The argument "But our users won't like stringent password requirements" is dated and flawed. Passwords are not dead and won't be for at least the coming few decades. It's time to fix this issue once and for all.

  Require strong passwords and you'll have the ammunition you need to stop those ridiculously short password change requirements. If your application is for third parties to use in a cloud scenario, at least provide the option for strong passwords so that you can show that customers or users have the choice in the event of an incident.

• Password complexity that's not enforced. It's one thing to tell your users that uppercase letters, numbers and special characters are required, but quite another to actually enforce this. Some web applications still say one thing during the initial user setup and password reset process, but allow for another. Make sure that any standards or policies are properly implemented. Otherwise, your users will take the path of least resistance.
• Application logins that are not protected by TLS encryption. Arguably, one of the riskiest application login-related vulnerabilities is when web communication sessions are unencrypted. It's bad enough to have SSL and older versions of TLS with known vulnerabilities to man-in-the-middle attacks. But to allow logins into core business applications, content management systems and other enterprise systems with no encryption at all shows a lack of due care and is asking for trouble.

  All it takes to ultimately expose your entire network is for a user to log in to such a system via public Wi-Fi or some other vulnerable vector. One set of credentials is often all that's needed for someone to get a foot in the door of your internal network, and you'll likely never even know about it.

Some people say that multifactor authentication, single sign-on and the like will solve these traditional web application login security flaws. Maybe they're right, but unless and until all business applications are protected with these controls, we'll continue seeing weaknesses -- and exploitations -- in the web application login process. The most important factor is identifying these vulnerabilities, and the next most important factor is fixing them. These are obvious steps, yet they're taken for granted -- especially the resolution part.

Make sure that you're doing the proper web application testing that includes both unauthenticated and authenticated vulnerability scans using dedicated web vulnerability scanners such as Netsparker and Acunetix Web Vulnerability Scanner, and not simply relying on traditional network vulnerability scanners. Purpose-built web scanners find many more -- and more important -- web flaws.

Still, these common web application login weaknesses are just as easily discovered through manual analysis using a good old-fashioned web browser; an integrated tool set, such as Firefox Web Developer; and maybe an HTTP proxy.

Look at the login process -- including initial user setup and password changes -- from the perspective of an attacker with ill-intent, and you're bound to find login- and even user session management-related weaknesses. Start today. It's better for your enterprise to find and fix these flaws on its own terms than someone else's.