Blog

Coders Conquer Security OWASP Top 10 API Series - Broken Authentication

Matias Madou, Ph.D.
Published Sep 16, 2020

It's no wonder that broken authentication made the OWASP list for API problems - authentication mechanisms are notoriously difficult to implement correctly. Also, attackers have a little bit of an advantage because by their very nature most authentication challenges must be exposed to users, giving attackers a chance to study them and look for patterns or vulnerabilities that they can exploit.

Finally, because authentication often acts as a gateway to both an application and potentially to the rest of a network, they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

So, in this chapter, we're going to learn how to shut the bad guys out when it comes to authentication issues. If you want to test your skills first, head over and play our gamified challenge:

Want to improve your score? Stay with me while we break it down.

What are some examples of broken or misconfigured authentication?

One example where the problem might not be so obvious is when an authentication method is vulnerable to credential stuffing, or using lists of known usernames and passwords to break security. Even a normally very secure authorization method, like multifactor authentication, might be vulnerable if requests are not limited, throttled, or otherwise monitored.

For example, an attacker could trigger a password recovery request by sending a POST request to /api/system/verification-codes and providing a username in the request body. If an app is using an SMS text message challenge where a six-digit code is sent to a user's phone, but the input field is not limited, the application can be broken into in just a few minutes. An attacker simply needs to send every possible six-digit combination into the application until they hit the correct one.

In that scenario, on the surface, it looks like having two-factor authentication will keep an application safe. But because the user input isn't rate limited, the authentication is broken and vulnerable.

In another example, an application might use encoded user objects as authentication cookies. But if an attacker with low-level user access decodes that cookie using Base64, they could discover how the cookie defines sessions and users to the application. For example, they may see the following JSON once decoded:

{
"username" : "ShadyGuy",
"role" : "user"
{

At that point, the malicious user could change their username, role, or both. They could become another user with a higher privilege level by changing a couple of values:

{
"username" : "GoodGuy",
"role" : "admin"
{

At that point, if the attacker recodes the information and sets it as the cookie value, they essentially become the new user with a higher permission level. Unless methods are in place to prevent a change like that, there is a good chance the application will accept the transformation.

Eliminating Broken or Misconfigured Authentication

If authentication fails, there is a good chance that security across the board will be compromised. But following a few important guidelines while coding applications can help to keep everything secure.

First off, be sure to include authentication checks everywhere that allow users to access program functionality. If the authentication check doesn't exist at all, then the battle is lost from the start.

In terms of best practices, one good thing to keep in mind is to avoid exposing session IDs in the URL that is accessible to users. In the second example above regarding broken authentication, keeping an attacker from trying to decode the session cookie is a lot easier if it's never exposed to them.

It's also a good idea to implement multifactor authentication. This can be done securely using hardware tokens that algorithmically generate passwords on tight schedules. If you aren't able to provide your users with devices like that, SMS text messages can also work. But you need to make sure that user requests are limited to something reasonable like three or four tries in a 30 second period, and that the codes expire all together after only a few minutes. Using an alphanumeric code can also improve security by adding letters and numbers to potential passwords.

Finally, if possible, avoid depending on user names or predictable sequential values as session IDs. Instead, use a secure server-side session manager that generates a random session ID each time.

Implementing secure authentication methods is a little more tricky than combatting the average vulnerability. But because authorization is so important to every application, program, and API, it's worth taking extra time to make sure that you get it right.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


View Resource
View Resource

Authentication often acts as a gateway to both an application and potentially to the rest of a network, so they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

Interested in more?

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

Book a demo
Share on:
Author
Matias Madou, Ph.D.
Published Sep 16, 2020

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Share on:

It's no wonder that broken authentication made the OWASP list for API problems - authentication mechanisms are notoriously difficult to implement correctly. Also, attackers have a little bit of an advantage because by their very nature most authentication challenges must be exposed to users, giving attackers a chance to study them and look for patterns or vulnerabilities that they can exploit.

Finally, because authentication often acts as a gateway to both an application and potentially to the rest of a network, they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

So, in this chapter, we're going to learn how to shut the bad guys out when it comes to authentication issues. If you want to test your skills first, head over and play our gamified challenge:

Want to improve your score? Stay with me while we break it down.

What are some examples of broken or misconfigured authentication?

One example where the problem might not be so obvious is when an authentication method is vulnerable to credential stuffing, or using lists of known usernames and passwords to break security. Even a normally very secure authorization method, like multifactor authentication, might be vulnerable if requests are not limited, throttled, or otherwise monitored.

For example, an attacker could trigger a password recovery request by sending a POST request to /api/system/verification-codes and providing a username in the request body. If an app is using an SMS text message challenge where a six-digit code is sent to a user's phone, but the input field is not limited, the application can be broken into in just a few minutes. An attacker simply needs to send every possible six-digit combination into the application until they hit the correct one.

In that scenario, on the surface, it looks like having two-factor authentication will keep an application safe. But because the user input isn't rate limited, the authentication is broken and vulnerable.

In another example, an application might use encoded user objects as authentication cookies. But if an attacker with low-level user access decodes that cookie using Base64, they could discover how the cookie defines sessions and users to the application. For example, they may see the following JSON once decoded:

{
"username" : "ShadyGuy",
"role" : "user"
{

At that point, the malicious user could change their username, role, or both. They could become another user with a higher privilege level by changing a couple of values:

{
"username" : "GoodGuy",
"role" : "admin"
{

At that point, if the attacker recodes the information and sets it as the cookie value, they essentially become the new user with a higher permission level. Unless methods are in place to prevent a change like that, there is a good chance the application will accept the transformation.

Eliminating Broken or Misconfigured Authentication

If authentication fails, there is a good chance that security across the board will be compromised. But following a few important guidelines while coding applications can help to keep everything secure.

First off, be sure to include authentication checks everywhere that allow users to access program functionality. If the authentication check doesn't exist at all, then the battle is lost from the start.

In terms of best practices, one good thing to keep in mind is to avoid exposing session IDs in the URL that is accessible to users. In the second example above regarding broken authentication, keeping an attacker from trying to decode the session cookie is a lot easier if it's never exposed to them.

It's also a good idea to implement multifactor authentication. This can be done securely using hardware tokens that algorithmically generate passwords on tight schedules. If you aren't able to provide your users with devices like that, SMS text messages can also work. But you need to make sure that user requests are limited to something reasonable like three or four tries in a 30 second period, and that the codes expire all together after only a few minutes. Using an alphanumeric code can also improve security by adding letters and numbers to potential passwords.

Finally, if possible, avoid depending on user names or predictable sequential values as session IDs. Instead, use a secure server-side session manager that generates a random session ID each time.

Implementing secure authentication methods is a little more tricky than combatting the average vulnerability. But because authorization is so important to every application, program, and API, it's worth taking extra time to make sure that you get it right.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


View Resource
View Resource

Fill out the form below to download the report

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Submit
To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.

It's no wonder that broken authentication made the OWASP list for API problems - authentication mechanisms are notoriously difficult to implement correctly. Also, attackers have a little bit of an advantage because by their very nature most authentication challenges must be exposed to users, giving attackers a chance to study them and look for patterns or vulnerabilities that they can exploit.

Finally, because authentication often acts as a gateway to both an application and potentially to the rest of a network, they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

So, in this chapter, we're going to learn how to shut the bad guys out when it comes to authentication issues. If you want to test your skills first, head over and play our gamified challenge:

Want to improve your score? Stay with me while we break it down.

What are some examples of broken or misconfigured authentication?

One example where the problem might not be so obvious is when an authentication method is vulnerable to credential stuffing, or using lists of known usernames and passwords to break security. Even a normally very secure authorization method, like multifactor authentication, might be vulnerable if requests are not limited, throttled, or otherwise monitored.

For example, an attacker could trigger a password recovery request by sending a POST request to /api/system/verification-codes and providing a username in the request body. If an app is using an SMS text message challenge where a six-digit code is sent to a user's phone, but the input field is not limited, the application can be broken into in just a few minutes. An attacker simply needs to send every possible six-digit combination into the application until they hit the correct one.

In that scenario, on the surface, it looks like having two-factor authentication will keep an application safe. But because the user input isn't rate limited, the authentication is broken and vulnerable.

In another example, an application might use encoded user objects as authentication cookies. But if an attacker with low-level user access decodes that cookie using Base64, they could discover how the cookie defines sessions and users to the application. For example, they may see the following JSON once decoded:

{
"username" : "ShadyGuy",
"role" : "user"
{

At that point, the malicious user could change their username, role, or both. They could become another user with a higher privilege level by changing a couple of values:

{
"username" : "GoodGuy",
"role" : "admin"
{

At that point, if the attacker recodes the information and sets it as the cookie value, they essentially become the new user with a higher permission level. Unless methods are in place to prevent a change like that, there is a good chance the application will accept the transformation.

Eliminating Broken or Misconfigured Authentication

If authentication fails, there is a good chance that security across the board will be compromised. But following a few important guidelines while coding applications can help to keep everything secure.

First off, be sure to include authentication checks everywhere that allow users to access program functionality. If the authentication check doesn't exist at all, then the battle is lost from the start.

In terms of best practices, one good thing to keep in mind is to avoid exposing session IDs in the URL that is accessible to users. In the second example above regarding broken authentication, keeping an attacker from trying to decode the session cookie is a lot easier if it's never exposed to them.

It's also a good idea to implement multifactor authentication. This can be done securely using hardware tokens that algorithmically generate passwords on tight schedules. If you aren't able to provide your users with devices like that, SMS text messages can also work. But you need to make sure that user requests are limited to something reasonable like three or four tries in a 30 second period, and that the codes expire all together after only a few minutes. Using an alphanumeric code can also improve security by adding letters and numbers to potential passwords.

Finally, if possible, avoid depending on user names or predictable sequential values as session IDs. Instead, use a secure server-side session manager that generates a random session ID each time.

Implementing secure authentication methods is a little more tricky than combatting the average vulnerability. But because authorization is so important to every application, program, and API, it's worth taking extra time to make sure that you get it right.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


Interested in more?

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Click on the link below and download the PDF of this one pager.

Download

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

View reportBook a demo
Share on:
Interested in more?

Share on:
Author
Matias Madou, Ph.D.
Published Sep 16, 2020

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Share on:

It's no wonder that broken authentication made the OWASP list for API problems - authentication mechanisms are notoriously difficult to implement correctly. Also, attackers have a little bit of an advantage because by their very nature most authentication challenges must be exposed to users, giving attackers a chance to study them and look for patterns or vulnerabilities that they can exploit.

Finally, because authentication often acts as a gateway to both an application and potentially to the rest of a network, they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

So, in this chapter, we're going to learn how to shut the bad guys out when it comes to authentication issues. If you want to test your skills first, head over and play our gamified challenge:

Want to improve your score? Stay with me while we break it down.

What are some examples of broken or misconfigured authentication?

One example where the problem might not be so obvious is when an authentication method is vulnerable to credential stuffing, or using lists of known usernames and passwords to break security. Even a normally very secure authorization method, like multifactor authentication, might be vulnerable if requests are not limited, throttled, or otherwise monitored.

For example, an attacker could trigger a password recovery request by sending a POST request to /api/system/verification-codes and providing a username in the request body. If an app is using an SMS text message challenge where a six-digit code is sent to a user's phone, but the input field is not limited, the application can be broken into in just a few minutes. An attacker simply needs to send every possible six-digit combination into the application until they hit the correct one.

In that scenario, on the surface, it looks like having two-factor authentication will keep an application safe. But because the user input isn't rate limited, the authentication is broken and vulnerable.

In another example, an application might use encoded user objects as authentication cookies. But if an attacker with low-level user access decodes that cookie using Base64, they could discover how the cookie defines sessions and users to the application. For example, they may see the following JSON once decoded:

{
"username" : "ShadyGuy",
"role" : "user"
{

At that point, the malicious user could change their username, role, or both. They could become another user with a higher privilege level by changing a couple of values:

{
"username" : "GoodGuy",
"role" : "admin"
{

At that point, if the attacker recodes the information and sets it as the cookie value, they essentially become the new user with a higher permission level. Unless methods are in place to prevent a change like that, there is a good chance the application will accept the transformation.

Eliminating Broken or Misconfigured Authentication

If authentication fails, there is a good chance that security across the board will be compromised. But following a few important guidelines while coding applications can help to keep everything secure.

First off, be sure to include authentication checks everywhere that allow users to access program functionality. If the authentication check doesn't exist at all, then the battle is lost from the start.

In terms of best practices, one good thing to keep in mind is to avoid exposing session IDs in the URL that is accessible to users. In the second example above regarding broken authentication, keeping an attacker from trying to decode the session cookie is a lot easier if it's never exposed to them.

It's also a good idea to implement multifactor authentication. This can be done securely using hardware tokens that algorithmically generate passwords on tight schedules. If you aren't able to provide your users with devices like that, SMS text messages can also work. But you need to make sure that user requests are limited to something reasonable like three or four tries in a 30 second period, and that the codes expire all together after only a few minutes. Using an alphanumeric code can also improve security by adding letters and numbers to potential passwords.

Finally, if possible, avoid depending on user names or predictable sequential values as session IDs. Instead, use a secure server-side session manager that generates a random session ID each time.

Implementing secure authentication methods is a little more tricky than combatting the average vulnerability. But because authorization is so important to every application, program, and API, it's worth taking extra time to make sure that you get it right.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.


Table of contents

View Resource
Interested in more?

Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.

Book a demoDownload
Share on:
Resource hub

Resources to get you started

More posts
Resource hub

Resources to get you started

More posts