[Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

erlend at oftedal.no erlend at oftedal.no
Tue Apr 19 21:45:07 UTC 2016

I would argue that OWASP Top 10 A9 is important here as well. Risk of using js libs with known vulnerabilities, and om the client side it’s easy to detect.

Secondly with regards to Risk 2, I once found a big bunch of Norwegian sites (airport, intranet, webmail etc.) which referenced a statistics script from domain that was no longer registered…
SRI would still fix that of course.

Fra: Jim Manico
Sendt: tirsdag 19. april 2016 kl. 19:59
Til: Stefano Di Paola; Jim Weiler
Kopi: owasp-leaders at lists.owasp.org
Emne: Re: [Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

Thanks for jumping in here Stefano. It's been a long time. We need to
see you Italian JS/Security researchers pop up more often! :)

In short...

* SRI is to make sure files on third party servers are not modified
after the time of analysis.
* DOMPurify takes a chunk of HTML and makes is safe.

SRI is a much stronger candidate to help manage third party JavaScript.
One of the more common use cases of SRI is to provide integrity when a
"friendly" third party is hosting your code, like a CDN.  I made a few
changes to the cheatsheet to make SRI a bit more prominent in the
defense section.

If anyone has any other input regarding
please jump in!


On 4/19/16 5:46 AM, Stefano Di Paola wrote:
> 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
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20160419/529bae34/attachment.html>

More information about the OWASP-Leaders mailing list