[Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

Jim Weiler jim.weiler at owasp.org
Tue Apr 19 14:54:39 UTC 2016


Thanks for the step by step description. I have 2 questions on SRI
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.
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.

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.

On Tue, Apr 19, 2016 at 4:49 AM, Stefano Di Paola <stefano at owasp.org> wrote:

> Hey,
> just chiming in to give some example :)
>
> On Tue, 2016-04-19 at 10:31 +0200, Antonio Fontes - OWASP wrote:
> > Hi,
> >
> > On 4/19/2016 12:57 AM, Weiler, Jim wrote:
> >
> > > If you assume a hacker breaches the 3rd party dev environment then the
> CSP checksum / subresource integrity  control is gone
> > > because the hacker could change the code and recompute the checksum,
> correct?
>
> SRI was created to block that kind of attacks.
>
> Github has several examples in its home page:
>  <link as="script"
> href="
> https://assets-cdn.github.com/assets/frameworks-b0c85b6eac5426cd1652deca19bc585e688aacec370c4541ab7f13cb5af4dc00.js"
> rel="preload" />
>
> or:
> <script src="https://3rdparty.co/xyz.js"
> integrity="SHA256-XXXXXXXXXXX"></script>
>
> Obviously if the attacker is able to change HTML *AND* 3rd Party JS then
> it's a complete defeat, but that's another story.
>
> > I'm not sure. From my understanding, script integrity checksums are to
> > be computed and verified under control of the invoking party:
> > - Org A computes checksums of org B's scripts (or verifies those
> > provided by the 3rd party)
> > - Org A puts checksums in org A's code
> > - If org B's scripts are compromised, org A's code will detect a breach
> > of integrity.
>
> That's correct.
>
> > However, if org A allows the 3rd party to provide its own checksums at
> > runtime, then indeed, that would constitute a vulnerability in regards
> > of the threat you described.
>
> Exactly!
>
> Cheers,
> Stefano
>
> >
> > cheers,
> > antonio
> >
> >
> >
> > > 4 other advantages of a server direct data layer that I will add are:
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 3. no 3rd party javascript executes on customer browsers, no CORS
> agreements are needed with vendors and no CSP ability is needed by vendors.
> > >
> > > 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
> > > 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;
> > > and
> > > 2. can be easily verified by security
> > >
> > > allows the host company to act with the speed and flexibility they
> want with minimal involvement from security.
> > >
> > > Please let me know any comments.
> > >
> > > Thanks Jim
> >
> >
> > _______________________________________________
> > OWASP-Leaders mailing list
> > OWASP-Leaders at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160419/7e02d42c/attachment.html>


More information about the OWASP-Leaders mailing list