Re: Updated script hash proposal (non spec text)

I found some approaches to get JS integrity verification like
Caja, FBJS or ADSafe projects.

the script hash in CSP can be replacement of those projects?

legal regulations need protection of application level (actually between
browser sandbox and JVM memory of web application server)



On Mon, Sep 23, 2013 at 12:15 PM, Brad Hill <hillbrad@gmail.com> wrote:

> That seems to be legal regulations, if the automated translation is
> correct.
>
> What I meant is that it is technically impossible for CSP to be stronger
> than TLS.  CSP is delivered over TLS, so if TLS "not enough" to stop your
> threat, they can just change the hashes or remove the header or meta tag
> entirely.
>  please share the link about the policy.
>
> is this link correct?
>
> http://law.fss.or.kr/fss/lmx/law_common/law_body.jsp?law_code=A00571372296760048&seqno=295311
>
> regards
> mountie
>
>
> On Mon, Sep 23, 2013 at 2:39 AM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> 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
>>>
>>>
>>>
>
>
> --
> 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