[Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

Jim Manico jim.manico at owasp.org
Tue Apr 19 17:54:00 UTC 2016


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
https://www.owasp.org/index.php?title=3rd_Party_Javascript_Management_Cheat_Sheet
please jump in!

Aloha,
Jim

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




More information about the OWASP-Leaders mailing list