[Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

Stefano Di Paola stefano at owasp.org
Tue Apr 19 15:46:46 UTC 2016


On Tue, 2016-04-19 at 10:54 -0400, Jim Weiler wrote:
> 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.

That's, indeed for 3rdparty scripts like CDN, but also for external
scripts that are not necessarily on a different server.
In the end the concern is about integrity. ;)

> 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.

`A` needs to precompute the content (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) :

$ curl -s
"https://assets-cdn.github.com/assets/frameworks-b0c85b6eac5426cd1652deca19bc585e688aacec370c4541ab7f13cb5af4dc00.js"|  openssl dgst -sha256 -binary | openssl enc -base64 -A 

sMhbbqxUJs0WUt7KGbxYXmiKrOw3DEVBq38Ty1r03AA=

Which is indeed the content in github.com (Cfr. "integrity" attr):
 <script crossorigin="anonymous"
integrity="sha256-sMhbbqxUJs0WUt7KGbxYXmiKrOw3DEVBq38Ty1r03AA="
src="https://assets-cdn.github.com/assets/frameworks-b0c85b6eac5426cd1652deca19bc585e688aacec370c4541ab7f13cb5af4dc00.js"></script>


> 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.

Yes, Dynamic JS is something completely different IMHO and hardly can fall in a SRI case.
Although one would have several scenarios where it's still reliable
i.e. when the output becomes static given expected input:
- JSONP based
- JS Aggregators
- others

Sandboxing JS is a very interesting solution, which, alas, has some
unsolved aspects
http://www.slideshare.net/mindedsecurity/sandboxing-js-and-html-a-lession-learned 

About DOMPurify, that's not for 3rd party JS but for untrusted HTML.

If we think that Google-Caja was born in 2010 as a projects aimed to
overcome the untrusted JS problem and we're still arguing about it.. 

Just my 2¢ :)
Cheers
Stefano
> 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
> >




More information about the OWASP-Leaders mailing list