Secure Coding Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Secure Coding Guidelines
Considerations for Flow Design
Secure Coding Cross Site Scripting
Secure Coding SQL Injection
Secure Coding Cross Site Request Forgery
Secure Coding Secure Communications
Storing Sensitive Data
Arbitrary Redirect
Authorization and Access Control
Lightning Security
Marketing Cloud Engagement API Integration Security
Secure Coding PostMessage
Secure Coding WebSockets
Platform Security FAQs
PDF

Authorization and Access Control

Authorization and Access Control - What is it?

Authorization and access control vulnerabilities can occur throughout a web application. These vulnerabilities occur whenever an attacker can access a resource that is restricted to only authenticated users. Some common ones are:
  • Directory traversal
  • Insecure Direct Object Reference
  • Bypassing authorization mechanisms
  • Privilege escalation

The way these vulnerabilities appear in a web application can be application specific, but common authorization vulnerabilities do exist and can be tested for. Authorization/access control, and directory traversal were both cited in the 2019 CWE/SANS Top 25 Most Dangerous Programming Errors report.

Web servers confine users browsing a site to the web document root directory, the location of which is dependent upon the web server‘s operating system and the server’s configuration. Access to the filesystem is additionally restricted by the operating system’s Access Control Lists (ACLs), which define read, write, and execute permissions for files. These protections are in place to restrict the user browsing the site from accessing sensitive information on the server. However, a web application that uses server-side scripts could allow an attacker to read, write, and execute files on the system by subverting the executing script. This is typically possible because input parameters to the script are not validated. Subverting a script in order to traverse the directories of a server and read sensitive files such as /etc/passwd are commonly referred to as directory traversal attacks.

Many web applications use roles, which permit selective access to certain resources based on the type of user. A common set of roles would be an unauthenticated user, a user, and an administrator account. An unauthenticated user might only be allowed to access a login page. The user may be able to access all of a web application except for maintenance and configuration of the web application, which is restricted to the administrator role. Any time that an attacker can gain access to a resource that is denied to their role, they have performed an authorization mechanism bypass.

A specific authorization bypass is privilege escalation, which occurs whenever an attacker who is operating as one role succeeds in changing themselves to another role, generally one with more privileges or specific restricted privileges.

Sample Vulnerability

Directory Traversal:

Consider the following URL:
https://www.example.com/index.php?page=login
A directory traversal attack to display the /etc/passwd file can be executed by changing the URL to: 
https://www.example.com/index.php?page=../../../../../../../etc/passwd
Example response: 
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin

In this sample the attacker gained read access to the /etc/passwd file.

Authorization:

Consider a HTTP request for an administrator to reset the password of a user:
POST /admin/resetPassword.jsp HTTP/1.1
Host: www.example.com
[HTTP Headers]
user=admin&newpassword=password

If an attacker could perform an identical request and the web application resets the admin account's password, this is an example of bypassing an authorization mechanism because this capability was only intended for administrators of www.example.com. In a sense, this is also a privilege escalation issue since a non-administrator can perform administrative password reset functionality and obtain access to the administrator account with the new password.

Is My Application Vulnerable?

It is not unusual for a web application to read, write, and execute files via scripts as part of the functionality they provide. As with other input validation vulnerabilities, protecting against directory traversal requires that developers take proactive steps to validate user input before it is executed. If this has not been done, your application may be vulnerable.

All web applications provide access to resources by definition. If your web application includes a login page, has a logical division between roles/groups, and has functionality restricted to only certain types of users such as administrators, your web application may be vulnerable unless carefully engineered.

How Can I Test My Application?

When considering a web application for directory traversal, stay alert for the following:

  • Any dynamic web page generation using scripts with variables that accept filenames
  • Any behavior by the web application that performs I/O on the server such as reading, writing, and executing files
  • Any cookies that appear to be part of dynamic web page generation
  • Any vector which uses what appears to be filenames

Burp Suite Professional has the capability to test for directory traversal. Information on using the Burp Scanner feature of the suite to test for directory traversal is available in the help file at https://portswigger.net/burp/help/scanner. Like Burp Suite, many testing tools also have very efficient spiders that can locate hidden content and pages intended to only be used by authorized users. Never assume an attacker does not know the entire layout of your web application.

Testing for authorization and access control vulnerabilities varies greatly from application to application. In general, using a proxy and staying alert for information being passed about the logical roles, accounts, and groups in a web application can identify how authorization and access control is enforced in a web application. Conduct an investigation of the web application driven by questions like:

  • What pages are used for authenticating a user?
  • What roles/groups exist for the web application?
  • What are the capabilities/resources of each role/group?
  • What mechanisms are used to grant access to the role/group, and does it actively check that a request is from an authenticated role/group member?
  • What happens when incorrect role/group data is supplied to the mechanisms?
  • What happens when the information of other role/group data is supplied to these mechanisms?
  • What happens when a user of the site modifies their own role/group data with a proxy before submission to a mechanism?
  • What assumptions are being made and what does a member of the product security team think about these assumptions?

Some commercial tools, such as IBM Rational AppScan, have the capability to differentiate between pages that only certain roles can reach, though tools such as these are expensive. When configured with an understanding of the divisions of your site, it can attempt to detect authorization vulnerabilities by recognizing when a role can access a page that should have been restricted to another role.

How Do I Protect My Application?

Apex and Visualforce Applications

Keep in mind that you must respect the organization's security policy on both standard and custom objects, and to gracefully degrade if a user's access has been restricted. Some use cases where it might be acceptable to bypass CRUD/FLS are:

  • For creating roll up summaries or aggregates that don’t directly expose the data
  • Modifying custom objects or fields like logs or system metadata that shouldn’t be directly accessible to the user via CRUD/FLS
  • Cases where granting direct access to the custom object creates a less secure security model.

Make sure to document these use cases as a part of your submission.

General Guidance

The simplest methods of protecting against directory traversal and other authorization and access control vulnerabilities are to validate user input and follow secure design principles. t is important to correctly identify the attack surface of your web application, which includes not only the intended user input, but also any values the user can modify and submit with a proxy, such as data in cookies, request information, request headers, forms, hidden fields, etc. All of this data should be properly validated before proceeding with any routines.

Secure design principles such as the principle of least privilege should also be strictly adhered to. Identify all capabilities the web application permits and divide these logically among separate roles and groups in accordance with the principle of least privilege.

Consider the OWASP Guide to Authorization:

  • Capabilities divided among roles/groups along principle of least privilege.
  • Centralize authorization code
  • Create an authorization matrix
  • Check authorization not just to capabilities but the resources those capabilities act on
  • Be wary of static resources and the possibility of forced browsing to those resources
  • Custom authorization mechanisms invite more vulnerabilities if not properly designed, implemented, and reviewed
  • Avoid client-side authorization mechanisms

Additionally, be cognizant of the influence of time on authorization. If a user is authenticated and allowed access to some resource, what happens a minute after login when the user has their role demoted such that they cannot access the resource? Do race conditions exist in the authorization mechanism?

For more information on this class of attacks, see the following articles:

ASP.NET

ASP.NET has a framework to perform authentication and authorization. Authentication can be configured using Active Directory, SQL Server, and Windows Authentication. Authorization can be controlled with the Authorization Manager (AzMan), the authorization management APIs, and various authorization modules such as UrlAuthorizationModule. UrlAuthorizationModule is used to determine if the current user is permitted access to the requested URL based on either the username or role membership.

For more information, review the following articles:

Java

Java EE 5 and later provides a framework to perform authentication and authorization. A web application can have defined realms, users, groups, and roles for a Java application in this framework. Roles can be defined by annotations or by deployment descriptor elements. Security constraints are defined in the deployment descriptor for a page.

For more information, review the following articles:

PHP

PHP does not provide a secure framework for doing authorization and access control like ASP.NET and Java. Be wary of 'secure' PHP scripts advertised on the Internet, many are rife with SQL injection and unsafe storage of the user's password.

PHP does have a session framework that can be used for authentication, and relied on to do subsequent authorization checks, for example: defining users and roles in a database schema, then storing authenticated session information for each user so that cross checks may be performed to determine whether that user should be allowed access to a given resource. The caveat is that care must be taken when configuring sessions since the defaults are insecure. The default settings of how PHP handles sessions must be changed in php.ini. Change the following settings to the values below:
session.hash_function = 1
session.entropy_file = /dev/urandom
session.entropy_length = 64
PHP has a special setting in php.ini called open_basedir. This setting can be used to restrict PHP file opening, writing, and deletion to a specified directory tree. By default this setting is turned off, and the necessity to use it depends on your server configuration. For example, PHP running as an Apache module on a secured configuration of Apache will inherit Apache's limited directory permissions, so it might not be necessary to use it in that case. It can be used in the following manner:
open_basedir = '/home/www/public_html'
During code review consider the usual PHP suspects: 
include(), include_once(), require(), require_once(), fopen(), readfile()

These functions take filenames as parameters, and should be traced back to verify if the parameters were properly validated.

If these functions are not required by your web application, it is possible to disable them in php.ini using the disable_functions setting. This is a common technique to prevent command injection by blocking a list of commands that might execute user data as instructions for a shell. It can be used in the following manner:
disable_functions = fopen, readfile, system, exec, passthru, shell_exec, proc_open

Another setting in php.ini that can be used is allow_url_include. This setting controls if files on remote URLs can be included via include() and require(). If this is not necessary, it should be set to off.