Compliance Impact

The vulnerability allows users with shared read-only access to delete or modify recipe books and entries, which can lead to unauthorized data modification and deletion.

Such unauthorized modifications and deletions could impact compliance with standards and regulations like GDPR and HIPAA, which require proper access controls and data integrity to protect personal and sensitive information.

Specifically, the lack of proper permission checks may violate principles of least privilege and data protection, potentially resulting in non-compliance with these regulations.

Useful 0 Not Useful 0

Executive Summary

The vulnerability in Tandoor Recipes affects the permission system in versions prior to 2.6.4. Specifically, the CustomIsShared permission class used in RecipeBookViewSet and RecipeBookEntryViewSet incorrectly grants permission for all HTTP methods, including unsafe ones like DELETE, PUT, and PATCH, without restricting these to read-only operations.

This means that any user who is in the shared list of a RecipeBook, who should only have read-only access, can actually delete or modify the RecipeBook and its entries. The permission check does not verify if the HTTP method is safe, allowing shared users to perform destructive actions.

The issue arises because the has_object_permission() method in CustomIsShared returns True for all HTTP methods without checking if the method is in SAFE_METHODS (GET, HEAD, OPTIONS). This flaw allows unauthorized modification and deletion by users who should only have read access.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have serious impacts if you use Tandoor Recipes prior to version 2.6.4. Users who are supposed to have only read-only access to shared RecipeBooks can instead delete entire RecipeBooks and their entries or modify them.

• Shared users can DELETE recipe books and entries, removing data they should not be able to.
• Shared users can PUT or PATCH recipe books and entries, overwriting names, descriptions, shared lists, and recipe details.

This leads to high integrity and availability impacts, as data can be maliciously or accidentally altered or deleted by unauthorized users.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by testing whether users with shared (read-only) access can perform unsafe HTTP methods such as DELETE, PUT, or PATCH on RecipeBook and RecipeBookEntry API endpoints.

Suggested commands to detect the vulnerability include sending HTTP requests as a shared user to the affected endpoints and observing if destructive actions succeed:

• PATCH /api/recipe-book/{id}/ to attempt changing the RecipeBook's name.
• DELETE /api/recipe-book/{id}/ to attempt deleting the entire RecipeBook.
• PATCH /api/recipe-book-entry/{id}/ to attempt modifying recipe book entry fields.
• DELETE /api/recipe-book-entry/{id}/ to attempt removing recipes from another user's book.

If these requests return successful HTTP responses (e.g., 200 OK for PATCH, 204 No Content for DELETE), the vulnerability is present.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include updating the permission classes used in the affected API endpoints to restrict unsafe HTTP methods for shared users.

Specifically, implement a new permission class `CustomIsSharedReadOnly` that allows only safe HTTP methods (GET, HEAD, OPTIONS) for shared users.

• Replace the existing permission composition `(CustomIsOwner | CustomIsShared) & CustomTokenHasReadWriteScope` with `(CustomIsOwner | CustomIsSharedReadOnly) & CustomTokenHasReadWriteScope` in `RecipeBookViewSet` and `RecipeBookEntryViewSet`.
• Alternatively, override the `destroy()` and `update()` methods in the ViewSets to explicitly check ownership before allowing modifications or deletions.

These changes prevent shared users from performing destructive or modifying actions, restoring the intended read-only access.

Useful 0 Not Useful 0