Default configuration allows for spam attack

Problem/Motivation

Using the default configuration, which includes a public-facing temporary directory (e.g., public://filefield_paths), file entries on ajax-enabled forms will be available via a publicly-accessible URL prior to submission. This allows for an attacker to programmatically request a form and upload a malicious file, even if the form itself is never submitted. A preview link on the form will immediately confirm the success of the attack, and provide the publicly-accessible URL at which the malicious entry can be found.

As these partial submissions are stored in cached form_state, an attacker can work around most server-side mitigation measures by just not closing the browser tab on which the form is loaded. A malicious file, after being deleted from the server, can be reinstated by simply refreshing the form.

As far as we could tell from this instance, the purpose of the attack was to plant spam PDFs (advertising cryptocurrency, movie streams, etc.) The URLs to these PDFs were then submitted to and crawled by Google, resulting in prominent placement of the malicious files in search results. Realistically, this attack could be repurposed to any number of nefarious goals, depending only on the file types allowed by the form.

I would not classify that as just a bug in filefield_paths, as it also relies on a particular configuration. The key point is that using a publicly-accessible directory as the staging/holding area for file submissions definitely enables this attack. AJAX may or may not be necessary for this vector to work.

Once an attack has occurred, the steps taken by my team were to shut down the offending form (closes the door), delete the suspect files (remove the assets), and clear form/form_state cache (remove persistence). Attacks may reoccur at any time unless filefield_paths is configured to use a private directory for its staging area.