Top 5 Security Considerations for a New Web App: 2. Authentication & Authorization

Welcome to my comprehensive series on the Top 5 Security Considerations for a New Web App. This post, focusing on Authentication and Authorization, is part of a broader effort to equip folks like you (developers, IT professionals, and web administrators) with essential security knowledge for proactively safeguarding their web applications. Throughout this series, we explore the critical security measures that are fundamental to the development and launch of a secure web application. For a complete overview and the context of this series, I invite you to read the Introduction post. This foundational understanding will enhance your grasp of why each consideration plays a vital role in the lifecycle of a web application in the initial buildout and the days immediately following the launch. Join me as we delve into the best practices, strategies, and real-world applications that underscore the importance of implementing robust security measures from the ground up.

Previous:1. Secure Coding Practices

2. Authentication and Authorization

In the intricate web of web application security, authentication and authorization stand as critical gatekeepers. These processes ensure that only legitimate users can access an application and that they can only perform actions within their permitted scope.

Authentication involves verifying a user's identity. This is often the first line of defense against unauthorized access. Key practices in robust authentication include:

• Strong Password Policies: Enforcing complex password requirements to prevent brute force attacks.
• Multi-Factor Authentication (MFA): Adding an extra layer of security by requiring additional verification methods beyond just a password.
• Session Management: Ensuring that user sessions are securely managed and terminated after inactivity or logout.

Authorization, on the other hand, determines what an authenticated user is allowed to do. It's about controlling user access levels and permissions within the application. Implementing role-based access control (RBAC) is a common and effective strategy in managing user permissions efficiently and securely.  For web applications, authorization is most commonly done using a bearer token or a cookie.  In implementations that aim to reduce or eliminate server-side state management for user sessions, bearer tokens typically use a signature to provide tamper resistance, which is critical to the trustworthiness of the token.

In addition to simply having authentication and authorization implemented in the application, it is important to ensure that the user-supplied credentials (e.g. username and password) and resulting values (e.g. session cookie, bearer token) are safely handled within the application.  The security provided by these controls is undermined if there is leakage of these values to other users within the app, or to third parties with which the application interacts.

A Case study - Leaking Auth Tokens - Facebook (2017)

The 2017 Facebook breach, stemming from vulnerabilities in the platform's "View As" feature, serves as a pivotal case study on the complexities and critical importance of authentication and authorization in web application security. This breach, disclosed by Facebook in September 2018, impacted approximately 50 million users, making it one of the most significant security incidents for the company at that time. The vulnerability allowed attackers to steal Facebook access tokens, which are the credentials that keep people logged in to Facebook, thereby bypassing authentication measures and gaining the ability to take over user accounts.

The "View As" feature was designed to allow users to see their own profile from the perspective of someone else, a tool intended to provide users with more control over their privacy settings. However, this feature inadvertently introduced a security flaw that exposed a user’s access token accounts they were friends with. Specifically, the breach was a result of three distinct bugs in Facebook's video uploading feature that interacted with the "View As" feature in a way that allowed attackers to obtain access tokens for other users. These tokens could then be used to access and potentially take over the accounts of those users.  This then allowed the attackers to target the accounts that were friends of the compromised users, and repeat the cycle.

Facebook's response to the breach included resetting the access tokens of the approximately 50 million accounts they believed were affected, as well as an additional 40 million accounts that had been subject to a "View As" lookup in the last year as a precautionary measure. This reset effectively logged out those users, requiring them to log back in—a step meant to secure their accounts. Furthermore, Facebook temporarily disabled the "View As" feature while they conducted a thorough security review.

Facebook’s public statement on this breach is available here: https://about.fb.com/news/2018/10/update-on-security-issue/

In Summary

Here are the core authentication and authorization things that I would want to make sure are correctly implemented before launching a new application:

• Any test code that might undermine the strength of the authentication has been removed. For example, hardcoded test credentials, or uppercasing/lowercasing passwords effectively making them case-insensitive.
• For tokens that use a signature for tamper-resistance (e.g. JWTs):
  • Only the signature algorithms you intend to use are allowed.  If your app uses RS256, any other value specified should cause the app to treat the token as invalid, and reject it.
  • The signature is actually being validated on every code-path where the token is used.  For example, the popular jsonwebtoken package for Node.js has two methods of getting the token’s claims, jwt.verify and jwt.decode.  The former checks that the token matches the signature, and the latter does not - something the documentation highlights.  While the specific method names might vary across packages, many of them have similar functionality.  It’s critical to ensure that the method with the signature validation is used on all authenticated routes.

• When using session cookies:
  
  • Use HTTPOnly when possible.
  • Use the Secure flag for environments that have TLS.
  • Explicitly set the SameSite attribute.  If your app works on an up-to-date version of Chrome without the SameSite attribute set, you can set SameSite=Lax (Chrome’s default behavior) and browsers with the weaker default (equivalent to SameSite=None) will benefit from the stronger Lax behavior.
  • Evaluate the domain attribute, determine if subdomains can be added to it. Doing so reduces the scope of that cookie, which lowers the attack surface it’s exposed to.
  • Evaluate the path attribute, determine if it makes sense to restrict the cookie to just a specific path, in the context of the domain your app is hosted on.
    
    
• Check for places your credentials, session, or bearer tokens are included in a URL, or in a response from your application.  While these interactions are sometimes necessary and actually commonplace in certain auth flows, it is preferable to avoid them when possible.  Leakage of these values to other users through the application is a significant flaw.
• Implement multi-factor authentication (MFA).  There was a time when this was less common, today it can usually be a launch day feature.

Related Materials

1. OWASP Cheatsheets on Authentication, Authorization, and Authorization Testing

1. Authentication (https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html): This relatively concise sheet is densely packed with useful information and technical details.  In addition to covering the basics fairly well, it  touches on other great topics such as Denial of Service attacks based on long passwords, and passwordless authentication.
2. Authorization (https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html):
   This sheet focuses more on different models that can be used to implement your own access control strategy from the ground up.  When possible, I lean toward leveraging existing frameworks, but that is not always a valid option.  It also lightly touches on the topic of creating Unit and Integration test cases for authorization logic.
3. Authorization Testing Automation (https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html):
   This sheet provides an approach and supporting example for defining an authorization matrix and performing automated tests against it.  The code examples are in Java, but the principles are not technology specific.

2. Auth0’s guide on selecting an OAuth 2.0 Flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use):
OAuth 2.0 flows are commonplace today, especially when using third-party identity providers such as Auth0, AWS Cognito, or even some self-hosted providers like KeyCloak.  This is a good starting point for understanding the different flows and security trade-offs between them.

Next: 3. Data Encryption and Protection

Mic Whitehorn is the Senior Security Consultant and Development Lead for Secure Ideas. Check out some of his latest insights on application security:

Read More:

• Many Hands Approach To AppSec
• What’s new in the OWASP Proactive Controls for 2024