[Owasp-leaders] 3rd Party JavaScript Management Cheatsheet

Jim Manico jim.manico at owasp.org
Fri May 27 17:18:26 UTC 2016


> Agreed on the 2nd point, but on the 1st one, if your hosting
environment is compromised then the attacker would change both the
checksum and the URL that the code comes from, no?

Indeed, that's a legit scenario. If your hosting environment is
compromised it's "game over". I was just walking over it all to make
sure we all get it. :)

The whole purpose of this standard to to protect the integrity of
downloaded files that you do NOT control. Like a JQuery lib hosted at
google....

Aloha, Jim


On 5/26/16 9:00 PM, The Black Labrador wrote:
> Agreed on the 2nd point, but on the 1st one, if your hosting
> environment is compromised then the attacker would change both the
> checksum and the URL that the code comes from, no?
>
> Mike
> ------------------------------------------------------------------------
> From: Jim Manico <mailto:jim.manico at owasp.org>
> Sent: ‎26/‎05/‎2016 17:40
> To: Weiler, Jim <mailto:Jim.Weiler at starwoodhotels.com>; Antonio Fontes
> - OWASP <mailto:antonio.fontes at owasp.org>; Ryan Barnett
> <mailto:ryan.barnett at owasp.org>; Rogan Dawes
> <mailto:rogan at dawes.za.net>; Kim Carter <mailto:kim.carter at owasp.org>;
> owasp-leaders at lists.owasp.org <mailto:owasp-leaders at lists.owasp.org>
> Subject: Re: [Owasp-leaders] 3rd Party JavaScript Management Cheatsheet
>
> > 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?
>
> No sir. The attacker would need to compromise BOTH the hosting
> environment of the 3rd party resource AND compromise your code where the
> hash resides.
>
> If the hacker ONLY compromises YOUR hosting environment they can change
> the hash and the hash would no longer match and the resource would not
> run.
>
> If the hacker ONLY compromises the THIRD PARTY hosting environment and
> changes the library code, then the hash will no longer match and the
> resource will not run.
>
> Aloha! - Jim
>
> On 4/18/16 12:57 PM, Weiler, Jim wrote:
> > I was planning to add risk sections, thanks.
> > 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?
> >
> > 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
> >
> > Jim Weiler       CISSP   CSSLP   GSSP - Java
> > Application Security Architect
> > Information Security Team
> > Starwood Hotels      1505 Washington St.   Braintree MA. 02184
> > mobile - 781 654 6048
> >
> > -----Original Message-----
> > From: owasp-leaders-bounces at lists.owasp.org
> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Antonio
> Fontes - OWASP
> > Sent: Monday, April 18, 2016 7:19 AM
> > To: Ryan Barnett; Rogan Dawes; Kim Carter; owasp-leaders at lists.owasp.org
> > Subject: Re: [Owasp-leaders] 3rd Party JavaScript Management Cheatsheet
> >
> > Hi,
> >
> > Just added a chapter about risks. Feel free to remove/edit it if
> inadequate :)
> >
> > cheers,
> > Antonio
> >
> >
> > --
> > OWASP Geneva Chapter
> > Contact: geneva at owasp.ch
> > Twitter: @owasp_geneva
> > Newsletter: https://lists.owasp.org/mailman/listinfo/owasp-geneva
> >
> > On 4/15/2016 2:59 PM, Ryan Barnett wrote:
> >> New Content Security Policy (CSP) has checksum support
> >> -
> >> https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Re
> >> factoring_inline_code
> >>
> >> Additionally, I would recommend some references to the following -
> >>
> >>   * DOMPurify - https://github.com/cure53/DOMPurify
> >>   * MentalJS - https://github.com/hackvertor/MentalJS
> >>
> >> Both of these can be used by sites to sandbox/clean DOM data.  If
> >> these are called up in the HTML header prior to other 3rd party JS
> >> code calls, it can provide protections.
> >>
> >> -Ryan
> >>
> >> From: <owasp-leaders-bounces at lists.owasp.org
> >> <mailto:owasp-leaders-bounces at lists.owasp.org>> on behalf of Rogan
> >> Dawes <rogan at dawes.za.net <mailto:rogan at dawes.za.net>>
> >> Date: Friday, April 15, 2016 at 5:41 AM
> >> To: Kim Carter <kim.carter at owasp.org <mailto:kim.carter at owasp.org>>,
> >> <owasp-leaders at lists.owasp.org <mailto:owasp-leaders at lists.owasp.org>>
> >> Subject: Re: [Owasp-leaders] 3rd Party JavaScript Management
> >> Cheatsheet
> >>
> >> My google-fu is weak today, but I'm pretty sure I recall reading about
> >> a mechanism to provide a checksum of an included resource in the
> >> including page, such that the browser will reject any content that
> >> does not match the checksum. That seems like a valuable addition to
> >> this cheat sheet, to me.
> >>
> >>
> >> On Fri, Apr 15, 2016 at 10:02 AM Kim Carter <kim.carter at owasp.org
> >> <mailto:kim.carter at owasp.org>> wrote:
> >>
> >>     Excellent! Doesn't seem to be anything there though...
> >>
> >>
> >>
> >>
> >>     Kim Carter
> >>
> >>     OWASP New Zealand Chapter Leader (Christchurch)
> >>
> >>     Author of *Holistic Info-Sec for Web Developers*
> >>     <https://leanpub.com/b/holisticinfosecforwebdevelopers>
> >>
> >>     c: +64 274 622 607
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>     On 15/04/16 09:10, Taras wrote:
> >>>     Hi!
> >>>
> >>>     It's a very interesting topic and good cheatsheet! My
> suggestions are:
> >>>     1. Add some code examples
> >>>     2. Add some diagrams to illustrate Server Direct flow
> >>>     3. What about using SRI (https://www.w3.org/TR/SRI/)? Can we
> use it
> >>>     here?
> >>>     4. What about using iframe from different domain (e.g. static data
> >>>     host) as "jail" for such 3rd party code? We can make communication
> >>>     between the host and this iframe with postMessage
> >>>
> >>>
> >>>     В Пн, 11/04/2016 в 16:41 -1000, Jim Manico пишет:
> >>>>     Hello folks,
> >>>>
> >>>>     Jim Weiler from the OWASP Boston chapter just released a
> cheatsheet
> >>>>     on 3rd party JavaScript management. I think this is a solid
> and very
> >>>>     interesting piece of work. It address a security concern
> which many
> >>>>     website operators face.
> >>>>
> >>>>     Take a look, your feedback is - as always - appreciated.
> >>>>
> >>>>    
> https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat
> >>>>     _Sheet
> >>>>
> >>>>     Aloha,
> >>>>     Jim Manico
> >>>>
> >>>>
> >>>>      _______________________________________________
> >>>>     OWASP-Leaders mailing list
> >>>>     OWASP-Leaders at lists.owasp.org
> >>>>
> >>>> <mailto:OWASP-Leaders at lists.owasp.org>https://lists.owasp.org/mailma
> >>>> n/listinfo/owasp-leaders
> >>>>
> >>>>
> >>>>     _______________________________________________
> >>>>     OWASP-Leaders mailing list
> >>>>     OWASP-Leaders at lists.owasp.org
> >>>>
> >>>> <mailto:OWASP-Leaders at lists.owasp.org>https://lists.owasp.org/mailma
> >>>> n/listinfo/owasp-leaders
> >>     _______________________________________________
> >>     OWASP-Leaders mailing list
> >>     OWASP-Leaders at lists.owasp.org
> <mailto:OWASP-Leaders at lists.owasp.org>
> >>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>
> >> _______________________________________________ OWASP-Leaders mailing
> >> list OWASP-Leaders at lists.owasp.org
> >> <mailto: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
> > This electronic message transmission contains information from the
> Company that may be proprietary, confidential and/or privileged. The
> information is intended only for the use of the individual(s) or
> entity named above. If you are not the intended recipient, be aware
> that any disclosure, copying or distribution or use of the contents of
> this information is prohibited. If you have received this electronic
> transmission in error, please notify the sender immediately by
> replying to the address listed in the "From:" field.
> > _______________________________________________
> > 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/20160527/c0bca1ba/attachment-0001.html>


More information about the OWASP-Leaders mailing list