Secure Applications with Authentication and Access Controls
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the importance of performing authentication and access control.
- Explain attack methods that leverage broken authentication.
- List attack methods that leverage broken access control.
Application Authentication and Access
Imagine the security at an airport. Before boarding, passengers must show proof of their identity to the ticket agent, who checks the ID against the passenger manifest and scans the ID against a database of bad actors. These physical authentication steps are much like the logical authentication steps users must complete before being able to access technological resources, including applications.
Application security engineers restrict data access to users who are identified, authenticated, and authorized. Authentication verifies someone’s identity by using credentials, usually username and password, to log into an application. This allows the application to grant users the necessary privileges, which restrict the user from accessing some things and allow them to access others. This concept of granting and restricting access to resources is called authorization. The entire process of identifying, authenticating, and authorizing users is known as access control.
Application security engineers have a key role to play in managing application authorization, log-in, and user permissions. Doing so protects against attackers compromising passwords, keys, or tokens. In doing so, application engineers control, manage, and audit access to applications, especially privileged (administrative) access.
Engineers run applications using the fewest privileges possible (a concept known as least privilege). They also test the application for vertical and horizontal access control issues. A horizontal issue occurs if one user can view/modify information of another user. A vertical issue occurs if the user can gain administrative access inappropriately.
For example, application security engineers protect against insecure direct object references, which allow attackers to bypass authorization and directly access resources in the system. This occurs when the application takes user-supplied input and uses it to retrieve an object (such as a database record or file) without performing sufficient authorization checks.
A token is usually used as follows: Instead of having to authenticate for each resource, the user authenticates that way once (within a session of limited duration), obtains a time-limited token from the server in return, and uses the identity data in that token for further authentication during the session.
Protect Against Broken Authentication
One risk that application security engineers protect against is called broken authentication. This occurs when an attacker gains unauthorized access to accounts and compromises a system. The impact of this risk can be severe, for example allowing an attacker to launder money, steal someone’s Social Security benefits, or even their identity. The risk of attackers exploiting broken authentication is high.
Attackers can easily access valid usernames and passwords by guessing the information through someone’s social media presence or using valid credentials available for sale on the dark web (a technique known as credential stuffing). Attackers test to see whether applications and associated software use default administrative accounts. If all else fails, the attacker uses a brute force attack to guess the user password or uses an automated program that systematically enters each word in a dictionary as a password (known as a dictionary attack) to gain illicit access.
Credential stuffing occurs when an attacker takes usernames and passwords from a major breach of another corporation and uses those credentials to log into other digital services. Because many people reuse usernames and passwords between sites, attackers can gain access to other accounts besides the ones that were originally compromised.
This all sounds pretty scary. How can application security engineers help? They have a key role to play in assessing an application to ensure it’s not vulnerable to broken authentication. In doing so, application security engineers check for the following weaknesses.
Default, Weak, or Well-Known Passwords
Engineers check to make sure that the application does not use default credentials (such as admin/admin for administrative accounts). They check the application for weak passwords, they require users to create passwords with a certain amount of characters, special characters, and they don’t allow common passwords. The National Institute of Standards and Technology (NIST) has guidelines for password length, complexity, and rotation.
Knowledge-Based Authentication (KBA)
Oftentimes, websites allow users to reset a password using KBA questions, such as the name of the street where they grew up or their dog’s name. The problem with this approach is that much of this personal information can be gleaned through a person’s social media presence or through information available on the dark web from previous breaches.
Application security engineers implement stronger account recovery mechanisms than KBA, such as requiring a code be sent to a registered email or phone number that the user has access to. They also limit and delay failed login attempts to prevent attackers from using brute force and dictionary attacks to guess passwords and ensure the application alerts administrators to failed login attempts.
Plain Text or Weakly Hashed Passwords
Storing and allowing users to enter passwords in plain text means that malicious actors can easily read them. Application security engineers ensure that all passwords for application resources are salted and hashed. This might sound like a cookbook recipe, but what it means is that extra data is added to the password, and it is scrambled in a way that cannot be reversed.
This way, even if someone steals the password, they cannot use it. Some of the computer algorithms (such as MD5) used to hash passwords are weak, because they can be quickly reverse engineered. Application security engineers avoid using these algorithms and implement strong hashing algorithms instead.
Single-Factor Authentication
Using only username and password (something the user knows) is called single-factor authentication (SFA). Because an attacker can guess or steal passwords, application security engineers implement multi-factor authentication (MFA) wherever possible to protect application authentication.
MFA uses both something the user knows (like a password) and something they have (like a phone) or something unique to them (like their face or fingerprint). For example, a user enters their username and password in an application. A separate authentication request is sent to their mobile phone which they must also approve. This extra layer of security makes it more difficult for attackers to compromise accounts.
Improper Session ID and Token Management
Improper session ID and token management can allow an attacker to hijack a session and impersonate a victim. In order to protect the session ID from being hijacked, engineers do a few things. They ensure the name of the ID is not descriptive so that attackers cannot gain information about the technologies and programming languages used by the application.
Just like passwords, session IDs should be long enough to prevent brute force attacks. And they should be unpredictable to prevent the attacker from guessing them. Application security engineers also store the meaning or business logic of session IDs on the server side (not the client side available to the user).
Finally, application security engineers implement built-in session management tools rather than build new ones from scratch and are aware of the vulnerabilities of the framework they choose to use. For more information on session management, see the associated OWASP Cheat Sheet.
A session is a series of requests and responses associated with a user sent to an application. Session IDs establish access rights to user interactions for the duration of the session.
Protect Against Broken Access Control
Whereas authentication logs a user into an account, access control enforces user permissions policies. When it is broken, attackers find ways to view or edit someone else’s accounts or act as administrators, using privileged functions to access, change, or delete records. This is a common security weakness and the impact can be severe depending on what type of data the attacker is able to access.
Application security engineers protect applications against this risk by using several strategies.
- Deny by default: If a request is not specifically allowed, it is denied. For example, if an administrator creates a new user account, the account should have minimal or no access by default until it is configured.
- Least privilege: All users are given as little access as possible.
- Enforce record ownership: Only certain users create, read, update, or delete any record.
- Log access control failures: Create a record and alert admins when an incorrect password is entered.
- Token management: Set expiration times for tokens and delete stored tokens upon log out. This prevents tokens from being used indefinitely and protects from an attacker tampering with tokens to elevate privileges.
- Test early and often: Finally, the application security engineer tests for these access control protections during the quality assurance process and throughout the SDLC.
Sum It Up
You’ve been introduced to strategies application security engineers use to protect the authentication and access control functions of an application to ensure only legitimate users are able to access their assigned resources and functionality. Now it’s time to dig into one last consideration around protecting applications: ensuring that sensitive data is not exposed.