Skip to main content

Insecure functionality - Masking

Need​

Implementation of data masking techniques

Context​

  • Usage of PHP 7.0 for server-side scripting and web development
  • Usage of Request for making HTTP requests
  • Usage of the User dependency for managing user-related functionality

Description​

Non compliant code​

public function store(Request $request)
{
    $user = new User;

    $user->name = $request->name;
    $user->email = $request->email;
    $user->password = $request->password;

    $user->save();

    return response()->json(['user' => $user], 200);
}

In the above PHP code, the store method is used to store the user's data in the database. This method is part of a Laravel controller that handles user requests and responses.

The vulnerability lies in the fact that the user's password is directly taken from the request and stored in the database. The password is not being masked or hashed in any way. This means that if a malicious actor were to gain access to your database, they would be able to see the users' passwords in plain text. This is a serious security risk as it could lead to unauthorized access to user accounts.

Additionally, the password is returned in the response after the user is saved. This is another security risk as the password can be intercepted during transmission. This could happen if the connection is not secure (i.e., not using HTTPS) or if a Man-in-the-Middle (MitM) attack is performed.

In summary, the code is vulnerable because it does not mask or hash the user's password before storing it in the database and it includes the password in the response.

Steps​

  • Firstly, never store passwords in plain text. Always hash the passwords before storing them in the database.
  • Secondly, when returning the user data in the response, make sure to exclude sensitive information like passwords, even if they are hashed.
  • Thirdly, consider using HTTPS for all communications to ensure that data in transit is encrypted and cannot be intercepted.
  • Lastly, consider using a data masking technique to hide sensitive data in the request or response. This can be done by replacing actual data with fictitious but realistic data.

Compliant code​

public function store(Request $request)
{
    $user = new User;

    $user->name = $request->name;
    $user->email = $request->email;
    $user->password = Hash::make($request->password);

    $user->save();

    $user = $user->makeHidden('password');

    return response()->json(['user' => $user], 200);
}

The updated code now includes a few changes to address the vulnerability:

  1. Password Hashing: The password from the request is now being hashed before it is stored in the database. This is done using Laravel's built-in Hash facade and its make method. This ensures that even if the database is compromised, the actual passwords of the users will not be exposed.
$user->password = Hash::make($request->password);
  1. Excluding Sensitive Information: When returning the user data in the response, the password field is now being excluded. This is done using the makeHidden method on the user model. This method temporarily hides the specified attributes from the model's array and JSON forms. This ensures that sensitive information like passwords are not exposed in the response.
$user = $user->makeHidden('password');

  1. Data Masking: Although not shown in the code, it is recommended to use data masking techniques to hide sensitive data in the request or response. This can be done by replacing actual data with fictitious but realistic data. This is especially useful when dealing with logs or when displaying data in a non-secure environment.

  2. HTTPS: Although not shown in the code, it is recommended to use HTTPS for all communications. This ensures that data in transit is encrypted and cannot be intercepted. This is typically done at the server or network level and not in the application code.

By implementing these changes, the system is now more secure and less likely to expose sensitive and confidential information.

References​

Last updated on