1839402 - Clickjacking protection for the filepicker window

Status: UNCONFIRMED

(Core :: Security, enhancement)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:114.0) Gecko/20100101 Firefox/114.0

Steps to reproduce:

1. In about:preferences configure Firefox to always ask where to save a file.
2. On Windows 10 (and probably Windows 11) start an "unexpected" download on any website (by clicking the related site-element to trigger an immediate or delayed download).
3. Just pretend doing your casual mouse-inputs meanwhile.

Actual results:

The filepicker window opens without any clickjacking protection, potentially causing the user to do unintentional and possibly harmful things (e.g. moving a file by accident).

Expected results:

Some form of clickjacking protection should have been provided.

Additional details:

This became a theoretical issue after major changes to the download behavior have been implemented quite a few versions ago now. For me it never became an issue until today where I clicked an element on a random website I tried some stuff out where it was not obvious to me it would trigger a download. In the time the filepicker window opened I did a left click as well - luckily it landed inside the filename field and nothing happened. But with the delayed opening of the filepicker window (e.g. using a HDD (which was the case here) or non-immediate downloads) and fast paced mouse movement it would be easy to do unintended things (e.g. moving a file into a directory where it does not belong to).

Actually, maybe it wasn't even a download I triggered - it also could have been the filepicker window variant for choosing a file to upload. In either case, the issue would apply to all instances where the filepicker window has no explicit clickjacking protection.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emma Zühlcke [:emz]]

We show a warning prompt before uploading an entire folder, but we don't have one for single file uploads AFAIC.

Comment 3

[sworddragon2]

(In reply to Paul Zühlcke [:pbz] from comment #2)

We show a warning prompt before uploading an entire folder, but we don't have one for single file uploads AFAIC.

I just tested this by clicking on an element on a website that triggers the filepicker window for a file/folder upload each. There is no warning before the filepicker window opens so I assume the warning just appears after you select a folder to upload. But this does not prevent the issue I described here as the filepicker window for folder uploads can still be clickjacked intentionally or by accident unless you had in mind moving the warning before the filepicker window opens to also utilize it as clickjacking-protection.

Comment 4

[Emma Zühlcke [:emz]]

(In reply to sworddragon2 from comment #3)

(In reply to Paul Zühlcke [:pbz] from comment #2)

We show a warning prompt before uploading an entire folder, but we don't have one for single file uploads AFAIC.

I just tested this by clicking on an element on a website that triggers the filepicker window for a file/folder upload each. There is no warning before the filepicker window opens so I assume the warning just appears after you select a folder to upload. But this does not prevent the issue I described here as the filepicker window for folder uploads can still be clickjacked intentionally or by accident unless you had in mind moving the warning before the filepicker window opens to also utilize it as clickjacking-protection.

I would argue that clickjacking is only problematic if it actually leads to an unwanted action, such as uploading the data to the website. That shouldn't happen until you confirm our folder upload confirmation dialog. Though again, we don't have this dialog for individual file uploads.

Comment 5

[sworddragon2]

(In reply to Paul Zühlcke [:pbz] from comment #4)

I would argue that clickjacking is only problematic if it actually leads to an unwanted action, such as uploading the data to the website. That shouldn't happen until you confirm our folder upload confirmation dialog. Though again, we don't have this dialog for individual file uploads.

There are several unwanted actions that can happen with varying severity:

• Changes to saved settings of the filepicker window itself due to an unwanted click (like changing a sorting). That is not a big deal but still quite undesired especially since it might be hard to track for an user if anything and what changed.
• Changes to the filesystem itself like in the case I mentioned in this report which was not far from happening to me as well. That might be less or more problematic depending on the case and again it would be difficult for an user to notice if and what changed.
• Leaks due to unintended uploads. But this is already partly mitigated as you pointed out.

In the past I was thinking if this is not actually a problem of the filepicker window itself. Does the Windows API (and respective other platforms) not support calling it in a safe manner for such purposes, e.g. the filepicker window grays then all elements out for a second before it responds to user input? As this could be an easy fix then (if desired) - and also possibly a simplification for the upload confirmation dialog.