- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Mon, 23 Sep 2013 10:17:35 +0200
- To: Mountie Lee <mountie@paygate.net>
- CC: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Neil Matatall <neilm@twitter.com>
- Message-ID: <523FF91F.10808@gmail.com>
Script hashes or nonces can only complicate a little bit the action of
the attacker, it's easy for the mitm to get rid of it.
If SSL/TLS is not enough, one way could be to have a secret known by the
user and the server that is never sent over the network, the secret is
used to deliver js and verify its integrity (encrypt/decrypt, add
information in the page about js content, hash, etc)
For CSP, as far as I understood nonces are not very easy to implement
for some CDNs, so there is the hash solution, which does not protect
better and can be more complicate to implement for standard sites, so I
would keep both.
Regards
Aymeric
Le 23/09/2013 06:58, Mountie Lee a écrit :
> 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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <tel:%2B82%202%202140%202700>
> > E-Mail : mountie@paygate.net
> <mailto: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 <tel:%2B82%202%202140%202700>
> E-Mail : mountie@paygate.net <mailto: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 <tel:%2B82%202%202140%202700>
> E-Mail : mountie@paygate.net <mailto: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 <mailto:mountie@paygate.net>
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>
>
>
>
--
jCore
Email : avitte@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web : www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Monday, 23 September 2013 08:18:31 UTC