New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(compiler): disallow i18n of security-sensitive attributes #39554
Conversation
ee12e9f
to
7d0c6b1
Compare
7d0c6b1
to
2898f35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just added a couple comments 👍
2898f35
to
d391b8d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a few nits, but otherwise this looks good to me.
Reviewed-for: global-approvers, fw-security
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With cleanup
Create a schema with an associated function to classify Trusted Types sinks. Piggyback a typo fix.
Make it possible to report errors from the I18nMetaVisitor parser.
To minimize security risk (XSS in particular) in the i18n pipeline, disallow i18n translation of attributes that are Trusted Types sinks. Add integration tests to ensure that such sinks cannot be translated.
Previously all constant values of security-sensitive attributes and properties were promoted to Trusted Types. While this is not inherently bad, it is also not optimal. Use the newly added Trusted Types schema to restrict promotion to constants that are in a Trusted Types-relevant context.
Script tags, inline event handlers and other script contexts are forbidden or stripped from Angular templates by the compiler. In the context of Trusted Types, this leaves no sinks that require use of a TrustedScript. This means that trustConstantScript is never used, and can be removed.
d391b8d
to
e676df2
Compare
Thanks for the comments everyone. I think all of them have been addressed now. Just started a global presubmit; will update the PR tomorrow with the results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thanks for the updates @bjarkler!
Reviewed-for: global-approvers, fw-security
I'm unflagging this as a breaking change since we have no evidence that there is any valid use of this feature today. |
FYI, adding the "presubmit" label since we are waiting for TAP run results from @bjarkler. |
@bjarkler, please let us know once you get presubmit results so we can proceed with merging this PR. Thank you. |
Just a quick note: we've discussed this offline with @bjarkler and this PR is ready to go. Thank you. |
Make it possible to report errors from the I18nMetaVisitor parser. PR Close #39554
To minimize security risk (XSS in particular) in the i18n pipeline, disallow i18n translation of attributes that are Trusted Types sinks. Add integration tests to ensure that such sinks cannot be translated. PR Close #39554
…#39554) Previously all constant values of security-sensitive attributes and properties were promoted to Trusted Types. While this is not inherently bad, it is also not optimal. Use the newly added Trusted Types schema to restrict promotion to constants that are in a Trusted Types-relevant context. PR Close #39554
…39554) Script tags, inline event handlers and other script contexts are forbidden or stripped from Angular templates by the compiler. In the context of Trusted Types, this leaves no sinks that require use of a TrustedScript. This means that trustConstantScript is never used, and can be removed. PR Close #39554
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
It is currently possible to mark security-sensitive attributes for i18n translation, e.g.:
This is a feature that should have very little use, but at the same time introduces complexity and security risk in the i18n pipeline.
What is the new behavior?
The above template now generates a parsing error:
(The same error occurs when using
ng extract-i18n
.)Note that this only applies to attributes/properties that are relevant to Trusted Types, which are now enumerated in trusted_types_schema.ts:
frame.srcdoc
*.innerHTML
*.outerHTML
embed.src
object.codebase
object.data
These can be considered the most risky attributes/properties in terms of XSS. (Note that the script tag, inline event handlers, and other attributes/properties of a script context are not relevant here as they are already forbidden or stripped out by the compiler.)
Piggyback:
trustConstScript
, as it was never needed.Does this PR introduce a breaking change?
This seems to be used extremely rarely. Sifting through GitHub search results for i18n-src only reveals a single result that might be affected by this change. (Note that e.g.
<img i18n-src
is not affected, since it is not a security-sensitive attribute.)For applications that need to migrate away from this pattern, translation can be done in the corresponding TS file and regular interpolation used in the Angular template instead.
Other information