refactor(core): align namespaced attribute validation and security schema contexts - #68686
Conversation
b8677ee to
582f901
Compare
582f901 to
6222760
Compare
AndrewKushnir
left a comment
There was a problem hiding this comment.
LGTM, but also adding @alxhub to review from the compiler side, to make sure we are not missing any cases.
dgp1130
left a comment
There was a problem hiding this comment.
I think I'm only half following the logic here, but it seems generally fine. My only concern is that this seems to be getting more complicated and therefore easier to make mistakes, so I want to make sure we take the time to design these APIs so we're less likely to misuse them on accident.
| const nameToContext = (elName: string) => { | ||
| const [nsStr, name] = splitNsName(elName); | ||
| const ns = nsStr ?? namespaceKey; | ||
| const fullName = ns ? `:${ns}:${name}` : name; |
There was a problem hiding this comment.
Consider: The constant splitting / joining of the namespace makes me worried we can easily introduce a bug here. Especially with namespace being optional and easily omitted.
Would it be worth moving away from the "stringly" types here and make something like:
interface Tag {
tagName: string;
namespace?: string;
}And then we can use this type in the relevant functions with consistent serialize / deserialize functions to make sure we never drop the namespace and are always checking it as expected?
I have a similar concern with casing, where we might forget a .toLowerCase call, maybe there's a way to standardize that part too?
There was a problem hiding this comment.
We could definitely do that, but that's quite a chunky refactor. Since the elementName as a string is used in a lot of places.
| if (registry.hasElement(svgElement, [])) { | ||
| elementNames = [svgElement]; | ||
| } else if (registry.hasElement(mathElement, [])) { | ||
| elementNames = [mathElement]; | ||
| } |
There was a problem hiding this comment.
Question: Were these intended to be elementNames.push({svg,math}Element)? Why else is elementNames an array?
There was a problem hiding this comment.
This is to keep the existing behaviour, the array is initialized with allKnownElements when the selector has no element.
| 'animate': { | ||
| ':svg:animate': { | ||
| 'attributename': true, | ||
| 'to': SECURITY_SENSITIVE_ATTRIBUTE_NAMES, | ||
| 'values': SECURITY_SENSITIVE_ATTRIBUTE_NAMES, | ||
| 'from': SECURITY_SENSITIVE_ATTRIBUTE_NAMES, | ||
| }, | ||
| 'set': {'attributename': true, 'to': SECURITY_SENSITIVE_ATTRIBUTE_NAMES}, | ||
| 'animatemotion': {'attributename': true}, | ||
| 'animatetransform': {'attributename': true}, |
There was a problem hiding this comment.
Question: Do we not care about the existing animate attributes? Don't we need to keep these without the :svg: prefix?
There was a problem hiding this comment.
No, since now the parser prefixes them.
6222760 to
763bc63
Compare
…hema contexts Refactors the element security schema lookups and runtime attribute validation to consistently account for SVG and MathML namespaces. This improves the modularity and accuracy of security context mapping during template compilation and runtime constant evaluation, eliminating redundant or false-positive lifecycle checks.
…rity schema contexts
f26b773 to
ee5a9a8
Compare
…rity schema contexts
ee5a9a8 to
5fa9201
Compare
…rity schema contexts
josephperrott
left a comment
There was a problem hiding this comment.
LGTM
Reviewed-for: fw-security
|
Hi @alan-agius4, Great to see this refactor get merged! This completely addresses the underlying namespace literal matching and attribute validation gaps we discussed back in Issue #67902 and that I had flagged through the Bug Hunter program. Since this architectural cleanup solves the exact root cause pipeline from that initial research, I’d appreciate it if my early reporting and analysis on these namespace vectors could be recognized as part of the disclosure and credit path for this security update. Thanks for putting together such a thorough fix! |
|
Hi @VenkatKwest, although this is similar to the issue mentioned above, that specific report did not prove an XSS was possible. We later received distinct reports that clearly demonstrated XSS via different namespaced elements, such as While you were the first to bring this area to our attention, the original report lacked a working XSS proof-of-concept and thus was in-actionable. This isn't to undermine your work, but rather to clarify. |
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Refactors the element security schema lookups and runtime attribute validation to consistently account for SVG and MathML namespaces. This improves the modularity and accuracy of security context mapping during template compilation and runtime constant evaluation, eliminating redundant or false-positive lifecycle checks.