fix(sanitizer): improve reliability of sanitizer

[liamdebeasi]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

We received a report about 3 XSS attack vectors:

1. onload is fired in Chrome when the untrusted string is appended to the document fragment. Even though we later remove the onload attribute, Chrome has already executed the code.
2. javascript: code can be executed by adding special characters to the javascript: string. For example, adding java	script: is still interpreted by the browser as javascript:.
3. Sanitizer is susceptible to DOM clobbering by overriding Element.attributes. This allows attackers to add blocked attributes to their string.

What is the new behavior?

• Updated the sanitizer to return the empty string if onload= is detected anywhere in the untrusted string.
• Updated the sanitizer to also check the property values for javascript:.
• Updated the sanitizer to remove the element if its attributes is not of type NamedNodeMap which is what a non-clobbered Element.attributes should be: https://developer.mozilla.org/en-US/docs/Web/API/NamedNodeMap

Note: Long term we should move away from this custom sanitizer. This custom sanitizer was made in response to an older XSS vulnerability to mitigate that issue while avoiding breaking custom HTML functionality. A couple options:

1. Swap out our integration for DOMPurify. Would need to evaluate this solution.
2. Remove custom HTML support from these components. This would be breaking change, but it's also worth evaluating whether this feature is even used today.

Does this introduce a breaking change?

• Yes
• No

Other information

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.