Attribute class does not sanitize for "javascript:alert('XSS')"

Could be a security bounty issue for you @Les Lim, so tagging in-case.

Anyways thoughts on resolution. Possibly stripping out attribute values from unsafe attributes. like javascript:, but we'd need a method like SafeMarkup/SafeString to override that in use-cases where those are practical.

Thanks for reporting this though!

Is there a proof of concept here?

Duplicate to the on Wim is working on to filter attributes?

#4: no, this is the theme/render system, not the filter system.

Which is exactly why there's no protection here: you should never ever pass user-created data to Attribute.

Ok, so I think we should mark this as "as designed"? The attributes class is not supposed to be checking attribute names.

Well, in this case you need a dangerous attribute name. So, possibly the code doc should be updated to make it clear that this doesn't check the actual names, just sanitizes HTML

I must be missed something, I have same comment to this issue

Why Why ? I don't understand. Danger strings in safe area, this is safe.

#2544110: XSS attribute filtering is inconsistent and strips valid attributes

onload="javascript:alert('XSS')"
This is the example in Summary. This is totally wrong.

#1. If you write custom code (in theme or PHP backend coding) and use onload and apply value. You expected THIS IS "JAVASCRIPT" and can be executed. (if Drupal stripped, it's bug)
#2. If you use javascript:alert('XSS') in non on* evetns, what's wrong ?

Here's a POC.

// test.php
// drush scr test.php
use Drupal\Core\Template\Attribute;

$render = \Drupal::service('renderer');
$attributes = new Attribute(['href' => 'javascript:alert(String.fromCharCode(88,83,83))']);
$xss = [
  '#type' => 'inline_template',
  '#template' => '<a{{ attributes }}>click me</a>',
  '#context' => ['attributes' => $attributes],
];
print $render->renderPlain($xss);

Yields:
<a href="javascript:alert(String.fromCharCode(88,83,83))">click me</a>

We are looking into hardening this but we have to try to avoid breaking mailto:

// Test
$mailto = 'mailto:me@example.com';
$result = UrlHelper::stripDangerousProtocols($mailto);
$this->assertEquals($mailto, $result);

Personally, I don't think it's an issue.

@see #6
@see #10: Point #1

Here's what developers should do:

$attributes = new Attribute(['href' => 

APPLY_XSS_FILTER_HERE('javascript:alert(String.fromCharCode(88,83,83))')

]);

If we do introduce it into Drupal, it should NOT enabled by default IMO.

This issue sounds like a duplicate of #2567743: Add protocol filtering to Attribute isn't it?

#13++

It is extremely confusing to see so many issues that are so heavily overlapping. Tentatively closing this one as a duplicate.