This is a spinoff of https://security.drupal.org/node/93428 (release advisory at https://drupal.org/node/2059603), pdf https://drupal.org/files/sdo-php-injection.pdf
In short - a services client was able to update a text field with a restricted input format, because the only core check on format access relies on the forms api. It seems to me it's the responsibility of the text module to provide a hook_field_access implementation to guard against this.
Patch to follow.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 2060237-11-text-format-access.patch | 8.16 KB | wodenx |
| #9 | 2060237-8-text-format-access.patch | 8.74 KB | wodenx |
| #5 | 2060237-5-text-format-access.patch | 6.25 KB | wodenx |
| #3 | 2060237-3-text-filter-access.patch | 3.57 KB | wodenx |
| #1 | 2060237-text-format-access.patch | 3.12 KB | wodenx |
Comments
Comment #1
wodenx commentedComment #3
wodenx commentedHm - well, the exceptions are due to entities with no values set for certain fields, and that's easily fixed by the attached patch.
The failures in FilterFormatAccessTestCase are due to the fact that Field module just doesn't display fields on the edit form which the current user doesn't have access to edit.
I actually don't think that behavior is correct. I think Field should display the fields (if the user has the permission to view them), but disable the input elements if the user doesn't have sufficient privileges to edit them.
Either way, the filter tests would have to be rewritten.
Thoughts?
Comment #5
wodenx commentedSomething like this. The compromise here is that we have to allow users with 'administer filters' permission access to a field with a disallowed input format, so that the text-format widget can do its thing.
An alternative would be to keep field module's behavior the same, but then have the format widget restore the hidden field.
Comment #6
wodenx commentedComment #8
wodenx commented'edit' permission doesn't imply 'view' permission.
Comment #9
wodenx commentedComment #11
wodenx commented