- Issue created by @prudloff
Contrib modules often add dangerous permissions (for example a permission that allows inserting JavaScript) without setting the "restrict access" flag.
The security team considers this a vulnerability and fixing it requires a security release.
I think we should try to have contrib module developers think about this flag from the start, to try to limit the number of security advisories related to this.
We should also try to improve the guidelines explaining which permissions should be restricted.
The PermissionHandler doc currently only says that the flag displays a security warning.
And the security policy says "Any user with one of the above permissions can already take over the site or bypass various access restrictions on the site".
I think this might not be enough for developers to make an informed decision. And it does not explicitly tell them that they should use this flag where appropriate or it will be considered a vulnerability.
It might not be easy to define exact rules but I think it should be something like "any permission that allows taking over the site or gaining access to an account with more permissions should be restricted".
And maybe give some examples of common ways to achieve this (inserting arbitrary JS, uploading PHP files, editing user roles, etc.).
Add a custom permission like this:
insert javascript:
title: 'Insert custom JavaScript into pages'
It should be defined like this:
insert javascript:
title: 'Insert custom JavaScript into pages'
restrict access: true
A solution could be to require setting "restrict access" explicitly to true or false.
This would force developers to think about it and make a conscious choice.
Active
11.0 🔥
other
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.