Update: Broken Authentication has moved down the list to position #7 because it seems to be less of an issue due to increasing adoption of standardized frameworks. It’s now grouped together with identification failures in a new category called Identification and Authentication Failures in the proposed OWASP Top 10 2021.
The next vulnerability on OWASP’s Top 10 list is Broken Authentication, a broad category covering a wide range of security flaws. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.
Broken Authentication involves all kinds of flaws that are caused by error in implementations of authentication and/or session management. Due to the wide range of different vulnerabilities therein it is quite hard to define its general properties.
The category includes everything from login lacking timeout, meaning that users who forget to logout on a public computer can get hijacked, to more technical vulnerabilities such as session fixation.
Developers tend to write their own implementations of stuff related to authentication and session management. That is something that is hard to get right, which is why different kinds of flaws within this category are so common.
The goal of an attack is to take over one or more accounts, and for the attacker to get the same privileges as the attacked user. If the attacker successfully hijacks an admin account, the attacker could therefore do as much as an ordinary admin, which depending on the application could have a great impact.
As it is such a broad category it is impossible to say how hard it is to exploit. OWASP classifies the exploitability as average, but it really depends on the specific vulnerability. Some of the vulnerabilities that fall into this category can be automated, but many of them require the attacker to be manually involved in the attack.
One of the type of findings that falls into this category is storing passwords in plain text. If someone were to hack a service and get hold of the passwords in plain text, the attacker could use those credentials to log into the service as any user. As people tend to re-use passwords, an attacker could also try these credentials to log into other services.
One of the most known recent cases of what have been described above is when 000webhost got hacked last year. That leak alone meant 13 million credentials in plain text.
How to discover
Some of these vulnerabilities can be scanned for automatically, which Detectify does when possible. However, some of the vulnerabilities under this category are simply not possible to look for in an automatic way.
When searching for this kind of vulnerabilities, it is of great advantage to read all the source to get a better overview of the situation. As it is such a broad category as it is, the ways to look for these vulnerabilities vary as well.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable »
Example of a vulnerable application
A webshop put the session id in the url. The links will look like this: http://example.com/?product=chair&session=51233123
If the user likes that product and wants to share a link with a friend, they would copy the link without giving it much thought. When the friend then clicks on the links, they inherit the same session id and if they decide to buy something, the first user’s credit card will be charged.
Security needs to be part of the developing process from the beginning. That is the only way to ensure nothing can be abused in a way that was not thought about during developing, as those kinds of vulnerabilities are hard to look for afterwards.
Many of the vulnerabilities within the category exist because developers mess up in some way. It is possible to fight that problem by making it harder for developers to make mistakes. This can be done by creating simple APIs which prevent incorrect use that leads to vulnerabilities. There are also many solutions available that have already been tested, so it is a good idea to look into that before reinventing the wheel.
The last vulnerability that will be mentioned here, even though this category involves many more, are XSSes that can be used to steal session cookies. There are several ways to resolve these, or at least make them not quite as bad. We recommend two of our remediation documents: