On Thu, Oct 1, 2015, at 07:45 AM, Travis Biehn wrote:
So, one of the difficulties w/ web-apps is that the 'code' is dynamic. You cannot implement a secure system if your attacker can change the code at any point in time. As is the threat model with backends, which attest to their 'trust me' security (a la lavabit, hushmail and so on) - so is the problem with client side code. If you build a web-app which does in-browser encryption and never sends the encryption key to the backend your attacker can simply modify the static JS source, DOM inject and XSS their way to your sweet sweet encrypted keys. Even if you audit your code at one point in time, you aren't certain it doesn't change with every request to the server.
SO
The first hurdle here is allowing users to reason about 'versions of web-app client assets' - if any part of the 'web-app client' relies on dynamic / non static JS, the application cannot effectively be 'versioned' (unless those sub-components are similarly versionable). A subset of HTML and JS is defined (safe javascript language subsets are a fail) AND the JS VM is modified to 'lock in' its object defns after loading.
So, then you can take the set of client side assets (html, js, images so on) hash each, add some version metadata and sign it. Version 1.
Front page of HN: https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/ Alfie -- Alfie John alfiej@fastmail.fm