Document SafeMarkup::set in Xss::filter

Sure, this is fair

+++ b/core/lib/Drupal/Component/Utility/Xss.php
@@ -79,6 +79,8 @@ public static function filter($string, $html_tags = array('a', 'em', 'strong', '
+    // Calling SafeMarkup::set() is acceptable here because all known XSS
+    // vectors will have been filtered out by now.

So, technically, if someone passes <script> in the $html_tags when they call this, then the XSS has been filtered. I think this is actually more like #2273925-256: Ensure #markup is XSS escaped in Renderer::doRender(). Also, I think we should emphasize why calling SafeMarkup::set() is correct rather than just acceptable.

Also, this is minor, but the regex is still doing some of the sanitization, so "by now" is slightly misleading I think.

So something like:

Strip any tags that are not in the whitelist, then mark the text as safe for output. All other known XSS vectors have been filtered out by this point, so it is acceptable to call SafeMarkup::set() on the resultant string.

Or something along those lines. Try to improve it from that probably. :)

Or something like:

...All other known XSS vectors have been filtered out by this point and any HTML tags remaining will have been deliberately allowed, so it is acceptable to call SafeMarkup::set() on the resultant string.

Looks ok to me, though we should make it harder for people to allow stupid things like SCRIPT, IFRAME, or OBJECT in the UI

Perfect, very thorough.

@pwolanin Maybe you could make a follow up but I believe we should let people shoot themselves in the foot sometimes and not mollycoddle them.

Great, thanks @joelpittet and @pwolanin!

The use is internal to Drupal's sanitization APIs, and we've had a member of the sec team check over this patch, so I think this is good as one of the "Document" issues. We could possibly use a followup about Xss more generally for #11.

This issue only changes documentation, so per https://www.drupal.org/core/beta-changes, this can be completed any time during the Drupal 8 beta phase. It's also part of resolving a critical issue. Committed and pushed to 8.0.x.

Looks ok to me, though we should make it harder for people to allow stupid things like SCRIPT, IFRAME, or OBJECT in the UI
....
@pwolanin Maybe you could make a follow up but I believe we should let people shoot themselves in the foot sometimes and not mollycoddle them.

See #275811: Warn about potentially insecure filter configurations