Bug Alert: Unauthorized Subscription Cancellation In MoviePilot

Hey guys, this is a heads-up about a nasty little bug in MoviePilot that I've been wrestling with. It seems that a standard user (User A) is able to do something they really shouldn't: cancel the subscriptions of an admin user (User B). This is a big deal because it messes with the whole system of permissions and who can do what. Let's dive into the nitty-gritty of what's happening and how it's breaking things.

The Setup: Roles and Permissions

First off, let's get the cast of characters straight. We have User A, who's just a regular user with the ability to discover and subscribe to movies. Then there's User B, who's the big cheese, the admin, with all the power. User B subscribes to a movie, expecting that subscription to stick. Now, here's where things go sideways.

MoviePilot's core functionality should be ironclad in handling user roles and permissions. The design should clearly define what actions each user type is permitted to execute. Admins, in the ideal scenario, would possess complete control over content management, user administration, and system configurations. Standard users, on the other hand, should have more constrained privileges, primarily focused on personal content consumption, like searching, subscribing, and potentially rating movies. A critical aspect of this user management design is how subscriptions are handled. Typically, subscriptions should be tied to the specific user account that initiates them. This ensures that only the subscribing user or an authorized admin has the authority to alter the subscription status.

The current bug undermines this foundational setup. It basically allows User A, who should only have control over their own subscriptions, to reach out and mess with User B's subscriptions. This presents a serious threat to the integrity and functionality of the MoviePilot platform. If unchecked, such a vulnerability might lead to user frustration, content mismanagement, and even data security issues. It is crucial to address this bug to maintain the trust and usability of the platform. The implications of unauthorized subscription cancellation include potential loss of access to desired content, a distorted view of personalized recommendations, and a general erosion of trust in the system's reliability.

The Bug in Action: Unauthorized Cancellation

Here's how the bug plays out. User B subscribes to a movie. User A, surprisingly, can't see this subscription in the usual place (/web#/subscribe/movie). You'd think that would be the end of it, right? Wrong! User A can still find the movie through the recommendation/explore sections. And guess what? They can see that User B is subscribed, and then, they can unsubscribe User B from the movie.

This kind of unauthorized access can lead to a breakdown in how users interact with the app. Users might be confused about why their subscriptions are vanishing, especially if they don't know that someone else could be messing with them. This kind of unexpected behavior erodes trust in the platform and the whole subscription ecosystem. The vulnerability doesn’t only affect the intended functionality of user subscriptions but also compromises the integrity of the data that drives personalized recommendations and content discovery. The core principle of a subscription-based system is that a user's content preferences and subscriptions are managed securely and exclusively by the user themselves or by authorized administrators. Any breach of this principle potentially results in skewed user experiences and inaccurate data analysis. For example, if a user's subscriptions are unexpectedly cancelled, the recommendation engines might fail to reflect the user's actual interests, leading to poor content suggestions and a decline in user engagement. In addition, unauthorized modification of subscriptions can lead to user dissatisfaction, as the users are unable to access their desired content. Moreover, unexpected subscription cancellations may trigger support requests, adding to the operational overhead and potentially damaging the reputation of the platform.

The Investigation: What's Happening Behind the Scenes

I'm not exactly sure what's causing this. The logs and config files didn't give me any clues, but there are a few possibilities. It could be a problem with how the app checks permissions, perhaps failing to correctly identify User A's limited access. Another possibility is a glitch in how subscriptions are managed, allowing the system to misinterpret the user who is requesting the unsubscription. Another potential cause might lie in the frontend interface. Perhaps the interface is incorrectly displaying subscription states or improperly handling user actions related to subscriptions. Additionally, there could be database-related issues, where the records of subscriptions are stored or retrieved in an insecure way. The database queries might not have proper checks to ensure that unsubscription requests are only executed by the rightful owner of the subscription. Incorrect permission settings on server-side APIs that handle subscription management might also trigger the issue.

Furthermore, the Docker environment might be causing some issues, since it could be affecting how the application interacts with the underlying system or how it handles permissions. Or, it could be something totally unexpected! Figuring this out will likely involve digging into the code, retracing the steps, and seeing where the app is going wrong. This includes examining the request paths, function calls, and error handling mechanisms to pinpoint the source of the problem. This investigation helps confirm whether the error resides within the core application logic, the interface, or the infrastructure. A detailed analysis is essential to prevent similar security vulnerabilities in the future. The development team should ensure that a thorough review of the codebase is conducted to identify and address any other potential security risks.

Technical Details: The Setup

• Version: v2.8.1-1 (Latest as of this report)
• Environment: Docker
• Problem Type: Core Application Issue

I've double-checked my version against the latest release, searched through the issues and the Telegram channel, and made sure my description is clear. I hope this helps in squashing this bug!

Steps to Reproduce the Issue:

1. User B (admin) subscribes to a movie.
2. User A (regular user) finds the same movie through the recommendations or explore section.
3. User A sees the movie listed as subscribed (even though it's User B's subscription).
4. User A cancels the subscription.
5. User B's subscription is removed, even though User A shouldn't have the authority.

Expected Behavior:

User A should not be able to cancel User B's subscription. Only User B or an admin should have that power.

System Logs and Configuration Files:

(No specific logs or config files are provided, the bug is in the logic, not related to specific configurations.)

The Call to Action

So, the main thing is that we've got a serious problem. A standard user can unsubscribe another user, which is a major security flaw. I'm providing all the details I can, including the steps to reproduce the issue. Hopefully, the developers can quickly investigate this and fix it. We need to prevent any unauthorized modification of subscriptions in MoviePilot.

If you're a developer or maintainer, please pay special attention to the access controls and the logic used to manage user subscriptions. This bug is a priority. Make sure that each user is authorized to perform the operations they are attempting. Any unauthorized access can result in security and privacy implications for our users. By carefully reviewing and validating these steps, we can ensure that subscriptions are secure and that the experience for our users is seamless.