Skip to main content

Insecure object reference - User deletion

Need​

Enhancement of user deletion process and session management

Context​

  • Usage of PHP 7.0 for server-side scripting and web development
  • Usage of the User dependency for user-related functionality

Description​

Non compliant code​

public function destroy($id)
{
    $user = User::find($id);
    $user->delete();

    return redirect()->back();
}

The above code represents a function in a Laravel controller that deletes a user from the database. The function takes an ID as input, finds the user with that ID, and deletes the user.

The vulnerability here is that there are no checks in place to ensure that the user being deleted should be allowed to be deleted. This means that any user, regardless of their permissions, could potentially delete any other user. This could result in unauthorized user deletions and potentially render the application inoperative.

Additionally, after the user is deleted, the function redirects the user back to the previous page. This means that the user's session is not terminated upon deletion. If the user was logged in when they were deleted, they could potentially continue browsing the application even though their user record no longer exists in the database. This could lead to further issues and inconsistencies within the application.

Steps​

  • First, implement an authorization check to ensure that the user performing the deletion has the necessary permissions to do so. This could be done using middleware or within the destroy method itself.
  • Second, validate the user ID before attempting to delete the user. This could involve checking that the ID is a positive integer and that a user with that ID exists in the database.
  • Third, handle the case where the user does not exist. Instead of attempting to call the delete method on a null object, return an error message or redirect the user to a suitable page.
  • Fourth, after successfully deleting a user, invalidate their session to prevent them from continuing to use the application. This could be done by calling a method to log the user out or by manually deleting their session data.
  • Finally, consider implementing a soft delete functionality. This would mark the user as deleted in the database, but not actually remove their data. This can help prevent data loss and allows the user to be restored if necessary.

Compliant code​

public function destroy($id)
{
    // Check if the user has the necessary permissions to delete users
    if (!Auth::user()->canDeleteUsers()) {
        return redirect()->back()->withErrors(['You do not have permission to delete users.']);
    }

    // Validate the user ID
    if (!is_int($id) || $id <= 0) {
        return redirect()->back()->withErrors(['Invalid user ID.']);
    }

    // Find the user
    $user = User::find($id);

    // Check if the user exists
    if (!$user) {
        return redirect()->back()->withErrors(['User not found.']);
    }

    // Delete the user
    $user->delete();

    // Invalidate the user's session
    Auth::logout($user);

    return redirect()->back();
}

The updated code includes several measures to prevent insecure object reference vulnerabilities.

First, it checks if the currently authenticated user has the necessary permissions to delete users. This is done using the canDeleteUsers method, which should be defined on the User model and return a boolean indicating whether the user has the necessary permissions. If the user does not have permission, the method redirects back with an error message.

Next, it validates the user ID. The ID must be a positive integer. If it is not, the method redirects back with an error message.

The method then attempts to find the user with the given ID. If no user is found, it redirects back with an error message.

If the user is found, the method deletes the user and invalidates their session. This is done using the logout method, which should invalidate the user's session and prevent them from continuing to use the application.

Finally, the method redirects back. This could be to a page showing a list of users, or to a confirmation page showing that the user was successfully deleted.

References​

Last updated on