Make WordPress Core

Opened 4 weeks ago

Last modified 13 days ago

#44230 new defect (bug)

Export Personal Data Flaw

Reported by: psycleuk Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version: 4.9.6
Component: Privacy Keywords:
Focuses: Cc:


In testing the new export personal data feature that was introduced in WordPress 4.9.6, i believe i have found a flaw in how it works.

Once a user has confirmed the data request and an admin user clicks the send email option against the request, this creates the zip file in the uploads directory. The zip file is then publicly accessible to anyone that could work out the url for 3 days by default. This seems wrong to me, the zip file should only be accessible to the user who requested it.

As a work around i have had to reduce the expiry time of the zip file, using the wp_privacy_export_expiration filter to be 1 hour. To minimise the window that the file is available and at risk, but still give the requesting user time to access it.

Steps to reproduce:

  • follow the Export Personal Data request process to send the data email
  • use the link in the email to download the zip file, this can be performed by anyone who has/knows the link

Expected result:

  • the wp-personal-data-exports folder should have public access blocked
  • access to the zip file should be through a token (ideally single use) and validated against the requesting user before allowing download

Change History (5)

#1 @johnbillion
4 weeks ago

  • Keywords close reporter-feedback added

Thanks for the report, @psycleuk.

The zip file is then publicly accessible to anyone that could work out the url for 3 days by default.

The randomised string that gets appended to the file name has a length of 32 characters, and is generated by wp_generate_password() from a pool of 62 possible characters. This gives it an entropy of 32^62, which is a number containing over ninety digits.

Brute force guessing such a filename is therefore out of the question. Are you aware of a means of pre-calculating the filename?

Note also that the directory listing is not readable due to the existence of the index.html file in the directory.

#2 @desrosj
4 weeks ago

Related: #43546.

For a full breakdown on the thought process behind the file names, please see the explanation in https://core.trac.wordpress.org/ticket/43546#comment:34

#3 @psycleuk
3 weeks ago

Apologies for not being clear enough in my initial wording - our concerns are that the file has no access control on it.

How guessable the file name is bears no relevance, as secure by obscurity is not secure. Once the file has been created anyone can access it and download it.

As Wordpress is an open source CMS and by default the code is open, it would therefore not be too difficult to reverse engineer how the file is created to build a script to exploit it.

There is also a potential issue with using index.html as a way to block directory viewing of the personal data folder, as any server that is configured to not default to index.html would be exposed. Although, i do appreciate that catering for server configurations is a difficult task. Ideally using .htaccess to block all public access to this folder is preferred, then any developer using nginx only setups would need to copy the rules into the nginx config.

#4 @psycleuk
3 weeks ago

  • Keywords close removed

Removing the close keyword, as based on my above comment i don't believe this issue should be considered resolved.

Last edited 3 weeks ago by psycleuk (previous) (diff)

#5 @psycleuk
13 days ago

  • Keywords reporter-feedback removed

Missed removing the reporter-feedback keyword on my previous comments.

Again, i reiterate my point that security by obscurity is not secure. The current implementation has no ACL on who can download the created zip file, which it should be only the user that the data is about and they should have to login to get access to it.

Note: See TracTickets for help on using tickets.