M6: Insecure Authorization

Overview

This article discusses the concept of insecure authorization and its impact on application security. It explains the threat agents, attack vectors, security weakness, technical and business impacts of insecure authorization. It also provides guidelines for preventing insecure authorization and presents two example attack scenarios. This information is part of the OWASP Top 10 Mobile Risks 2016.

Description

Insecure authorization refers to vulnerabilities in an application's authorization scheme that allow unauthorized users to gain access to privileged functionality. This can occur when the application fails to properly authenticate and verify the permissions of users. Adversaries can exploit these vulnerabilities through automated attacks using available or custom-built tools. Once authenticated, they can forcefully browse to a vulnerable endpoint and execute administrative functionality. Poor or missing authorization schemes can lead to severe technical and business impacts, such as system destruction or information theft.

How to Prevent ?

To prevent insecure authorization, organizations should verify the roles and permissions of authenticated users using information contained only in backend systems. Relying on roles or permissions information from the mobile device itself should be avoided. Backend code should independently verify incoming identifiers associated with a request to ensure they match up and belong to the incoming identity. In addition, developers should look out for insecure direct object reference vulnerabilities, hidden endpoints, and the transmission of LDAP roles as indicators of insecure authorization vulnerabilities.

Example Attack Scenarios:

• Scenario #1: Insecure Direct Object Reference:  In this scenario, a user makes an API endpoint request to a backend REST API that includes an actor ID and an oAuth bearer token. The backend validates the presence of the bearer token but fails to validate the actor ID associated with it. The user can manipulate the actor ID in the request and gain access to other users' account information.

• Scenario #2: Transmission of LDAP Roles:  In this scenario, a user makes an API endpoint request to a backend REST API that includes a standard oAuth bearer token and a header with a list of LDAP groups they belong to. The backend checks the bearer token and the user's LDAP group membership before proceeding with sensitive functionality. However, it relies solely on the incoming LDAP information without independent validation. The user can modify the header and claim membership in any LDAP group, thereby gaining administrative privileges.