Improper Authorization

The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.


Description

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

When access control checks are not applied consistently - or not at all - users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.

Background

An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

This function runs an arbitrary SQL query on a given database, returning the result of the query.

function runEmployeeQuery($dbName, $name){
  mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
  //Use a prepared statement to avoid CWE-89
  $preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
  $preparedStatement->execute(array(':name' => $name));
  return $preparedStatement->fetchAll();
}
/.../

$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.

Example Two

The following program could be part of a bulletin board system that allows users to send private messages to each other. This program intends to authenticate the user before deciding whether a private message should be displayed. Assume that LookupMessageObject() ensures that the $id argument is numeric, constructs a filename based on that id, and reads the message details from that file. Also assume that the program stores all private messages for all users in the same directory.

sub DisplayPrivateMessage {
  my($id) = @_;
  my $Message = LookupMessageObject($id);
  print "From: " . encodeHTML($Message->{from}) . "<br>\n";
  print "Subject: " . encodeHTML($Message->{subject}) . "\n";
  print "<hr>\n";
  print "Body: " . encodeHTML($Message->{body}) . "\n";
}

my $q = new CGI;
# For purposes of this example, assume that CWE-309 and


# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
  ExitError("invalid username or password");
}

my $id = $q->param('id');
DisplayPrivateMessage($id);

While the program properly exits if authentication fails, it does not ensure that the message is addressed to the user. As a result, an authenticated attacker could provide any arbitrary identifier and read private messages that were intended for other users.

One way to avoid this problem would be to ensure that the "to" field in the message object matches the username of the authenticated user.

See Also

OWASP Top Ten 2017 Category A5 - Broken Access Control

Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2017.

Authorize Actors

Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have th...

SFP Secondary Cluster: Insecure Resource Access

This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Access cluster (SFP35).

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.

Weaknesses Introduced During Design

This view (slice) lists weaknesses that can be introduced during design.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.