fix(sanitizeUri): sanitize URIs that contain IDEOGRAPHIC SPACE chars #16311
Conversation
petebacondarwin
force-pushed
the
sanitize-mxss-issue-16288
branch
from
bf1f5d0
to
80cfb04
Compare
|
I have removed the |
|
The commit message is too long & it makes the build fail. |
|
I'm not sure if the description in this fix is 100% correct. So either the test is wrong, or the description is wrong (the string in the test is not dangerous, because it is not executed). I think it makes sense to explicitly trim the string before sanitizing it though. The description should be more precise though. |
|
@Narretz - you have to apply the "evil" text via You can see it happening on Chrome 61 here: https://plnkr.co/edit/Y6EsbsuDgd18YTn1oARu?p=preview Background: http://www.nds.rub.de/media/emma/veroeffentlichungen/2013/12/10/mXSS-CCS13.pdf |
petebacondarwin
force-pushed
the
sanitize-mxss-issue-16288
branch
from
80cfb04
to
769306d
Compare
|
@petebacondarwin Thanks for clarifying. The part about innerHTML and the link should be a code comment or part of the commit message. |
|
@Narretz :-( after I just got Travis to go green too |
Browsers mutate attributes values such as `&angular#12288;javascript:alert(1)` when they are written to the DOM via `innerHTML` in various vendor specific ways. In Chrome (<62), this mutation removed the preceding "whitespace" resulting in a value that could end up being executed as JavaScript. Here is an example of what could happen: https://plnkr.co/edit/Y6EsbsuDgd18YTn1oARu?p=preview If you run that in Chrome 61 you will get a dialog box pop up. There is background here: http://www.nds.rub.de/media/emma/veroeffentlichungen/2013/12/10/mXSS-CCS13.pdf The sanitizer has a bit of code that triggers this mutation on an inert piece of DOM, before we try to sanitize it: https://github.com/angular/angular.js/blob/817ac567/src/ngSanitize/sanitize.js#L406-L417 Chrome 62 does not appear to mutate this particular string any more, instead it just leaves the "whitespace" in place. This probably means that Chrome 62 is no longer vulnerable to this specific attack vector; but there may be other mutating strings that we haven't found, which are vulnerable. Since we are leaving the mXSS check in place, the sanitizer should still be immune to any strings that try to utilise this attack vector. This commit uses `trim()` to remove the IDEOGRAPHIC SPACE "whitespace" before sanitizing, which allows us to expose this mXSS test to all browsers rather than just Chrome. Closes angular#16288
|
I updated the commit message |
petebacondarwin
force-pushed
the
sanitize-mxss-issue-16288
branch
from
769306d
to
ec3673d
Compare
|
LGTM |
| expectHTML('<a href="　javascript:alert(1)">CLICKME</a>').toBe('<a>CLICKME</a>'); | ||
| }); | ||
| } | ||
| it('should prevent mXSS attacks', function() { |
There was a problem hiding this comment.
TBH, I don't think this test does what it says it does, but that is not related to this PR (it was like that before).
(It is more like it should not be too strict in preventing mXSS aattacks 😃)
Chrome 62 was not sanitizing dangerous URLs containing
JavaScript, if they started with these "whitespace" characters.
Closes #16288
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
fix
What is the current behavior? (You can also link to an open issue here)
#16288
What is the new behavior (if this is a feature change)?
URIs are sanitized correctly on Chrome 62
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements
Other information: