In my work performing Web security assessments, I come across a lot of interesting issues. Many things are minor, but quite a few are a big deal. In this tip I cover some big-deal Web authentication vulnerabilities I've seen, such as login weaknesses, and offer some ways developer, QA or security professionals can fix them.
One of the biggest Web-based authentication weaknesses I've seen involved an Internet Explorer browser helper object that provided access into a sensitive back-end system. Basically the login mechanism evaluated the user's Windows login status and ID and assuming they were logged in on the machine with a valid account access was granted without any further authentication into the application.
Interestingly, I found that this "authentication" process could be manipulated using a Web proxy in order to gain unauthorized access into the environment. All you had to do is edit the Windows user ID field that was passed in the HTTP requests and simply insert a known good user ID, say "jsmith". From that point on, the Web proxy could be taken out of the loop and free and clear access was provided into the system until the browser was closed. Ouch.
Moral of the story: Authentication logic that can be manipulated by a user such as this is hardly a good idea. Furthermore, never assume that just because some has logged into the local OS using a valid account means that they're authorized to access the Web application.
In another situation, I was analyzing the multi-factor authentication system for an application that provided access to highly-sensitive information. The intruder lockout mechanism utilized a control variable that could be reset by the user via Web proxy or a script. This effectively negated any benefits derived from the multi-factor system – especially the intruder lockout piece!
Moral of the story: Don't send login control variables that can be modified by the user.
Another interesting Web authent...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
ication vulnerability I came across basically allowed user names consisting of all numbers anywhere from two to 10 characters and passwords that could have all the same numbers such as 55555. This weakness facilitated user account harvesting and password cracking very quickly using automated scanning tools, especially given that no intruder lockout mechanism was in place.
Moral of the story: Always require complex passwords and user names that can't be guessed by simply incrementing a number. Intruder lockout after 10-15 failed attempts is a good thing as well.
Interestingly, after all these years hearing "passwords are important," I still see Web applications that don't have any sort of password complexity requirements. I recently came across an application that allowed users to only have a single number or letter as their passwords. Think about it. If password complexity requirements are not enforced what kind of passwords do you think users going to choose?
On a similar note, another issue I come across quite often is demo and guest accounts with weak passwords or no passwords at all. These are accounts that are typically setup by sales reps, account managers, or marketing folks for ease of use when demonstrating the application. Security's not really on their radar but, as you can imagine, providing such simple access can lead to situations where competitors and others with malicious intent can gain access and do things in your environment that you probably don't want them doing.
Moral of the story: Set everyone up for success and require complex passwords (ideally passphrases for all accounts regardless of their role or purpose. Furthermore ensure that intruder lockout is enabled like I mentioned above. The latter may create more work for your help desk but it's better than allowing anyone and everyone free reign to try and break into your Web systems.
I also find weaknesses in Web systems that are overlooked or otherwise deemed non-critical. For example, I uncovered a weak password for an Outlook Web Access user account when assessing the security of an email environment. What I thought was going to be an otherwise unexciting security assessment ended up being extended by day or two as I perused Microsoft Exchange public folders containing sensitive internal documents (many of which were ironically labeled Internal Use Only), captured other user's email addresses, and cracked the relatively weak passwords on a dozen or so other accounts.
Moral of the story: Web security should mean Web security that takes every Web-based system into account and not just the custom-written sites and applications that get the most attention.
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at www.principlelogic.com.
