There have been a few security issues created regarding this topic, however they have been pushed to be "made public" indicating that the "documenation should be enough":
string $message: (optional) The translated message to be displayed to the user. For consistency with other messages, it should begin with a capital letter and end with a period.
That implies that the message has been routed via t() and if t() is used correctly, there should not be raw html in there.
Documentation aside, what is "intended" does not mitigate that it is still technically possible to inject anything one desires via
A very real world example of this abuse is by the popular
devel module which exploits this loophole in core to display it's debugging output which does inject HTML (
Any module or custom code can pass whatever they want in
drupal_set_message() and then it's simply printed (as is) in
Most themes normally do not override this theme function, so they rely on core's implementation.
Simple example of exploit:
Unless a developer knows about this "implied" assumption, they could easily do something like the following and thus open up an XSS security vulnerability:
// Some "message" node. $node = node_load(1); // A user provided message. // Note: this could be a simple "text" field which doesn't have "filtering" // because it was designed to be a "simple" message. $message_field = field_get_items('node', $node, 'field_message'); // The message type (i.e. warning, error, status). $type_field = field_get_items('node', $node, 'field_type'); // Extract the message: // <script>window.alert("Let's see what damage we can do here.");</script> $message = $message_field['value']; // Extract the type. $type = $type_field['value']; // Display the message. drupal_set_message($message, $type);
Add an additional
$output argument to the function signature of drupal_set_message() like is done in drupal_set_title().
By default it should pass through the most permissive filter:
filter_xss_admin() with the option to "passthrough".
Note: this doesn't affect 8.x because variables printed in Twig templates that aren't an instance of MarkupInterface are auto-escaped.
- Create patch
- Create tests
User interface changes
Adds a new
$output argument to the
Data model changes