M3: Insecure Authentication/Authorization (2024)

Weak authentication flows, missing session management, and broken access controls. Attackers bypass login, escalate privileges, or hijack sessions.

Risk Assessment

Am I Vulnerable?

• Insecure Direct Object Reference (IDOR): Noticing an IDOR vulnerability may suggest that the code isn't conducting a proper authorization check.
• Hidden Endpoints: Developers might neglect authorization checks on backend hidden functionality, assuming that the hidden functionality will only be accessed by a user with the appropriate role.
• User Role or Permission Transmissions: Should the mobile app transmit the user's roles or permissions to a backend system as part of a request, this could signal insecure authorization.
• Anonymous Backend API Execution: The ability of the app to execute a backend API service request without providing an access token may point to insecure authentication.
• Local Storage of Passwords or Shared Secrets: If the app stores any passwords or shared secrets locally on the device, this could be a sign of insecure authentication.
• Weak Password Policy: The use of a simplified password-entering process may imply insecure authentication.
• Usage of Features like FaceID and TouchID: Employing features like FaceID or TouchID could be indicative of insecure authentication if not properly implemented.

How Do I Prevent It?

• Match Web Authentication Standards: Authentication requirements for mobile versions should match web application standards.
• Server-Side Authentication: Perform authentication server-side whenever feasible.
• Encrypt Locally Stored Data: Encrypt locally stored data using keys derived from login credentials.
• No Local Password Storage: Never store passwords in "Remember Me" functionality.
• Revocable Device-Specific Tokens: Use revocable device-specific authentication tokens.
• Avoid Spoofable Values: Avoid spoofable authentication values like device identifiers or geolocation.
• Opt-In Persistent Authentication: Make persistent authentication opt-in, not default.
• No 4-Digit PINs: Don't permit 4-digit PINs for passwords.
• Server-Side Enforcement: Assume all client-side controls can be bypassed; enforce server-side reinforcement.
• Independent Role Verification: Backend systems should independently verify user roles and permissions. Never rely on role information sent from mobile devices.
• Biometric Protection: Use biometric features to protect authentication materials like session tokens, rather than as standalone authentication.
• Local Integrity Checks: Implement local integrity checks to detect unauthorized code changes.

Example Attack Scenarios

• Hidden Service Requests: Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.
• Interface Reliance: Developers assume that only authorized users will be able to see the existence of a particular function on their mobile app. Hence, they expect that only legitimately authorized users will be able to issue the request for the service from their mobile devices. The back-end code that processes the request does not bother to verify that the identity associated with the request is entitled to execute the service. Hence, adversaries are able to perform remote administrative functionality using fairly low-privilege user accounts.
• Usability Requirements: Due to usability requirements, mobile apps allow for passwords that are 4 digits long. The server code correctly stores a hashed version of the password. However, due to the severely short length of the password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables. If the password file (or data store) on the server is compromised, an adversary will be able to quickly deduce users' passwords.
• Insecure Direct Object Reference: A user makes an API endpoint request to a backend REST API that includes an actor ID and an OAuth bearer token. The user includes their actor ID as part of the incoming URL and includes the access token as a standard header in the request. The backend verifies the presence of the bearer token but fails to validate the actor ID associated with the bearer token. As a result, the user can tweak the actor ID and attain the account information of other users as part of the REST API request.
• Transmission of LDAP Roles: A user makes an API endpoint request to a backend REST API that includes a standard OAuth bearer token along with a header that includes a list of LDAP groups that the user belongs to. The backend request validates the bearer token and then inspects the incoming LDAP groups for the right group membership before continuing on to the sensitive functionality. However, the backend system does not perform an independent validation of LDAP group membership and instead relies upon the incoming LDAP information coming from the user. The user can tweak the incoming header and report to be a member of any LDAP group arbitrarily and perform administrative functionality.