<div dir="ltr">Thanks for the step by step description. I have 2 questions on SRI<div>1. if A computes the checksum, doesn't that mean that A has the script so why request it at all, just put it in the page.</div><div>2. if A receives the checksum from B, A has to trust that the script is not malicious, which means trusting that no B insider is malicious and that no hacker has breached B.</div><div><br></div><div>SRI also won't stop the XSS vulnerability that has been observed in the wild, where a the generated script is exactly what the business wants but it copies a DOM element that is susceptible to manipulation (e.g. request parameters) to a page location that will execute script.  This can be prevented by input validation (e.g.DOMPurify) at the server direct data layer. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 19, 2016 at 4:49 AM, Stefano Di Paola <span dir="ltr"><<a href="mailto:stefano@owasp.org" target="_blank">stefano@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
just chiming in to give some example :)<br>
<span class=""><br>
On Tue, 2016-04-19 at 10:31 +0200, Antonio Fontes - OWASP wrote:<br>
> Hi,<br>
><br>
> On 4/19/2016 12:57 AM, Weiler, Jim wrote:<br>
><br>
> > If you assume a hacker breaches the 3rd party dev environment then the CSP checksum / subresource integrity  control is gone<br>
> > because the hacker could change the code and recompute the checksum, correct?<br>
<br>
</span>SRI was created to block that kind of attacks.<br>
<br>
Github has several examples in its home page:<br>
 <link as="script"<br>
href="<a href="https://assets-cdn.github.com/assets/frameworks-b0c85b6eac5426cd1652deca19bc585e688aacec370c4541ab7f13cb5af4dc00.js" rel="noreferrer" target="_blank">https://assets-cdn.github.com/assets/frameworks-b0c85b6eac5426cd1652deca19bc585e688aacec370c4541ab7f13cb5af4dc00.js</a>" rel="preload" /><br>
<br>
or:<br>
<script src="<a href="https://3rdparty.co/xyz.js" rel="noreferrer" target="_blank">https://3rdparty.co/xyz.js</a>"<br>
integrity="SHA256-XXXXXXXXXXX"></script><br>
<br>
Obviously if the attacker is able to change HTML *AND* 3rd Party JS then<br>
it's a complete defeat, but that's another story.<br>
<span class=""><br>
> I'm not sure. From my understanding, script integrity checksums are to<br>
> be computed and verified under control of the invoking party:<br>
> - Org A computes checksums of org B's scripts (or verifies those<br>
> provided by the 3rd party)<br>
> - Org A puts checksums in org A's code<br>
> - If org B's scripts are compromised, org A's code will detect a breach<br>
> of integrity.<br>
<br>
</span>That's correct.<br>
<span class=""><br>
> However, if org A allows the 3rd party to provide its own checksums at<br>
> runtime, then indeed, that would constitute a vulnerability in regards<br>
> of the threat you described.<br>
<br>
</span>Exactly!<br>
<br>
Cheers,<br>
Stefano<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> cheers,<br>
> antonio<br>
><br>
><br>
><br>
> > 4 other advantages of a server direct data layer that I will add are:<br>
> ><br>
> > 1. performance - a page can easily have 50 or 100 tags each from a different vendor. Loading js from that many different sites, when the client is often far removed from the single or few vendor servers, can make a page unacceptably slow to load. Server direct eliminates this - all requests go to one tag manager url which will allow even a few dispersed servers to provide fast response because the requests are small, simple data value delivery, not requests for code.<br>
> ><br>
> > 2. centralization of data validation - DOMPurify or other validation logic can be applied to the data layer variables which are in a single page location and are much easier to document and keep track of, and can be implemented by security aware developers.<br>
> ><br>
> > 3. no 3rd party javascript executes on customer browsers, no CORS agreements are needed with vendors and no CSP ability is needed by vendors.<br>
> ><br>
> > 4. The key audience is the marketing team, not the web, middleware or application  development teams. The marketing team makes the agreements with 3rd party vendors. The ability to have<br>
> > 1. a simple security standard that says 'only use server direct and the host data layer'  when you use regardless of the  tool the host company chose to generate the client javascript;<br>
> > and<br>
> > 2. can be easily verified by security<br>
> ><br>
> > allows the host company to act with the speed and flexibility they want with minimal involvement from security.<br>
> ><br>
> > Please let me know any comments.<br>
> ><br>
> > Thanks Jim<br>
><br>
><br>
> _______________________________________________<br>
> OWASP-Leaders mailing list<br>
> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br>
<br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</div></div></blockquote></div><br></div>