Re: Updated script hash proposal (non spec text)

Mountie, the policy is delivered over https, so it can never be stronger
than the transport protections.
On Sep 20, 2013 8:12 PM, "Mountie Lee" <mountie@paygate.net> wrote:

> I have BIG interest for protecting javascript integrity.
>
> at WebCrypto WG, it was metioned out-of-scope
> at WebAppSec WG, it was touched but minor than nonce.
> at WebApp WG, I found your comment.
>
> many people said SSL/TLS is enough.
> but in view of OSI 7 layers, it only protect transport layer.
>
> I think we need a protection mechanism in application layer.
>
> script hash or signature are the possible solutions.
>
> can your suggestions be deliverable?
>
>
>
>
>
>
> On Sat, Sep 21, 2013 at 1:46 AM, Neil Matatall <neilm@twitter.com> wrote:
>
>> > 1. what to do after comparing hash?
>>
>> The policy used determines this, it will generate a warning and
>> optionally block depending on the presence of "-Report-Only" in the
>> header name.
>>
>> > 2. page encodings
>>
>> There has definitely been some discussion on this. ABarth explained
>> this one time but I _think_ the consensus that UTF-8 only was OK. All
>> valid javascript code characters fall within UTF-8 and non-UTF-8 data
>> can be read from elsewhere in the DOM/external scripts. I would
>> definitely appreciate extra eyes on this. It breaks some edge cases
>> (like script A modifying script B before B is done loading), but still
>> works in the common case.
>>
>> > 3. add tag attributes to hash source
>>
>> I don't think this gives us any benefit and increases the complexity
>> of the hashing significantly. There was talk of including the "type"
>> attribute, but I believe that was decided to be ignored. Type
>> "application/json" is ignored by CSP enforcement, VBScript/Ruby/Etc
>> are not covered by this.
>>
>> On Fri, Sep 20, 2013 at 12:21 AM, Mountie Lee <mountie@paygate.net>
>> wrote:
>> > questions and comments.
>> >
>> > 1. what to do after comparing hash?
>> >
>> > if browser calculate and compare the script hash,
>> > what to do next? block? warning? get user consent?
>> > dependent on browser vendor decision?
>> >
>> > 2. page encodings
>> >
>> > scripts are dependent on page encodings.
>> > many countries use non unicode encoding (GB2312, BIG5, EUC-KR, EUC-JP,
>> > Shift-JIS)
>> >
>> > is the non-unicode page encodings out of scope?
>> > can we use "charset" attribute in script tag?
>> >
>> > 3. add tag attributes to hash source
>> >
>> > in your example,
>> > <script>
>> >   alert(1);
>> > </script>
>> >
>> > "\n  alert(1);\n" is the hash source.
>> >
>> > if the tag has more attributes like
>> > <script language="javascript" charset="EUC-KR">
>> >  alert(1);
>> > </script>
>> >
>> > can we add tag attributes ("language...." part) to hash source?
>> >
>> >
>> >
>> > On Fri, Sep 20, 2013 at 7:46 AM, Neil Matatall <neilm@twitter.com>
>> wrote:
>> >>
>> >> Sorry for the long period of silence, I've been doing some
>> evangelizing.
>> >>
>> >> Script hashes will be another source expression. Per script hash, the
>> >> algorithm and digest length precede the actual hash value. e.g.:
>> >>
>> >> script-src 'sha256-0byNO6Svx+EJYSy3Osvd2sBSyTAlqh+ClC7au33rgqE'
>> >>
>> >> If a script hash source is specified and the user agent understands
>> >> it, the browser should ignore the 'unsafe-inline' directive for
>> >> backwards compatibility. Any inline script whose computed hash value
>> >> does not match a hash specified in the hash sources should not be
>> >> executed and an informative error message should be displayed
>> >> including the expected hash value.
>> >>
>> >> If multiple hashing algorithms are specified in the CSP header, the
>> >> browser must compute all possible hashes for each inline script block.
>> >> If the computed hash matches any computed hash in the header with a
>> >> matching algorithm+digest length, the script should execute. There was
>> >> talk of limiting this to one algorithm per header, but CDNs complicate
>> >> things.
>> >>
>> >> This is not meant to and should not support dynamic javascript. Hashes
>> >> should not be computed dynamically (at least not in production).
>> >>
>> >> === Computing hash values
>> >>
>> >> base64encode(<hashing algorithm>(UTF-8(<content of script tag>)))
>> >>
>> >> <script>
>> >>   alert(1);
>> >> </script>
>> >>
>> >> base64encode(sha256(UTF-8("\n  alert(1);\n")))
>> >>
>> >> === Script-hash unobtrusive workflow (PoC)
>> >>
>> >> Unfortunately, many online hashing services will strip
>> >> leading/trailing whitespace which is not what we want.
>> >>
>> >> I wrote a quick and dirty method for computing all script-hashes on a
>> >> page:
>> >>
>> >> $.each($('script'), function(index, x) {
>> >>
>> console.log(CryptoJS.SHA256(x.innerHTML).toString(CryptoJS.enc.Base64));
>> >> });
>> >>
>> >> Here's the equivilent openssl command:
>> >>
>> >> openssl dgst -sha256 -binary | base64
>> >>
>> >> I wrote a more thorough rails plugin and explained how it works in [1]
>> >> including a (low quality) video on how the developer workflow would
>> >> work: [2].
>> >>
>> >> Essentially:
>> >> 1) Find all inline scripts - search through the source code of any
>> >> file that could be rendered / displayed to a user.
>> >> 2) Extract the content of each inline script, hash according to the
>> algo
>> >> above.
>> >> 3) Store as Filename -> [hashes] mapping. In a configuration file, for
>> >> example.
>> >> 4) Any time a file is rendered, the corresponding hashes are added to
>> >> the CSP header.
>> >>
>> >> I believe this can be built in to every framework and be unobtrusive.
>> >>
>> >> [1]
>> http://nmatatal.blogspot.com/2013/09/how-my-script-hash-poc-works.html
>> >> [2] http://www.youtube.com/watch?v=Bc2hvziTRxg
>> >>
>> >> p.s. I support both script nonce and script hash, I think we need to
>> >> have both :-/
>> >>
>> >
>> >
>> >
>> > --
>> > Mountie Lee
>> >
>> > PayGate
>> > CTO, CISSP
>> > Tel : +82 2 2140 2700
>> > E-Mail : mountie@paygate.net
>> >
>> > =======================================
>> > PayGate Inc.
>> > THE STANDARD FOR ONLINE PAYMENT
>> > for Korea, Japan, China, and the World
>> >
>>
>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
>  =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>

Received on Sunday, 22 September 2013 17:39:54 UTC