Handling of dependent types #6
Comments
|
Another example is the |
|
Another variant: The contents of Somewhat aside, it's not obvious what type should be required for the contents (or URL) of a <script> element with |
|
We might be able to ignore What would be problematic is that we couldn't require TT for the HTML module import path: import doc from './my-html-module.html' as HTMLModule;We can't require A competing solution of including HTML from HTML markup seems like it doesn't get enough traction, although there's still possibility this will be possible via another element. |
|
Re: HTML module import: It seems fine to not require TrustedScriptURL for the module import path, since it's entirely determined at load time, i.e. should not be subject to injection vulnerabilities. For applications that are deployed via some form of build-time assembly, security reviewers can check at build time that there are, for instance, no imports from third-party sources. There is https://github.com/tc39/proposal-dynamic-import to consider. |
|
For vanilla module import paths we don't even have a way of using TTs (they cannot be expressions). For dynamic imports we should require TTs, but that's probably difficult to have, as it requires some changes from TC39, or some support in the spec for the runtime to enforce additional rules on the import path (it's probably required, as the runtime has to resolve the paths somehow - for browser they are URLs, for node - some magic identifiers). |
|
It seems like dynamic imports are already implemented in Safari & Chrome. From the polyfill, there's nothing we can do (we can't hook into Given that this is a string->code vector (while non-DOM), it's not clear to me whether we should make it in scope for TT enforcement, or rather leave it to base CSP cc @arturjanc |
|
It turns out actually, CSP |
|
IIUC, the specification for modules is split into two parts, and there's a
"host specific" part that describes how modules are actually loaded. This
is indeed part of the web platform spec,
https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-module-system.
Presumably, mention of how this interacts with CSP ought to go there?
…On Wed, Jun 20, 2018 at 6:40 AM Krzysztof Kotowicz ***@***.***> wrote:
It turns out actually, CSP script-src doesn't apply at all to dynamic
imports :(
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AED2jteiwTUYRjoWXFwHYoqnWqmN4aomks5t-lDogaJpZM4Phq3x>
.
|
|
We departed a little bit from the original issue (into module loading). IIUC, the only elements right now that have different contracts based on other attribute values are:
The most strict (for DOM XSS) For others, I think we might simply choose the most restrictive contract, and as such This approach is simple, and fails close. You have to create a type is a value can be used in a risky way, not when we are sure it will be used as such. In general this is always the case with TT - it's possible that the typed object is not added to the DOM at all, or is added to an inert DOM etc. |
|
One potential downside with this approach is that it requires application code to assign a stronger contract, which confers a higher level of trust, to values that don't actually merit that contract. This makes it imperative that the surrounding code ensures that the resulting TrustedTyped is in fact only assigned to the sink in that restricted context, and does not "escape" into the rest of the program, where it could be assigned to a sink with the assumption that it's actually safe in the sinks context (which it isn't). For instance, to assign an arbitrary string to iframe.srcdoc of a sandboxed iframe, it has to be converted to TrustedHTML without sanitization or escaping. One would have to be very careful that the resulting TrustedHTML doesn't "escape" and get assigned to another element's innerHTML. This was the main reasoning behind the Google/Closure APIs that set, e.g., both the |
|
A prospective solution to that might be what @briansmith proposed in #152 (comment), which is to outline the allowed sinks when producing the types. This allows one to create subtypes, only valid for certain sinks, but on the other hand creates type instances that are not interchangeable, which might lead to problems e.g. with bugs surfacing only at runtime. I think we should strive for a system that lets the runtime bugs be discoverable as early as possible, and that leverage the type system to allow for static analysis and refactorings. Brainstorming a bit: perhaps instead we could guard it at runtime in a different fashion? Each type object carries the name of the policy that created it (in polyfill, Chrome doesn't implement that yet). Perhaps authors might be able to configure some sinks to only accept objects from given policies? Statically, in a header, or dynamically via registering a callback that will always vet a value based on its policy name? My rough preference would be to leverage existing mechanism like changing the property setters, but I'm not sure if they would not get the already stringified value now. However, it does start to look like the complexity of such solution is too big, for a little gain. One extra related type interdependency is on ( |
|
I've confirmed that the property setters do not get the stringified arguments, so it seems adding additional restrictions to the sinks could work like that: |
|
Closing; The impact of the issue is quite narrow now, post- HTML import and TrustedURL deprecation (#204). I think only the sandbox iframe |
There are attributes where the required security type contract of the assigned value depends on the value of another attribute. Notably, the
<link>element's href attribute requires a type that represents a URL that references a trustworthy resource (TrustedResourceUrl in Closure; similar to TrustedScriptURL in this proposal), if the element'srelattribute has a value ofimportorstylesheet. For other values ofrel(e.g.,author) thehrefattribute is interpreted as a plain hyperlink, and hence a weaker contract suffices ("following the link / navigating to the URL does not result in any undesirable side effects such as script execution").This is a rather unfortunate design but we're presumably stuck with it.
In particular, we need to account for the possibility that the attribute that the type depends on (
rel) is changed from a value that requires the weaker contract to one that requires the stronger contract after the dependently-typed attribute (href) itself.In Closure, this is accounted for by a typed wrapper (
goog.dom.safe.setLinkHrefAndRel) that sets both attributes at the same time, and dynamically enforces the appropriate type contract, combined with disallowing direct assignment to either attribute (relorhref) in application source.In a native implementation of typed setters such a combined setter is likely undesirable. However, the issue could be addressed by changing the behavior of the
relattribute setter to clear thehrefattribute's value on assignment to therelattribute (or perhaps preferably, to throw an exception ifrelis assigned whenhrefalready has a non-empty value). The setter for thehrefattribute can then dynamically enforce the appropriate type contract depending on therelattribute's actual value.The text was updated successfully, but these errors were encountered: