Permission manipulation errors occur when an attacker is able to modify a value used in determining permissions within an application.

Example 1: The following code uses input from a file to determine the FileIOPermissions required in the application.

...
String permissionsXml = GetPermissionsFromXmlFile();
FileIOPermission perm = new FileIOPermission(PermissionState.None);
perm.FromXml(permissionsXml);
perm.Demand();
...

In this scenario, if the user is able to control the XML file used to retrieve the data, they control what permissions may be demanded by the system.

Permission manipulation logging errors occur when an attacker is able to modify a value used in determining permissions within an application that are used to determine what is logged. In Windows there are System Access Control Lists (SACLs) that are used to determine users and groups that should be audited to see if access is successful or fails against resources. If the Access Control Entries (ACEs) stored within these or access settings can be controlled by an attacker, the attacker has the potential to disable auditing of their account, thus making it harder to determine what an attacker may have done in a breach.

Example 1: The following code lets a user specify which operations to generate an audit log.

...
CrytoKeyAuditRule auditRule = new CryptoKeyAuditRule(IdRef, (CryptoKeyRights) input, AuditFlags.Success); 
...

In this scenario, if the user can control input then they can specify what type of operation can be logged. If the user can manipulate this to CryptoKeyRights.Delete, then they may be able to read the encryption key without it being logged, making you unaware that an attacker has stolen your encryption keys.

File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system properties to set the default permission mask. If attackers can alter the system properties, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

When declaring a custom permission, there are four options for specifying permission's protection level: normal, dangerous, signature, and signature or system. Normal permissions are granted to any application that requests them. Dangerous permissions are granted only after user confirmation. Signature permissions are granted only to applications signed by the same developer key as the package that defines the permission. Signature or system permissions are similar to signature permissions, but are also granted to packages in the Android system image.

Example 1: The following is an example of a custom permission declared with the normal protection level.

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

An application should only have the minimum permissions required for its proper execution. Extra permissions might deter users from installing the application. This permission might be unnecessary for this program.

Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

Permissions in the .NET Framework work by going up the stack tree (where the tree grows downward), to check if permissions are set sufficiently to access a resource. When a developer uses Assert() with a specific permission it is a way to say that the current controlflow has the specified permission. This in turn leads to the .NET framework stopping any further permission checks as long as it satisfies the needed permissions, meaning that code that calls the code making the call to Assert() may not have the required permission. The use of Assert() is helpful in some cases, but can lead to vulnerabilities when this allows a malicious user to get control of a resource that they would not have permission to otherwise.