3. party software, including JavaScript software, can "phone home" (passwords, private data, etc.). Given the cost of software development, it is practically impossible to avoid using 3. party JavaScript libraries. An example of a JavaScript based, NSA related, security breach has been described at
http://www.democracynow.org/2014/2/28/peeping_webcam_with_nsa_help_british
JavaScript formal verification tools do not yet exist and even, if they did, it would probably be unaffordably laborious to write/review the set of requirements of all of the 3. party libraries and their dependencies.
API Proposal
One possible solution is to place JavaScript software to a semi-jail that has AJAX and other forms of IP-layer access only to a specified set of URL's. If web browsers supported the following function:
Code: Select all
webbrowserspecific_api.v_niceversion.blow_all_bridges_except(array_of_allowed_URL_prefixes);then the only way for the malicious software to "phone home" is by having the server side to redirect the call to "home".
Most of the communication of the 3. party libraries can be jailed, handled, by using the following architecture:
X) The whole application, from log-in to log-out, runs at a single "html-page" that
is served by the index.php.
X) After the index.php has served the initial HTML and JavaScript, the
window.onload() executes the blow_all_bridges_except(...) and all of the
communication between the web browser and the server can only take place
either by using
XX) demultiplexer_as_a_single_entry_for_all_application_specific_AJAX_requests.php
XX) a folder, JS_and_CSS_folder, that contains all of the JavaScript and CSS files
that this web application uses, including all 3. party JavaScript and CSS libraries.
To make sure that the "call to home" can only take place through the
demultiplexer....php
the JS_and_CSS_folder contains .htaccess file that tells the web server to make sure that no files in the JS_and_CSS folder (read: server-side files of the 3. party libraries) is executed at the server side. To make this work, the web application specific demultiplexer....php has all of the web application specific PHP file loading commands and function calls hard coded in itself, e.g. 3. party JavaScript can not use the demultiplexer....php as an "eval" function that loads a file from the JS_and_CSS_folder and executes it.
It's also important that the server side versions of the 3. party libraries can neither modify each other, nor modify the web application specific code, including the demultiplexer....php. The aforementioned measures impose the desired limit.
This feature request has emerged from a discussion that I initiated at the Yahoo YUI forum,
https://groups.google.com/forum/#!category-topic/yui-support/everything-else/kZZA6lDaODw
Thank You for reading this comment.
