Skip to main content

Insecure Access Control

Fixing Insecure Access Control​

About Insecure Access Control

What is improper access control?​

Improper access control is a vulnerability that occurs when a system does not properly restrict or enforce access to resources, such as files, directories, network resources, or application functions.

Examples of improper access control vulnerabilities include:

  • Weak access controls: When access controls are weak or easily bypassed, attackers can gain access to sensitive resources or data by exploiting security weaknesses.
  • Insufficient authorization checks: When authorization checks are insufficient, it can allow unauthorized users to access sensitive data or resources, or to perform actions that they are not authorized to do.
  • Overly permissive access: When access controls are overly permissive, they can allow users to access resources or data that they do not need, increasing the risk of data breaches or other security incidents.

Check out these videos for a high-level explanation:

  • Missing function level access control

  • Missing object level access control

What is the impact of improper access control?​

Improper access control can lead to various security threats, such as:

  • Data breaches: Improper access control can allow attackers to access sensitive data, leading to data breaches, data loss, or unauthorized access to confidential information.
  • Unauthorized access to resources: Attackers can exploit improper access control to gain unauthorized access to resources, such as servers, databases, and applications.
  • Account takeover: Attackers can use improper access control to take over user accounts and gain access to sensitive data or resources.

How to prevent improper access control?​

Here are some measures that can help ensure proper access control:

  • Strong access controls: Implement strong access controls that restrict access to sensitive resources or data based on user roles and permissions.
  • Proper user authentication and authorization: Implement proper user authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
  • Input validation and sanitization: Validate and sanitize user input before using it to access internal objects or data. Use regular expressions or input filters to remove or encode any special characters that could be used to access sensitive data or resources.
  • Least privilege: Use the principle of least privilege to restrict access to resources to only what is necessary for each user role. This can help prevent attackers from gaining access to resources that they do not need to access.
  • Regular security audits: Regularly audit your system for security vulnerabilities, including improper access control vulnerabilities. Use automated tools and manual testing to identify potential issues and fix them before they can be exploited.

References​

Taxonomies​

Explanation & Prevention​

Training​

Missing User Instruction​

The USER instruction in a Dockerfile specifies the user that should be used when running the container. If a Dockerfile doesn't contain a USER instruction, the container will be run as the root user by default, which can pose some potential security risks.

Here are the problems of not having a USER instruction in a Dockerfile:

  1. Security Risks: Containers run as root have the potential to gain escalated permissions on the host system, which can lead to security vulnerabilities. If a process needs to run as root inside the container, and the container is compromised, the attacker could potentially gain root access to the host system. It's best practice to run processes as non-root whenever possible to mitigate these risks.

  2. Principle of Least Privilege: Following the principle of least privilege, processes should only have the minimum permissions necessary to perform their function. When processes are run as root, they have more access than they likely need, which again, can lead to security issues.

#. Regulatory and Compliance Requirements: Depending on the environment and application, there may be compliance requirements that dictate that applications must not run with root level permissions.

It's recommended to use the USER instruction in a Dockerfile to ensure your containers are running as a non-root user, enhancing the security of your application and following best practices. If a process needs specific permissions, consider using Linux capabilities to grant those permissions rather than running the process as root.

Rule-specific references:

Option A: Create and Use Non-root Users​

To specify a user other than root in a Dockerfile, you can use the USER instruction. You should also create a non-root user and group in your Dockerfile if they do not exist already.

Here's a basic example for Ubuntu:

FROM ubuntu:latest

# Create a new group
RUN groupadd -r mygroup && useradd -r -g mygroup myuser

# Install necessary packages, etc.
# RUN apt-get update ...

# Use the USER instruction to switch to the new user
USER myuser

# Continue with your Dockerfile...
# CMD ["your", "command", "here"]

In this example, groupadd creates a new group, myuser, and useradd creates a new user and adds it to the group. The -r option creates a system user/group, and -g specifies the group for the user.

The USER instruction changes the user for all following instructions in the Dockerfile, and also for the container when it's run. In this case, it switches to the myuser user that we created.

It's important to note that the USER instruction does not have any effect on the RUN, CMD, and ENTRYPOINT instructions that have been run before it in the Dockerfile.

If your application needs to write to a specific directory, you should also ensure that this directory is owned by the user you switch to, or that this user has write permissions for this directory. Otherwise, your application might crash because it's not allowed to write where it needs to. You can change the ownership using the chown command in your Dockerfile.

Be careful while performing operations like installing packages, starting services, and writing to privileged directories, because non-root users may not have the necessary permissions. In those cases, you will have to switch back and forth between root and the non-root user as needed.

Run Using Sudo​

Using sudo in a Dockerfile can create several potential issues:

  1. Security Risks: If you include sudo in your Docker image, it could be exploited to escalate privileges within a running container. Even though containers are isolated from the host by default, this can still present a security risk.

  2. Unnecessary Overhead: Docker builds and runs containers as the root user by default, so there's typically no need to use sudo for operations in your Dockerfile. This is different from a typical Ubuntu or other Linux system where you often need sudo to perform administrative tasks.

  3. Inconsistent Behavior: If you build your Dockerfile as a non-root user using the USER directive, the sudo command may not work as expected. The sudo command is intended to elevate privileges, but Docker doesn't always handle this correctly, which can lead to inconsistencies and bugs.

To fix these issues, it's best to avoid using sudo in your Dockerfiles. If you need to perform operations as a non-root user, use the USER directive. If you need to switch back to the root user for certain operations, you can do so using USER root, then switch back to the non-root user with USER youruser. Remember, the principle of least privilege is crucial in maintaining secure systems, so always use the least privileged user that's able to perform the necessary tasks.

Rule-specific references:

Option A: Avoid the Use of 'sudo'​

Avoid using sudo in a Dockerfile. If you need to perform operations as a non-root user, you can use the USER directive. You can switch back and forth between the root user and the non-root user as needed. Here's an example:

FROM ubuntu:latest

# Create a new group and user
RUN groupadd -r mygroup && useradd -r -g mygroup myuser

# Do necessary operations as root
# e.g., Install necessary packages, etc.
# RUN apt-get update ...

# Switch to non-root user
USER myuser

# Do necessary operations as myuser
# e.g., COPY a file owned by myuser
# COPY --chown=myuser:mygroup myFile /my/directory/

# If necessary, switch back to root for other operations
# USER root

# Finally switch back to non-root user before ending Dockerfile
# USER myuser

# Set the default command for the container
# CMD ["your", "command", "here"]

In this example, groupadd creates a new group, myuser, and useradd creates a new user and adds it to the group. The -r option creates a system user/group, and -g specifies the group for the user.

The USER instruction changes the user for all following instructions in the Dockerfile, and also for the container when it's run. We switch to the myuser user for the operations that don't require root privileges.

If you need to go back to the root user to perform some operations, you can use USER root. But make sure you switch back to a non-root user before ending the Dockerfile. This way, when the container is run, it will run as a non-root user, following the principle of least privilege and enhancing the security of your container.

Last updated on by Stefan Streichsbier