- From: Brad Hill <hillbrad@gmail.com>
- Date: Sun, 22 Sep 2013 11:39:25 -0600
- To: Mountie Lee <mountie@paygate.net>
- Cc: public-webappsec@w3.org, Neil Matatall <neilm@twitter.com>
- Message-ID: <CAEeYn8hWBeF9hNvss0Yn4j0dQ5JU8Ph18ESMOfuckQ_t2A6ZEA@mail.gmail.com>
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