A lot of contrib modules sanitize user inputs with Xss::filter(), either calling it directly or indirectly (#markup or #prefix) for example.
This method can be called with a list of allowed tags but it will always allow every attribute except a list of dangerous attributes (most notably on* attributes).
The CKE config allows specifying allowed attributes, we should have the same control when sanitizing outside of CKE fields.
This would help mitigate (although not completely prevent) XSS attacks where the attacker needs to insert a tag with a specific attribute in the page.
We have seen multiple XSS vulnerabilities that could not be exploited in CKE fields (because they required a specific attribute that's usually not allowed, for example a specific data attribute) but could be exploited when using a module that sanitizes user inputs with Xss::filter().
Imagine a module that wants to allow some specific tags:
Xss::filter($userInput, ['a', 'b']);
The module knows it only cares about some very specific attributes (for example href) but has no way to restrict those.
While allowing other attributes is not dangerous by itself, it is always better to restrict what attackers can input and to use an allowlist rather than a blocklist.
I guess it does not make sense to separate the allowed attributes from the allowed tags.
But we could have something like this:
Xss::filter($userInput,
[
// Allow any attribute.
'b',
// Allow specific attributes.
'a' => ['href'],
// Don't allow any attribute.
'span' => []
]
);
Active
11.0 🔥
render system
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.