“And by so doing force example.com to load an old version of the Angular framework that allows bypassing of CSP, if the real https://scripts.example.com origin didn’t actually have a copy of that resource.” ➝ “and by so doing cause the UA to load and execute an old, vulnerable, or otherwise incorrect version of Angular in the context of example.com.”
“Similar restrictions might apply for features like Workers or ServiceWorkers which are required to be loaded same-origin as a similar security precaution.” ➝ “A similar risk might apply to features like Workers or ServiceWorkers. (As a security mechanism, UAs require that Workers and ServiceWorkers can only invoke scripts that come from the same origin. Origin laundering could bypass that mechanism.)”
—
“Luckily, browsers can do magic behind-the-scenes, and performance improvements, so long as they are correct from the perspective of application semantics and security, need not be precisely identical across the population of user agents.”
Suggestion for clarity/concision: “As long as they do not violate the application’s semantics (including security), performance improvements need not be uniform across the population of UAs.”
However, I’m not sure what that means. :)
—
“Origin laundering is a bit more difficult to address, but it can be handled with the same strategy that also informs population of the cache, so long as one is aware of the issue in advance.”
Question: What strategy is that?
—
Typo: “alloted” ➝ allotted
—
Ahh, I see now what double-keying is. Maybe put a “(see below)” in the 1st place you mention it.
—
“If a resource’s Content-Security-Policy header explicitly lists the hash of an external resource as allowed, that could be interpreted as an authoritative statement that its origin provenance is irrelevant” ➝ “If a resource’s Content-Security-Policy header explicitly lists the hash of an external resource as allowed, the UA could interpret that as an authoritative statement that the resource’s provenance is irrelevant”
The first bug report left off here:
“it would be bad if an attacker could inject the following into the resource:” ➝ “…inject the following code into the parent document:”
So here's the rest:
➝ <script src="https://scripts.example.com/angular.min.js" integrity="sha-256:DEADBEEF0BADCAFE…” />
“And by so doing force example.com to load an old version of the Angular framework that allows bypassing of CSP, if the real https://scripts.example.com origin didn’t actually have a copy of that resource.” ➝ “and by so doing cause the UA to load and execute an old, vulnerable, or otherwise incorrect version of Angular in the context of example.com.”
“Similar restrictions might apply for features like Workers or ServiceWorkers which are required to be loaded same-origin as a similar security precaution.” ➝ “A similar risk might apply to features like Workers or ServiceWorkers. (As a security mechanism, UAs require that Workers and ServiceWorkers can only invoke scripts that come from the same origin. Origin laundering could bypass that mechanism.)”
—
“Luckily, browsers can do magic behind-the-scenes, and performance improvements, so long as they are correct from the perspective of application semantics and security, need not be precisely identical across the population of user agents.”
Suggestion for clarity/concision: “As long as they do not violate the application’s semantics (including security), performance improvements need not be uniform across the population of UAs.”
However, I’m not sure what that means. :)
—
“Origin laundering is a bit more difficult to address, but it can be handled with the same strategy that also informs population of the cache, so long as one is aware of the issue in advance.”
Question: What strategy is that?
—
Typo: “alloted” ➝ allotted
—
Ahh, I see now what double-keying is. Maybe put a “(see below)” in the 1st place you mention it.
—
“If a resource’s Content-Security-Policy header explicitly lists the hash of an external resource as allowed, that could be interpreted as an authoritative statement that its origin provenance is irrelevant” ➝ “If a resource’s Content-Security-Policy header explicitly lists the hash of an external resource as allowed, the UA could interpret that as an authoritative statement that the resource’s provenance is irrelevant”