Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] SaferScript (Rough draft)

Scott Arciszewski kobrasrealm at gmail.com
Sat Sep 28 17:28:19 PDT 2013


Hey LiberationTech,

I was going to try to polish this idea and develop it, but it's probably
better
off being developed by people with experience developing Firefox addons
and/or
who understand PKI in-and-out. Also, due to complications in my own life, I
do
not have the time or energy to invest in such an undertaking.

I've previously shared this with Micah Lee of the EFF and his friend
Garrett.

This is just a very rough draft. If anyone wants to take this up as a FOSS
project, feel free; I only ask that Taylor and I be mentioned somewhere in
the
credits.

################################################################################
  _____        __          _____           _       _
 / ____|      / _|        / ____|         (_)     | |
| (___   __ _| |_ ___ _ _| (___   ___ _ __ _ _ __ | |_
 \___ \ / _` |  _/ _ \ '__\___ \ / __| '__| | '_ \| __|
 ____) | (_| | ||  __/ |  ____) | (__| |  | | |_) | |_
|_____/ \__,_|_| \___|_| |_____/ \___|_|  |_| .__/ \__|
                                            | |
                                            |_|         (The name is
negotiable)
_______________________________________________________________________________
\
;
 \  Making Javascript Safer, Preventing XSS
Payloads                           ;
  \   @voodooKobra (Scott
Arciszewski)                                         ;
   \  Further suggestions by @DefuseSec (Taylor
Hornby)                        ;

\__________________________________________________________________________;

WHAT IS IT?
  An optional way to configure only digitally signed Javascript for websites
  set up to use it.

COMPONENTS
  o Browser plugin (Firefox at first, eventually Chrome & Opera?)
  o Netbeans plugin (for developers)
  o CLI Program (integrates with gnupg) for the server
  o Source file on the server
  o Publicly accessible whitelist file
  o Network of notaries which audit the signed whitelists to detect abuse

_____________________

 | The Browser Plugin
\______________________________________________________
 |
|
 | For security-conscious users, the SaferScript browser plugin would
request |
 | a whitelist of .js files (and their sha256 checksums), which should
be     |
 | signed by the developer's GPG private
key.                                 |
 |
|
 | (Note: In case SHA-256 is ever broken it needs to be able to support
other |
 | hash functions, such as the SHA-3 family, Whirlpool, and
RIPEMD.)          |
 |
|
 | If we do not know the public key, we will request it from the server
and   |
 | check with notaries that the user trusts that they see the same key.
If    |
 | the website has been queried before, the notary will also compare
the      |
 | public key it received with the one
archived.                              |
 |
|
 | The code will then verify the signature of the whitelist. If it
matches,   |
 | then each .js file will be downloaded and their checksums will be
verified |
 | before they are loaded into memory. If any of their checksums
doesn't      |
 | match, then that .js file is not loaded and the user is
notified.          |
 |
|
 | For public key verification, The browser will then send an SHA-256
digest  |
 | of the whitelist to a notary. If the notary does not have a record of
that |
 | whitelist, our network will request the whitelist and compare the
digest   |
 | with the one submitted by the user. If it doesn't match, the user
is       |
 | notified and they fail back to a copy that was signed and stored in
the    |
 | public
record.                                                             |
 |
|
 | If the signature matches but it is an updated version of the
Javascript    |
 | (and the notary has cached a copy of the same whitelist), the user will
be |
 | notified of the change and asked if they wish to examine the
differences   |
 | between the old version and the new version. (This can be turned off
for   |
 | non-tech-savvy users; all changes that any user experiences should
be      |
 | mirrored on the notaries, assuming they have opted
in.)                    |
 |
|
 | No other Javascript will load. Even inline function calls (onClick=""
etc) |
 | will have to be rewritten as $("#objectID").click( function() {
});        |
 |
|
 | If the GPG signature doesn't match, NO Javascript will load for the
entire |
 | domain until the developer updates the signed whitelist with new
checksums |
 | and an updated
signature.                                                  |
 |
|
 | Two further levels of paranoia will also be available: If a .css file
is   |
 | specified in the whitelist, no other stylesheet changes (outside of
those  |
 | made by trusted Javascript) will be registered. Additionally, if a
.png,   |
 | .jpg, .gif (etc) file is listed, all other images will be
blacklisted.     |
 | These paranoid modes are entirely optional and suited to
self-contained    |
 | apps rather than content portals that depend on user-generated
content.    |
 |
|
 | Notaries are selected when a user first installs the addon. Trust may
be   |
 | revoked by the user at any time should they change their
mind.             |
 |____________________________________________________________________________|


  __________________
 | The CLI Program
\_________________________________________________________
 |
|
 | For developers who prever to SSH directly into their production
system,    |
 | the CLI program would reconstruct (calculate sha256 checksums and GPG
sign |
 | the list) the whitelist
textfile.                                          |
 |
|
 | root at server~$: saferscript /root/whitelist.src
/var/www/white.list         |
 | Calculating SHA-256
checksums:                                             |
 |
/var/www/jquery.js:
|
 |
ea3b35ed94f9e600c29ca51d2ee1f6efb03d1389ea5455d2596ca32af1f6aadd
|
 |
/var/www/interface.js:
|
 |
f75062d19a9e56f0d002f9a93c909636e559ff16b0c8c712e84d207a434e66d8
|
 | Enter GnuPG Password to sign the new
whitelist:                            |
 | Your SaferScript whitelist is located at
/var/www/white.list               |
 | root at server~$:
_                                                           |
 |____________________________________________________________________________|


  _____________________
 | The Whitelist Files
\______________________________________________________
 |
|
 | There would be two files: One you edit that tells the CLI script which
.js |
 | files should be checksummed and included in the GPG-signed whitelist,
and  |
 | the latter file which should be served publicly (http://domain/white.list)
|
 |
|
 | Source File (typically
whitelist.src)                                      |
 | - Line 1 should contain the document root
folder                           |
 | - Lines 2-n should contain the relative path of each script to be
included |
 |
|
 | Public Whitelist (should be
/white.list)                                   |
 |
/jquery.js:sha256:ea3b35ed94f9e600c29ca51d2ee1f6efb03d1389ea5455d2596ca...
|
 |
/interface.js:sha256:f75062d19a9e56f0d002f9a93c909636e559ff16b0c8c712e8...
|
 | (Truncated here for the sake of
formatting)                                |
 | (Then, the PGP signature goes
below)                                       |
 |
|
 | As stated above, the source public whitelist can also contain image or
CSS |
 | files if the developer is truly
paranoid.                                  |
 |____________________________________________________________________________|


  ______________________
 | The Netbeans Plugin
\_____________________________________________________
 |
|
 | For convenience when updating a project on a remote server, without
having |
 | to login through SSH and run the saferscript CLI, a Netbeans plugin
would  |
 | be created that would run the command for you every time you update
your   |
 | Javascript
files.                                                          |
 |
|
 | The whitelist generation would take place entirely on the developer's
box, |
 | but an option to mirror your whitelist source file would be
available.     |
 |
|
 | (Netbeans was chosen because it's currently the best free and open
source  |
 | IDE for PHP projects on a remote
server.)                                  |
 |____________________________________________________________________________|


  ________________
 | Notary Network
\___________________________________________________________
 |
|
 | Inspired in part by the EFF's SSL Observatory and Moxie
Marlinspike's      |
 | Convergence, we would need to set up a robust network capable of
handling  |
 | three
tasks:                                                               |
 |  1. When a user passes a hostname:SHA hash of a server's whitelist,
the    |
 |     notaries will see if the hash already exists in its records. If
it     |
 |     doesn't, the notary requests the white.list, records it, and
also      |
 |     verifies that the copy it has on file is the same as the copy the
user |
 |     forwarded. This should prevent targeted
attacks.                       |
 |  2. When a user passes the hostname:SHA hash of a server's purported
GPG   |
 |     public key, the server will check to see if it's a known key for
that  |
 |     particular host. It will also request the key itself and make sure
it  |
 |     sees the same key, and store a publicly auditable
copy.                |
 |  3. It allows the general public to verify and audit the signed code
on    |
 |     websites that use this feature, by mirroring this data on a public
web |
 |     site on a different
network.                                           |
 |____________________________________________________________________________|


.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,
{                     PROCESS FLOW (PROGRAM
LOGIC)                             }
`^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^'
A request is sent to a webserver
Has the user already established the credibility of the code this session?
YES:
> Just load whatever settings were cached to minimize overhead
NO:
> Do we have a cached copy of the development team's GPG key?
>  YES:
>>    Continue.
>  NO:
>>   !Fallback feature so we can support Tor Hidden Services
>>   (Make it possible to disable this feature?)
>>   Does /dev.public exist?
>>   YES:
>>>    Fetch /dev.public, which should contain the public key
>>>    SHA2/3 hash the file
>>>    Pass it to the Notaries for GPG key verification
>>>    The notaries will let you know if that's a known public key on
>>>      file for that hostname. This is a weak authentication so...
>>>    Prompt the user whether or not they trust the public key
>>>    YES:
>>>>     Save the public key to cache for the hostname
>>>    NO:
>>>>     Disable Javascript, require user to confirm a security exemption
>>>>     if they wish to still visit the page.
>>   NO:
>>>    Abort; SaferScript is not deployed on this host
> Does /white.list exist?
> YES:
>>  GET /white.list
>>  Verify the GPG Signature with the developer's GPG Public Key
>>  Does it match?
>>  YES:
>>>   Download the .js files
>>>   FOR EACH JS FILE:
>>>>    Calculate the hash digest
>>>>    Does it match?
>>>>    YES:
>>>>>     Do we have a cached copy that's any different than the new one?
>>>>>     YES:
>>>>>>      Alert user to the changes, allow them to review the changes
between
>>>>>>      both versions and decide whether or not to use the new one or
the old
>>>>>>      copy of the file
>>>>>     NO:
>>>>>>      Proceed.
>>>>    NO:
>>>>>     Blacklist that file, make sure the user knows.
>>>   IF(SEND_TO_NOTARIES):
>>>>    SHA2/3 the white.list file
>>>>    Send to a trusted notary over TLS (respect proxy
>>>>      settings so it works with Tor, etc)
>>>>    Notary will request the white.list file and SHA2/3 hash it
>>>>    Does it match?
>>>>    YES:
>>>>>     Is it an old copy or a new copy?
>>>>>     NEW:
>>>>>>      Respond affirmatively, but let the user know it's a new copy
>>>>>     OLD:
>>>>>>      Respond affirmatively
>>>>    NO:
>>>>>     The user is being signled out with different copies of the
Javascript
>>>>>     Reply negatively, offer the user a nonce they can use to request
>>>>>       a trusted copy of the white.list if it's needed
>>  NO:
>>>   Danger, Will Robinson! Let the user know it failed.
>>>   Do we have a copy of trusted (signed) code?
>>>   YES:
>>>>    Use that instead, keeping the user notified that something is wrong.
>>>   NO:
>>>>    Disable Javascript, require user to confirm a security exemption
>>>>    if they wish to still visit the page.
> NO:
>>  Abort. If a GPG key was specified, disable Javascript and require the
user
>>  to confirm a security exemption if they wish to still visit the page.
It's
>>  fishy if they specify a key but have no white.list file.
And then everything else proceeds like normal.

MOTIVATIONS AND DESIGN GOALS
  o Provide a feature analogous to DEP for Javascript (mitigate XSS)
  o Provide a mechanism to deliver signed Javascript code
  o Needs to function even on HTTPS and Tor Hidden Services (no special
ports)
  o Needs to use existing cryptographic primitives (GPG, SHA2)
  o Needs to be released as free and open source software
  o All code changes need to be publicly auditable in case of attack
  o All code delivered must be neutral; you and I should see the same code
  o Users should have the option to reject "Updates" published by servers

ROADMAP
  o Build a browser plugin that only allows "trusted" Javascript
  o Build a GPG signature verification feature for selecting "trusted" code
  o Build the Command Line Interface tool (C, C++)
  o Build the Netbeans plugin
  o Write the documentation
  o Publish an alpha release
  o Get peer review, code audits
  o Possibly publish an Internet Standard?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130928/b1dee1c4/attachment.html>


More information about the liberationtech mailing list