[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