XSS vulnerability in HTMLSanitizer might be insufficiently handled

Framework Knowledge
1

As stated elsewhere, @MedAziz1 recently blogged about the vulnerability in HTMLSanitizer that he reported back in 2019, resulting amongst other in this article and a tweet by the CVE team.

Aziz also expresses these worries: “The 2.0 version of its framework hasn’t been released and its biggest 1.x contributor is now working at Microsoft on fast so it remains to be seen what the future of the Aurelia framework [and its security] is,” he commented.

In the original discussion, @EisenbergEffect concluded this way:

I am not convinced that this addresses the concerns sufficiently. Many people will use the sanitizeHTML value converter without knowing about the issues, especially if they started using it before the docs were edited in 2019. There’s no guarantee that they will see the warning in the console, either.

My suggestion would be the following:

  1. Make HTMLSanitizer throw an error in its sanitize() function, requiring supplying a “real” implementation to work at all.
  2. Deprecate all previous versions of the aurelia-templating-resources NPM package, and possibly also aurelia-bootstrapper.
  3. (Perhaps too radical?) Make innerhtml.bind require and use a sanitizer implementation, with an explicit option to override.
2 Likes
2

Hello There,

Since there is already a discussion for this, I’d like to add a little something.
In the last couple of days, I’ve decided to check the pre-release version of Aurelia 2. I found that this issue appears to have found its way there . As can be seen below, the same default sanitizer (written in a slightly different way) is being used on the untrusted markup.

Concerned file:

1 Like
3

I created an issue for this:

1 Like