Revision: 6469 Author: tamplinjohn Date: Mon Oct 26 14:11:20 2009 Log: Edited wiki page through web user interface. http://code.google.com/p/google-web-toolkit/source/detail?r=6469
Modified: /wiki/DesignOOPHM.wiki ======================================= --- /wiki/DesignOOPHM.wiki Tue May 26 06:32:14 2009 +++ /wiki/DesignOOPHM.wiki Mon Oct 26 14:11:20 2009 @@ -1,4 +1,5 @@ #summary Design: Out of Process Hosted Mode (OOPHM) +#labels Phase-Design = Design: Out of Process Hosted Mode (OOPHM) = @@ -13,7 +14,7 @@ * We can't use hosted mode across platforms (for example, using IE from a Linux hosted mode across the network). Fixing a late bug on IE often requires setting up an IDE and importing the entire project. == Goals == - * Support use of multiple browsers on each supported platform: Linux: Firefox 1.5+. Windows: Firefox 1.5+, IE6/7 and Safari3. OS X: Firefox 1.5+ and any !WebKit browser. + * Support use of multiple browsers on each supported platform: Linux: Firefox 1.5+. Windows: Chrome, Firefox 3+, IE6/7/8 and Safari3+. OS X: Firefox 1.5+ and any !WebKit browser. * Enable the use of standard and current browser plugins, tools and capabilities (Firebug, DOM Inspector, Gears). * Avoid version dependencies in supported browsers or system-supplied libraries (and minimize it where it is absolutely not possible). * Provide user-visible performance no worse than the current implementation. @@ -42,7 +43,7 @@ http://google-web-toolkit.googlecode.com/svn/wiki/DesignOOPHM-arch.png === User Interface === - The following is an *incomplete* sketch of the new UI for hosted mode. The mocks will be updated again soon, but this illustrates the primary motivation for updating the UI. The possibility of having multiple browsers running modules in the same hosted mode server requires more visibility and separation of the different clients and their associated reporting. Another component that is not represented currently is the embedded Tomcat instance. That will be fixed in the next mock. + The following is an *incomplete* sketch of the new UI for hosted mode. The mocks will be updated again soon, but this illustrates the primary motivation for updating the UI. The possibility of having multiple browsers running modules in the same hosted mode server requires more visibility and separation of the different clients and their associated reporting. Another component that is not represented currently is the embedded Tomcat instance. That will be fixed in the next mock. _(Note: this mock is rather out-of-date at this point). @@ -161,22 +162,21 @@ Opera - Unsupported (NPAPI/npruntime when we confirm that they have finally implemented it fully) - Chrome - Currently unsupported, but NPAPI will be used + Chrome - Preliminary support via CRX with NPAPI plugin === Hosted GWT module space === The infrastructure in place in the current version of hosted mode has remained largely intact. At a very high level, this new model for hosted mode replaces the implementation of the !JavaScriptHost interface (which provides an interface directly to the corresponding !JavaScript environment) with the !BrowserChannel construct that is described above. We are intentionally avoiding a massive restructuring of the hosted space infrastructure at this point. - === Security Considerations === - At this point, we present the security considerations without explicitly identifying solutions. We will update this again soon to propose solutions. - - The biggest threat vector comes from the fact that the hosted mode functionality is a general purpose plugin that is instantiable in the browser you use daily by any site. A couple of other issues that come into play here are, (1) using the hosted server UI to validate a user's intent to debug is problematic since that would require the plugin to open a socket to a potentially private address (2) NPAPI and other page based plugins do not have a reliable way to interact with the browser chrome to present dialogs to the user. - -== Development Plan == -OOPHM is planned to go into GWT 2.0, which should be 3Q09. The current state (as of October 2008) is the Swing-based UI is fully functional and all supported browsers/platforms pass all tests. There are still a few rough edges in the support, but it is perfectly functional. - -Areas to improve: - * Testing opens a new browser, which can be annoying on Windows/Mac (on Linux it is easy enough to run Selenium-RC inside an Xvfb instance). - * hosted.html currently generates missing plugin warnings on Firefox - * User access controls to address the security issue above - * The UI is currently a quick-and-dirty solution with the bare minimum functionality. - * The plugin code needs to be refactored to extract more common code. += Security Considerations = + +== Primary Threats == + * The plugin is available to arbitrary and potentially malicious JS code. If not protected, this could lead to buffer overrun and similar attacks. + * The plugin opens a network connection to an address supplied by JS code. This could be used to subvert a firewall for example. It is clear the plugin could be used to do at least a port scan behind a firewall, and it may be possible to do more. + * The plugin connects to a GWT server, which could be under hostile control. Lack of care in processing this connection could result in buffer overrun and similar attacks. + +== Threat Mitigation == + * All data passed from JS to the plugin must be fully validated. We do not assume any subversion of the host browser, as in that case the presence of our plugin does not increase the exposure. + * The plugin maintains a whitelist (location varies by browser) listing the hosts which are allowed to open an OOPHM network connection, initially containing only localhost and 127.0.01. Any URL whose serving host is not in the whitelist will result in a dialog box asking the user to permit the connection (with the option of remembering this decision for future connections). If the URL is blacklisted or the user does not give consent, the connection attempt fails. + * The normal use case is for a developer debugging their own GWT apps, usually on the same machine but sometimes with other nearby machines, so it should be surprising for a developer to browse a site not under their control and see a dialog about the connection attempt. + * Note that this consent is essentially at the host level, so if a user trusts a host they are trusting all the web pages served from that host. + * Rogue GWT servers should not be an issue due to the whitelist approach described above, but we still make sure not to overflow any buffers due to malformed network messages. We do not attempt to avoid denial of service attacks, such as exhausting all memory to hold a long string, etc. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
