Files served at url are visible to anonymous users

Describe the bug User uploaded file viewer is wrapped in @login_required, but somehow both anonymous users and other users can see that users file.

To Reproduce Steps to reproduce the behavior:

1. Upload file “X.pdf” as user Y
2. Logout
3. As anonymous user, browse to show/X.pdf
4. File is visible or
5. As a different user, browse to show/X.pdf
6. File is visible

Expected behavior I expect to be redirected to my login view when an anonymous person tries to go to this address.

Desktop (please complete the following information):

• OS: MacOS, iOS
• Browser Safari & firefox
• Version Latest

Additional context Code

@app.route('/show/<filename>')
@login_required
def show(filename: str) -> Union[Response, str]:
    filename = secure_filename(filename)  # clean user input
    user_dir = os.path.join(app.config['UPLOAD_FOLDER'], current_user.uuid)
    if os.path.exists(os.path.join(user_dir, filename)):
        return send_from_directory(directory=user_dir, filename=filename)
    else:
        abort(404)

I honestly have no clue how this is happening. Each user has a unique uuid that acts as a unique directory where their files get stored to disk.

My bug might come from a misunderstanding of how cookies and session data are stored here. It might be relevant that I am accessing these file urls shortly after being logged in as the correct user that owns the files.

[elamje]

@ndavison Thanks for the detailed responses. After the entire day, I discovered what my problem was, and I’m sad to say it, was Cloudflare caching production. I was so confident I was thinking of every part of my stack, but I forgot about how aggressive Cloudflare caches content (images in this case).

I believe I was reproducing the issue locally because my browser was caching the results, but I’m going to look into it more.

Thanks again!

[ndavison]

What does your @login_manager.user_loader callback look like? As your comment above shows, the _id is sticky (looks like this will be fixed in the next major release https://github.com/maxcountryman/flask-login/pull/436) so if you’re using this for any sort of logic in loading the user from the cookie and session, it may be causing an issue.

In the /show/x route, which current_user id, name etc does it think is logged in when you’re experiencing the issue?

FYI, unrelated but based on your comment above, you’ll need to clear the CSRF token on login as otherwise it too is prone to session fixation issues - the attack could be an anonymous user generates a session with a CSRF token they know, somehow gives this session to another user (using some other vulnerability, like response header injection), this other user elevates the session into an authenticated one, and therefore the attacker knows this authenticated user’s CSRF token.