Originally reported to the Drupal security team by @poiu → on 2 April 2019 (#169784), which was subsequently considered a case for security hardening and not a vulnerability.
---
This proof of concept overrides the system/ajax url with the user supplied content of a file uploaded to a private file system, this requires an attacker to have the "Administer URL aliases" permission and the ability to upload private files. There may be other ways to exploit this as well.
It's kind of long, the TL:DR version is:
* Create a "system/ajax" url alias and point it at - say - "node"
* Go to system/ajax and see that you get the "node" page
Here's the long one:
* Create a poc.txt file containing:
[{"command":"insert","method":"html","data":"<img src=x onerror=alert(0)>"}]
* Install Drupal 7
* Go to admin/config/media/file-system
* Under "Private file system path" enter "sites/default/files/private"
* Click "Save configuration"
* Go to admin/structure/types/manage/page/fields
* Under "Add new field" enter "File"
* Under "Field type" select "File"
* Click "Save"
* Under "Upload destination" select "Private files"
* Click "Save field settings"
* Click "Save settings" again
* Go to node/add/page
* Fill in some title
* Click "Choose File"
* Select poc.txt
* Click "Upload"
* Hover over the poc.txt link to make sure it points to ".../system/files/poc.txt"
* Click "Save"
* Go to admin/config/search/path/add
* Under "Existing system path" enter "system/files/poc.txt"
* Under "Path alias" enter "system/ajax"
* Go to admin/structure/types/manage/article/display
* Click the gear icon on the "Image" field (on the far right)
* You should see an alert
I haven't tried it with D8 yet.
- poiu
- samuel.mortenson
- dsnopek
- mlhess
- Berdir
- effulgentsia
- moshe weitzman
- catch
---
Comment by @catch:
AJAX can now use GET in core, and Views does as of 10.1, so the idea to reject POST requests for private files would no longer be any mitigation at all, it would have been good to flip the restricted permission bit four years ago when it was suggested but at least let's try to do it now.
We should open a public issue to make 'administer URL aliases' have the 'restrict access' bit. It seems completely reasonable to add that based on the public information in https://www.drupal.org/project/drupal/issues/121362 🐛 Do not allow existing or reserved paths as aliases Needs work which is 16 years old now.
Needs review
7.0 ⚰️
Last updated
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.
If it would be sufficient to mark the permission as "trusted" (as @catch suggested), then uploading a patch with this change.
Adding a tag and a list of contributors in the original issue