Skip to content
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

Jump to bottom

fix(compiler): promote constants in templates to Trusted Types #39211

Closed
wants to merge 2 commits into from
Closed

fix(compiler): promote constants in templates to Trusted Types #39211

wants to merge 2 commits into from

Conversation

@bjarkler
Copy link
Contributor

@bjarkler bjarkler commented Oct 10, 2020

Angular treats constant values of attributes and properties in templates
as secure. This means that these values are not sanitized, and are
instead passed directly to the corresponding setAttribute or setProperty
function. In cases where the given attribute or property is
security-sensitive, this causes a Trusted Types violation.

To address this, functions for promoting constant strings to each of the
three Trusted Types are introduced to Angular's private codegen API. The
compiler is updated to wrap constant strings with calls to these
functions as appropriate when constructing the consts array. This is
only done for security-sensitive attributes and properties, as
classified by Angular's dom_security_schema.

This is based on #39207. See the individual commits for more details.

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

This is part of an ongoing effort to add support for Trusted Types to Angular.
@google-cla google-cla bot added the cla: yes label Oct 10, 2020
@bjarkler bjarkler force-pushed the trusted-types-constants branch 2 times, most recently from 08a7a1f to 6e2e964 Oct 11, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 11, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
d238720 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler mentioned this pull request Oct 11, 2020
Closed
14 tasks
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 6e2e964 to 898d78c Oct 11, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 11, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
3c31f60 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler mentioned this pull request Oct 11, 2020
Closed
23 tasks
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 11, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
3fb5f14 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 12, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
118d8c5 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 898d78c to 6a0273b Oct 13, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 13, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
5d0253e 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 6a0273b to 4f7a86d Oct 13, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 13, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
28d133a 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 4f7a86d to 64aba01 Oct 13, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 13, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
b1434ad 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 64aba01 to 2a7204c Oct 13, 2020
@ngbot ngbot bot added this to the needsTriage milestone Oct 13, 2020
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 2a7204c to afff6f0 Oct 14, 2020
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 14, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
c9d2f97 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
IgorMinar
IgorMinar reviewed Oct 14, 2020
View changes
Copy link
Member

@IgorMinar IgorMinar left a comment

this change lgtm with just one nit about the naming of the private types.

the CI is happy as well. I kicked of g3 presubmit just so that we have a g3 signal as well, but I'm expecting that g3 will be happy as well.

packages/types.d.ts Show resolved Hide resolved
packages/core/src/util/security/trusted_type_defs.ts Outdated Show resolved Hide resolved
@pullapprove pullapprove bot requested review from IgorMinar Oct 14, 2020
@bjarkler bjarkler force-pushed the trusted-types-constants branch from afff6f0 to 3d6ae16 Oct 14, 2020
bjarkler added 2 commits Oct 14, 2020
@bjarkler
build: replace @types/trusted-types dep with minimal type defs
efdb4e5 
The @types/trusted-types type definitions are currently imported in
types.d.ts, which causes them to eventually be imported in core.d.ts.
This forces anyone compiling against @angular/core to provide the
@types/trusted-types package in their compilation unit, which we don't
want.

To address this, get rid of the @types/trusted-types and instead import
a minimal version of the Trusted Types type definitions directly into
Angular's codebase.

Update the existing references to Trusted Types to point to the new
definitions.
@bjarkler
fix(compiler): promote constants in templates to Trusted Types
b26a984 
Angular treats constant values of attributes and properties in templates
as secure. This means that these values are not sanitized, and are
instead passed directly to the corresponding setAttribute or setProperty
function. In cases where the given attribute or property is
security-sensitive, this causes a Trusted Types violation.

To address this, functions for promoting constant strings to each of the
three Trusted Types are introduced to Angular's private codegen API. The
compiler is updated to wrap constant strings with calls to these
functions as appropriate when constructing the `consts` array. This is
only done for security-sensitive attributes and properties, as
classified by Angular's dom_security_schema.
@bjarkler bjarkler force-pushed the trusted-types-constants branch from 3d6ae16 to b26a984 Oct 14, 2020
IgorMinar
IgorMinar approved these changes Oct 14, 2020
View changes
Copy link
Member

@IgorMinar IgorMinar left a comment

LGTM assuming that CI passes. 🤞

Reviewed-for: global-approvers

bjarkler added a commit to bjarkler/angular that referenced this issue Oct 14, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
82254ba 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 14, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
41c3754 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 15, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
32170b7 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
@bjarkler bjarkler mentioned this pull request Oct 15, 2020
Closed
14 tasks
@atscott atscott closed this in 9bfb508 Oct 15, 2020
atscott added a commit that referenced this issue Oct 15, 2020
@bjarkler @atscott
fix(compiler): promote constants in templates to Trusted Types (#39211)
6e18d2d 
Angular treats constant values of attributes and properties in templates
as secure. This means that these values are not sanitized, and are
instead passed directly to the corresponding setAttribute or setProperty
function. In cases where the given attribute or property is
security-sensitive, this causes a Trusted Types violation.

To address this, functions for promoting constant strings to each of the
three Trusted Types are introduced to Angular's private codegen API. The
compiler is updated to wrap constant strings with calls to these
functions as appropriate when constructing the `consts` array. This is
only done for security-sensitive attributes and properties, as
classified by Angular's dom_security_schema.

PR Close #39211
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 15, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
a292e37 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 15, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
8995625 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 16, 2020
@bjarkler
fix(core): promote i18n constants to Trusted Types
cc97cbc 
When an attribute has a constant value that is marked for translation
(i18n-attrName), a special variable is created in the `consts` array of
the compiled template. Since this is not a constant, it is not promoted
to a Trusted Type by angular#39211, and can thus cause Trusted Types
violations. The same applies to constant attributes parsed out of
(potentially translated) i18n ICU messages.

Use the newly introduced `SanitizerFn` to promote these constants
directly to appropriate Trusted Types. Tree shakability is not a concern
here since Trusted Types are already required for i18n to work (angular#39208).
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 28, 2020
@bjarkler
fix(core): mark Trusted Types as declarations
2a2c331 
Angular-internal type definitions for Trusted Types were added in angular#39211.
When compiled using the Closure compiler with certain optimization
flags, identifiers from these type definitions (such as createPolicy)
are currently uglified and renamed to shorter strings. This causes
Angular applications compiled in this way to fail to create a Trusted
Types policy, and fall bock to using strings.

To fix this, mark the internal Trusted Types definitions as declarations
using the "declare" keyword.
@bjarkler bjarkler mentioned this pull request Oct 28, 2020
Closed
14 tasks
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 28, 2020
@bjarkler
fix(core): mark Trusted Types as declarations
7c2f053 
Angular-internal type definitions for Trusted Types were added in angular#39211.
When compiled using the Closure compiler with certain optimization
flags, identifiers from these type definitions (such as createPolicy)
are currently uglified and renamed to shorter strings. This causes
Angular applications compiled in this way to fail to create a Trusted
Types policy, and fall bock to using strings.

To fix this, mark the internal Trusted Types definitions as declarations
using the "declare" keyword.
bjarkler added a commit to bjarkler/angular that referenced this issue Oct 29, 2020
@bjarkler
fix(core): mark Trusted Types as declarations
e59949d 
Angular-internal type definitions for Trusted Types were added in angular#39211.
When compiled using the Closure compiler with certain optimization
flags, identifiers from these type definitions (such as createPolicy)
are currently uglified and renamed to shorter strings. This causes
Angular applications compiled in this way to fail to create a Trusted
Types policy, and fall bock to using strings.

To fix this, mark the internal Trusted Types definitions as declarations
using the "declare" keyword. Also convert types to interfaces, for
the reasons explained in https://ncjamieson.com/prefer-interfaces/
josephperrott added a commit that referenced this issue Oct 29, 2020
@bjarkler @josephperrott
fix(core): mark Trusted Types as declarations (#39471)
f54662e 
Angular-internal type definitions for Trusted Types were added in #39211.
When compiled using the Closure compiler with certain optimization
flags, identifiers from these type definitions (such as createPolicy)
are currently uglified and renamed to shorter strings. This causes
Angular applications compiled in this way to fail to create a Trusted
Types policy, and fall bock to using strings.

To fix this, mark the internal Trusted Types definitions as declarations
using the "declare" keyword. Also convert types to interfaces, for
the reasons explained in https://ncjamieson.com/prefer-interfaces/

PR Close #39471
@angular-automatic-lock-bot
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Nov 15, 2020

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@IgorMinar IgorMinar

Assignees
No one assigned
Labels
action: merge cla: yes comp: compiler target: minor
Projects
None yet
Milestone
needsTriage
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
@bjarkler @IgorMinar @atscott