Laravel

Table of contents

1. XSS
2. SQL injection
3. Broken Access Control
4. Cryptographic Failures
5. Insecure Design
6. Security Misconfiguration
7. Vulnerable and Outdated Components
8. Identification and Authentication Failures
9. Software and Data Integrity Failures
10. Security Logging and Monitoring Failures
11. Server-Side Request Forgery

XSS

Noncompliant code:

// Noncompliant code
public function store(Request $request)
{
    $name = $request->input('name');
    $message = $request->input('message');
    
    DB::table('comments')->insert([
        'name' => $name,
        'message' => $message,
    ]);
    
    return redirect()->back();
}

In this noncompliant code, the store method receives user input through the $request object and directly inserts it into the database without any validation or sanitization. This makes the application vulnerable to Cross-Site Scripting (XSS) attacks, as an attacker can submit malicious JavaScript code as the message input, which will be rendered as-is when displayed back to users.

Compliant code:

// Compliant code
public function store(Request $request)
{
    $name = $request->input('name');
    $message = $request->input('message');
    
    $sanitizedMessage = htmlspecialchars($message, ENT_QUOTES, 'UTF-8');
    
    DB::table('comments')->insert([
        'name' => $name,
        'message' => $sanitizedMessage,
    ]);
    
    return redirect()->back();
}

In the compliant code, the htmlspecialchars function is used to sanitize the user input before inserting it into the database. This function escapes special characters that have special meaning in HTML, preventing them from being interpreted as HTML tags or entities when displayed in the browser. This sanitization process helps mitigate XSS vulnerabilities by ensuring that user-supplied input is treated as plain text rather than executable code.

It’s important to note that while the htmlspecialchars function provides basic protection against XSS attacks, it is context-specific. Depending on the specific output context (e.g., HTML attributes, JavaScript, CSS), additional sanitization or encoding may be required. Consider using specialized libraries or functions that are tailored to the specific output context to provide more comprehensive protection against XSS vulnerabilities.

In addition to input sanitization, other security measures you can implement in Laravel to mitigate XSS vulnerabilities include:

• Utilizing Laravel’s built-in CSRF protection to prevent cross-site request forgery attacks.
• Applying output encoding using Laravel’s Blade templating engine or helper functions like to automatically escape variables.
• Implementing content security policies (CSP) to control the types of content allowed to be loaded and executed on your web pages.

By properly sanitizing user input and implementing security measures throughout your Laravel application, you can effectively mitigate XSS vulnerabilities and enhance the overall security of your web application.

SQL injection

Noncompliant code:

$userInput = $_GET['username'];
$query = "SELECT * FROM users WHERE username = '".$userInput."'";
$results = DB::select($query);

In this noncompliant code, the user input is directly concatenated into the SQL query string, creating a vulnerability known as SQL injection. An attacker can manipulate the input to inject malicious SQL statements, potentially gaining unauthorized access to the database or manipulating its contents.

Compliant code:

$userInput = $_GET['username'];
$results = DB::select("SELECT * FROM users WHERE username = ?", [$userInput]);

In the compliant code, Laravel’s query builder is used with prepared statements to mitigate SQL injection. The user input is bound to a placeholder (?) in the query, and Laravel handles the proper escaping and sanitization of the input.

By using prepared statements, the compliant code ensures that user input is treated as data rather than executable SQL code, thereby preventing SQL injection attacks.

Broken Access Control

Noncompliant code:

public function deletePost(Request $request, $postId)
{
    $post = Post::find($postId);
    
    // Check if the currently authenticated user is the owner of the post
    if ($post->user_id == Auth::user()->id) {
        $post->delete();
        return redirect('/dashboard')->with('success', 'Post deleted successfully.');
    } else {
        return redirect('/dashboard')->with('error', 'You do not have permission to delete this post.');
    }
}

In this noncompliant code, the deletePost method assumes that the currently authenticated user is authorized to delete any post based solely on their user ID. However, it fails to perform proper access control checks to ensure that the user is the actual owner of the post. This can lead to broken access control, allowing unauthorized users to delete posts.

Compliant code:

public function deletePost(Request $request, $postId)
{
    $post = Post::find($postId);
    
    // Check if the currently authenticated user is the owner of the post
    if ($post->user_id == Auth::user()->id) {
        $post->delete();
        return redirect('/dashboard')->with('success', 'Post deleted successfully.');
    } else {
        abort(403, 'Unauthorized');
    }
}

In the compliant code, the deletePost method performs the same check to verify if the authenticated user is the owner of the post. However, instead of redirecting with an error message, it throws a 403 Forbidden exception using the abort function if the user is not authorized. This ensures that unauthorized users cannot determine the existence of a post they don’t have access to.

Cryptographic Failures

Noncompliant code:

public function encryptData($data, $key)
{
    return encrypt($data, $key);
}

public function decryptData($encryptedData, $key)
{
    return decrypt($encryptedData, $key);
}

In this noncompliant code, the encryptData and decryptData functions use the default Laravel encryption functions encrypt and decrypt to perform cryptographic operations. However, this code does not consider important aspects of cryptographic security, such as key management, algorithm selection, and secure handling of sensitive data. This can lead to cryptographic failures and vulnerabilities in the application.

Compliant code:

use Illuminate\Support\Facades\Crypt;

public function encryptData($data, $key)
{
    return Crypt::encryptString($data);
}

public function decryptData($encryptedData, $key)
{
    try {
        return Crypt::decryptString($encryptedData);
    } catch (DecryptException $e) {
        // Handle decryption error
    }
}

In the compliant code, we use Laravel’s Crypt facade to perform the encryption and decryption operations. The encryptString and decryptString methods provided by the Crypt facade offer a more secure approach for cryptographic operations. Additionally, error handling is implemented using a try-catch block to properly handle decryption errors, such as when an incorrect key is provided.

Insecure Design

Noncompliant code:

public function getUserProfile($userId)
{
    $user = User::find($userId);

    if ($user) {
        return [
            'id' => $user->id,
            'name' => $user->name,
            'email' => $user->email,
            'role' => $user->role,
        ];
    }

    return null;
}

In this noncompliant code, the getUserProfile function retrieves a user’s profile information based on the provided $userId. However, it lacks proper access control and authorization checks. Any user can potentially access the profile information of any other user, bypassing the necessary security measures.

Compliant code:

public function getUserProfile($userId, $requestingUserId)
{
    $requestingUser = User::find($requestingUserId);

    if ($requestingUser && $requestingUser->isAdmin()) {
        $user = User::find($userId);

        if ($user) {
            return [
                'id' => $user->id,
                'name' => $user->name,
                'email' => $user->email,
                'role' => $user->role,
            ];
        }
    }

    return null;
}

In the compliant code, we have introduced an additional parameter $requestingUserId to identify the user making the request. We first check if the requesting user exists and if they have the necessary privileges, such as being an administrator, to access the profile information. Only if these conditions are met, the profile information is returned. Otherwise, null is returned, indicating the lack of authorization.

Security Misconfiguration

Noncompliant code:

// config/database.php

return [
    'default' => 'mysql',
    'connections' => [
        'mysql' => [
            'driver' => 'mysql',
            'host' => '127.0.0.1',
            'port' => '3306',
            'database' => 'mydatabase',
            'username' => 'root',
            'password' => '',
            'unix_socket' => '',
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => false,
            'engine' => null,
        ],
    ],
];

In this noncompliant code, the database configuration file config/database.php contains sensitive information, such as the database credentials. The password field is empty, which means the application is using a default or weak password, making it vulnerable to unauthorized access. Additionally, the strict mode is disabled, which can lead to insecure SQL queries.

Compliant code:

// config/database.php

return [
    'default' => env('DB_CONNECTION', 'mysql'),
    'connections' => [
        'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'mydatabase'),
            'username' => env('DB_USERNAME', 'root'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            'collation' => 'utf8mb4_unicode_ci',
            'prefix' => '',
            'strict' => true,
            'engine' => null,
        ],
    ],
];

In the compliant code, sensitive information such as the database credentials are not hard-coded directly in the configuration file. Instead, environment variables are used to retrieve the values. This allows for better security by keeping the sensitive information separate from the codebase and configurable based on the deployment environment.

By using environment variables, you can easily manage different configurations for development, testing, and production environments without exposing sensitive information in the codebase or version control system.

Vulnerable and Outdated Components

Noncompliant code:

composer require laravel/framework:5.7.0

In this noncompliant code, the Laravel framework version 5.7.0 is explicitly specified. This can lead to using a vulnerable and outdated version of the framework, as newer versions may contain security patches and bug fixes.

Compliant code:

composer require laravel/framework:^8.0

In the compliant code, the Laravel framework version is specified using a version constraint ^8.0. This allows Composer, the PHP dependency manager, to install the latest compatible version of the Laravel framework within the major version 8.x. This ensures that you receive the latest security updates and improvements.

Identification and Authentication Failures

Noncompliant code:

public function login(Request $request)
{
    $credentials = $request->only('email', 'password');
    
    if (Auth::attempt($credentials)) {
        // User authenticated successfully
        return redirect()->intended('/dashboard');
    } else {
        // Authentication failed
        return redirect()->back()->withErrors(['Invalid credentials']);
    }
}

In this noncompliant code, the authentication process solely relies on the Auth::attempt() method, which attempts to authenticate the user based on the provided email and password. However, this code does not handle certain authentication failures appropriately, such as account lockouts or brute-force protection.

Compliant code:

public function login(Request $request)
{
    $credentials = $request->only('email', 'password');
    
    if (Auth::attempt($credentials)) {
        // User authenticated successfully
        return redirect()->intended('/dashboard');
    } else {
        // Authentication failed
        if (Auth::exists(['email' => $request->input('email')])) {
            // Invalid password provided
            return redirect()->back()->withErrors(['Invalid password']);
        } else {
            // Invalid email provided
            return redirect()->back()->withErrors(['Invalid email']);
        }
    }
}

In the compliant code, we have enhanced the authentication process by considering different types of authentication failures. If the provided email exists in the system database but the password is incorrect, we show an appropriate error message indicating an invalid password. If the provided email does not exist, we show an error message indicating an invalid email.

Software and Data Integrity Failures

Noncompliant code:

public function updateProfile(Request $request)
{
    $user = Auth::user();

    $user->name = $request->input('name');
    $user->email = $request->input('email');
    $user->save();

    return redirect('/profile');
}

In this noncompliant code, the user’s profile information is updated directly based on the user input received from the request. While this code successfully updates the user’s name and email, it lacks proper validation and sanitization of the input, which can lead to software and data integrity failures.

Compliant code:

public function updateProfile(Request $request)
{
    $user = Auth::user();

    $validatedData = $request->validate([
        'name' => 'required|string|max:255',
        'email' => 'required|email|unique:users,email,' . $user->id,
    ]);

    $user->name = $validatedData['name'];
    $user->email = $validatedData['email'];
    $user->save();

    return redirect('/profile');
}

In the compliant code, we have added validation rules to ensure the integrity of the software and data. The validate() method is used to validate the input fields against specific rules. In this example, the name field is required and should be a string with a maximum length of 255 characters. The email field is also required and must be a valid email format. Additionally, the email field is validated for uniqueness, ensuring that no other user in the database has the same email.

Security Logging and Monitoring Failures

Noncompliant code:

public function deleteUser(Request $request)
{
    $userId = $request->input('user_id');

    $user = User::find($userId);

    if ($user) {
        $user->delete();
    }

    return redirect('/users');
}

In this noncompliant code, when a user is deleted, there is no logging or monitoring mechanism in place to track this activity. The code simply deletes the user if found and redirects back to the list of users. Without proper logging and monitoring, it becomes challenging to identify and investigate any unauthorized or suspicious user deletions.

Compliant code:

public function deleteUser(Request $request)
{
    $userId = $request->input('user_id');

    $user = User::find($userId);

    if ($user) {
        $user->delete();

        // Log the user deletion activity
        Log::info('User deleted', ['user_id' => $userId]);
    }

    return redirect('/users');
}

In the compliant code, we have added a logging mechanism to track the user deletion activity. After successfully deleting the user, we use Laravel’s Log facade to record an information-level log entry. The log message includes relevant details such as the user ID that was deleted. By incorporating logging into the code, we can keep a record of important security-related events and establish an audit trail for future analysis and monitoring.

Server-Side Request Forgery

Noncompliant code:

public function fetchExternalData(Request $request)
{
    $url = $request->input('url');

    $data = file_get_contents($url);

    return response()->json(['data' => $data]);
}

In this noncompliant code, the fetchExternalData method takes a URL input from the user and directly uses the file_get_contents function to fetch data from that URL. This can lead to a Server-Side Request Forgery vulnerability, where an attacker can provide a malicious URL that causes the application to perform unintended actions or access internal resources.

Compliant code:

public function fetchExternalData(Request $request)
{
    $url = $request->input('url');

    // Validate and sanitize the URL to prevent SSRF
    $validatedUrl = filter_var($url, FILTER_VALIDATE_URL);
    
    if (!$validatedUrl) {
        return response()->json(['error' => 'Invalid URL'], 400);
    }

    // Restrict allowed domains if necessary
    $allowedDomains = ['example.com', 'trusteddomain.com'];
    $parsedUrl = parse_url($validatedUrl);
    
    if (!in_array($parsedUrl['host'], $allowedDomains)) {
        return response()->json(['error' => 'Access to the specified domain is not allowed'], 403);
    }

    // Fetch the data
    $data = file_get_contents($validatedUrl);

    return response()->json(['data' => $data]);
}

In the compliant code, several measures are taken to mitigate the Server-Side Request Forgery vulnerability:

1. URL Validation and Sanitization: The URL input is validated and sanitized using the filter_var function with the FILTER_VALIDATE_URL filter. This ensures that the URL provided by the user is a valid URL.

2. Restrict Allowed Domains: If necessary, a whitelist of trusted domains can be maintained. The parsed URL’s host is checked against this list to ensure that only trusted domains are accessed. This helps prevent access to potentially malicious or internal resources.

3. Proper Error Handling: In case of an invalid URL or unauthorized domain, appropriate error responses are returned. This ensures that potential SSRF attempts are properly handled and communicated to the user or client.