<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>> 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?</p>
    <p>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. :)</p>
    <p>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....<br>
    </p>
    <p>Aloha, Jim<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 5/26/16 9:00 PM, The Black Labrador
      wrote:<br>
    </div>
    <blockquote
      cite="mid:5747f098.22d8c20a.61040.ffffff7a@mx.google.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div>
        <div style="font-family: Calibri,sans-serif; font-size: 11pt;">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?<br>
          <br>
          Mike</div>
      </div>
      <div dir="ltr">
        <hr><span style="font-family: Calibri,sans-serif; font-size:
          11pt; font-weight: bold;">From: </span><span
          style="font-family: Calibri,sans-serif; font-size: 11pt;"><a
            moz-do-not-send="true" href="mailto:jim.manico@owasp.org">Jim
            Manico</a></span><br>
        <span style="font-family: Calibri,sans-serif; font-size: 11pt;
          font-weight: bold;">Sent: </span><span style="font-family:
          Calibri,sans-serif; font-size: 11pt;">‎26/‎05/‎2016 17:40</span><br>
        <span style="font-family: Calibri,sans-serif; font-size: 11pt;
          font-weight: bold;">To: </span><span style="font-family:
          Calibri,sans-serif; font-size: 11pt;"><a
            moz-do-not-send="true"
            href="mailto:Jim.Weiler@starwoodhotels.com">Weiler, Jim</a>;
          <a moz-do-not-send="true"
            href="mailto:antonio.fontes@owasp.org">Antonio Fontes -
            OWASP</a>; <a moz-do-not-send="true"
            href="mailto:ryan.barnett@owasp.org">Ryan Barnett</a>; <a
            moz-do-not-send="true" href="mailto:rogan@dawes.za.net">Rogan
            Dawes</a>; <a moz-do-not-send="true"
            href="mailto:kim.carter@owasp.org">Kim Carter</a>; <a
            moz-do-not-send="true"
            href="mailto:owasp-leaders@lists.owasp.org"><a class="moz-txt-link-abbreviated" href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a></a></span><br>
        <span style="font-family: Calibri,sans-serif; font-size: 11pt;
          font-weight: bold;">Subject: </span><span style="font-family:
          Calibri,sans-serif; font-size: 11pt;">Re: [Owasp-leaders] 3rd
          Party JavaScript Management Cheatsheet</span><br>
        <br>
      </div>
      > If you assume a hacker breaches the 3rd party dev environment
      then the<br>
      CSP checksum / subresource integrity control is gone because the
      hacker<br>
      could change the code and recompute the checksum, correct?<br>
      <br>
      No sir. The attacker would need to compromise BOTH the hosting<br>
      environment of the 3rd party resource AND compromise your code
      where the<br>
      hash resides.<br>
      <br>
      If the hacker ONLY compromises YOUR hosting environment they can
      change<br>
      the hash and the hash would no longer match and the resource would
      not run.<br>
      <br>
      If the hacker ONLY compromises the THIRD PARTY hosting environment
      and<br>
      changes the library code, then the hash will no longer match and
      the<br>
      resource will not run.<br>
      <br>
      Aloha! - Jim<br>
      <br>
      On 4/18/16 12:57 PM, Weiler, Jim wrote:<br>
      > I was planning to add risk sections, thanks.<br>
      > 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?<br>
      ><br>
      > 4 other advantages of a server direct data layer that I will
      add are:<br>
      ><br>
      > 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.<br>
      ><br>
      > 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.<br>
      ><br>
      > 3. no 3rd party javascript executes on customer browsers, no
      CORS agreements are needed with vendors and no CSP ability is
      needed by vendors.<br>
      ><br>
      > 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<br>
      > 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;<br>
      > and<br>
      > 2. can be easily verified by security<br>
      ><br>
      > allows the host company to act with the speed and flexibility
      they want with minimal involvement from security.<br>
      ><br>
      > Please let me know any comments.<br>
      ><br>
      > Thanks Jim<br>
      ><br>
      > Jim Weiler       CISSP   CSSLP   GSSP - Java<br>
      > Application Security Architect<br>
      > Information Security Team<br>
      > Starwood Hotels      1505 Washington St.   Braintree MA.
      02184<br>
      > mobile - 781 654 6048<br>
      ><br>
      > -----Original Message-----<br>
      > From: <a class="moz-txt-link-abbreviated" href="mailto:owasp-leaders-bounces@lists.owasp.org">owasp-leaders-bounces@lists.owasp.org</a>
      [<a class="moz-txt-link-freetext" href="mailto:owasp-leaders-bounces@lists.owasp.org">mailto:owasp-leaders-bounces@lists.owasp.org</a>] On Behalf Of
      Antonio Fontes - OWASP<br>
      > Sent: Monday, April 18, 2016 7:19 AM<br>
      > To: Ryan Barnett; Rogan Dawes; Kim Carter;
      <a class="moz-txt-link-abbreviated" href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a><br>
      > Subject: Re: [Owasp-leaders] 3rd Party JavaScript Management
      Cheatsheet<br>
      ><br>
      > Hi,<br>
      ><br>
      > Just added a chapter about risks. Feel free to remove/edit it
      if inadequate :)<br>
      ><br>
      > cheers,<br>
      > Antonio<br>
      ><br>
      ><br>
      > --<br>
      > OWASP Geneva Chapter<br>
      > Contact: <a class="moz-txt-link-abbreviated" href="mailto:geneva@owasp.ch">geneva@owasp.ch</a><br>
      > Twitter: @owasp_geneva<br>
      > Newsletter:
      <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-geneva">https://lists.owasp.org/mailman/listinfo/owasp-geneva</a><br>
      ><br>
      > On 4/15/2016 2:59 PM, Ryan Barnett wrote:<br>
      >> New Content Security Policy (CSP) has checksum support<br>
      >> -<br>
      >>
      <a class="moz-txt-link-freetext" href="https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Re">https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Re</a><br>
      >> factoring_inline_code<br>
      >><br>
      >> Additionally, I would recommend some references to the
      following -<br>
      >><br>
      >>   * DOMPurify - <a class="moz-txt-link-freetext" href="https://github.com/cure53/DOMPurify">https://github.com/cure53/DOMPurify</a><br>
      >>   * MentalJS - <a class="moz-txt-link-freetext" href="https://github.com/hackvertor/MentalJS">https://github.com/hackvertor/MentalJS</a><br>
      >><br>
      >> Both of these can be used by sites to sandbox/clean DOM
      data.  If<br>
      >> these are called up in the HTML header prior to other 3rd
      party JS<br>
      >> code calls, it can provide protections.<br>
      >><br>
      >> -Ryan<br>
      >><br>
      >> From: <<a class="moz-txt-link-abbreviated" href="mailto:owasp-leaders-bounces@lists.owasp.org">owasp-leaders-bounces@lists.owasp.org</a><br>
      >> <a class="moz-txt-link-rfc2396E" href="mailto:owasp-leaders-bounces@lists.owasp.org"><mailto:owasp-leaders-bounces@lists.owasp.org></a>>
      on behalf of Rogan<br>
      >> Dawes <<a class="moz-txt-link-abbreviated" href="mailto:rogan@dawes.za.net">rogan@dawes.za.net</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:rogan@dawes.za.net"><mailto:rogan@dawes.za.net></a>><br>
      >> Date: Friday, April 15, 2016 at 5:41 AM<br>
      >> To: Kim Carter <<a class="moz-txt-link-abbreviated" href="mailto:kim.carter@owasp.org">kim.carter@owasp.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:kim.carter@owasp.org"><mailto:kim.carter@owasp.org></a>>,<br>
      >> <<a class="moz-txt-link-abbreviated" href="mailto:owasp-leaders@lists.owasp.org">owasp-leaders@lists.owasp.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:owasp-leaders@lists.owasp.org"><mailto:owasp-leaders@lists.owasp.org></a>><br>
      >> Subject: Re: [Owasp-leaders] 3rd Party JavaScript
      Management<br>
      >> Cheatsheet<br>
      >><br>
      >> My google-fu is weak today, but I'm pretty sure I recall
      reading about<br>
      >> a mechanism to provide a checksum of an included resource
      in the<br>
      >> including page, such that the browser will reject any
      content that<br>
      >> does not match the checksum. That seems like a valuable
      addition to<br>
      >> this cheat sheet, to me.<br>
      >><br>
      >><br>
      >> On Fri, Apr 15, 2016 at 10:02 AM Kim Carter
      <<a class="moz-txt-link-abbreviated" href="mailto:kim.carter@owasp.org">kim.carter@owasp.org</a><br>
      >> <a class="moz-txt-link-rfc2396E" href="mailto:kim.carter@owasp.org"><mailto:kim.carter@owasp.org></a>> wrote:<br>
      >><br>
      >>     Excellent! Doesn't seem to be anything there
      though...<br>
      >><br>
      >><br>
      >><br>
      >><br>
      >>     Kim Carter<br>
      >><br>
      >>     OWASP New Zealand Chapter Leader (Christchurch)<br>
      >><br>
      >>     Author of *Holistic Info-Sec for Web Developers*<br>
      >>    
      <a class="moz-txt-link-rfc2396E" href="https://leanpub.com/b/holisticinfosecforwebdevelopers"><https://leanpub.com/b/holisticinfosecforwebdevelopers></a><br>
      >><br>
      >>     c: +64 274 622 607<br>
      >><br>
      >><br>
      >><br>
      >><br>
      >><br>
      >><br>
      >><br>
      >><br>
      >>     On 15/04/16 09:10, Taras wrote:<br>
      >>>     Hi!<br>
      >>><br>
      >>>     It's a very interesting topic and good
      cheatsheet! My suggestions are:<br>
      >>>     1. Add some code examples<br>
      >>>     2. Add some diagrams to illustrate Server Direct
      flow<br>
      >>>     3. What about using SRI
      (<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/SRI/">https://www.w3.org/TR/SRI/</a>)? Can we use it<br>
      >>>     here?<br>
      >>>     4. What about using iframe from different domain
      (e.g. static data<br>
      >>>     host) as "jail" for such 3rd party code? We can
      make communication<br>
      >>>     between the host and this iframe with postMessage<br>
      >>><br>
      >>><br>
      >>>     В Пн, 11/04/2016 в 16:41 -1000, Jim Manico пишет:<br>
      >>>>     Hello folks,<br>
      >>>><br>
      >>>>     Jim Weiler from the OWASP Boston chapter just
      released a cheatsheet<br>
      >>>>     on 3rd party JavaScript management. I think
      this is a solid and very<br>
      >>>>     interesting piece of work. It address a
      security concern which many<br>
      >>>>     website operators face.<br>
      >>>><br>
      >>>>     Take a look, your feedback is - as always -
      appreciated.<br>
      >>>><br>
      >>>>    
      <a class="moz-txt-link-freetext" href="https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat">https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat</a><br>
      >>>>     _Sheet<br>
      >>>><br>
      >>>>     Aloha,<br>
      >>>>     Jim Manico<br>
      >>>><br>
      >>>><br>
      >>>>     
      _______________________________________________<br>
      >>>>     OWASP-Leaders mailing list<br>
      >>>>     <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      >>>><br>
      >>>>
<a class="moz-txt-link-rfc2396E" href="mailto:OWASP-Leaders@lists.owasp.org"><mailto:OWASP-Leaders@lists.owasp.org></a><a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailma">https://lists.owasp.org/mailma</a><br>
      >>>> n/listinfo/owasp-leaders<br>
      >>>><br>
      >>>><br>
      >>>>    
      _______________________________________________<br>
      >>>>     OWASP-Leaders mailing list<br>
      >>>>     <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      >>>><br>
      >>>>
<a class="moz-txt-link-rfc2396E" href="mailto:OWASP-Leaders@lists.owasp.org"><mailto:OWASP-Leaders@lists.owasp.org></a><a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailma">https://lists.owasp.org/mailma</a><br>
      >>>> n/listinfo/owasp-leaders<br>
      >>     _______________________________________________<br>
      >>     OWASP-Leaders mailing list<br>
      >>     <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:OWASP-Leaders@lists.owasp.org"><mailto:OWASP-Leaders@lists.owasp.org></a><br>
      >>    
      <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
      >><br>
      >> _______________________________________________
      OWASP-Leaders mailing<br>
      >> list <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      >> <a class="moz-txt-link-rfc2396E" href="mailto:OWASP-Leaders@lists.owasp.org"><mailto:OWASP-Leaders@lists.owasp.org></a><br>
      >> <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
      >><br>
      >><br>
      >> _______________________________________________<br>
      >> OWASP-Leaders mailing list<br>
      >> <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      >> <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
      >><br>
      > _______________________________________________<br>
      > OWASP-Leaders mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      > <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
      > 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.<br>
      > _______________________________________________<br>
      > OWASP-Leaders mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      > <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
      <br>
      _______________________________________________<br>
      OWASP-Leaders mailing list<br>
      <a class="moz-txt-link-abbreviated" href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
      <a class="moz-txt-link-freetext" href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
    </blockquote>
    <br>
  </body>
</html>