| <!-- |
| * weinre is available under *either* the terms of the modified BSD license *or* the |
| * MIT License (2008). See http://opensource.org/licenses/alphabetical for full text. |
| * |
| * Copyright (c) 2010, 2011 IBM Corporation |
| --> |
| |
| <p>About security for <span class="weinre">weinre</span>: <b>there is none</b>. |
| |
| <p>Obviously there should be some. The question is, what do we need to do? |
| |
| <!-- ======================================================== --> |
| <h2>Background and potential exposures</h2> |
| |
| <p>Currently <span class="weinre">weinre</span> uses plain old HTTP - not HTTPS - and provides |
| no level of authentication for requests. |
| |
| <p>The primary security exposure with <span class="weinre">weinre</span> is via |
| the debug server. |
| |
| <p>Currently, the server only reads files from the <tt>weinre.jar</tt> file, |
| and from the <tt>~/.weinre/</tt> directory (for property files). |
| The only thing the server writes to is <tt>stdout</tt> and <tt>stderr</tt>. |
| |
| <p>If you use the default <tt>--boundHost</tt> option value of |
| <tt>localhost</tt>, then any software on the machine running the debug |
| server can communicate with the debug server. This probably isn't a big |
| deal, since presumably you control the software running on that machine. |
| |
| <p>If you use a non-default <tt>--boundHost</tt> option value, |
| then <b>any software on any machine that can access that specified |
| host can communicate with the debug server</b>. This is a much bigger |
| deal. |
| |
| <p>The most obvious exposure with using <tt>--boundHost</tt> and |
| a specific hostname / ip address, is that any debug client or |
| debug target that can access that hostname / ip address can access |
| the server. For example, a rogue debug client could connect to |
| your debug target and fiddle about with it. |
| |
| <p>Other exposures include leaving a debug target injection |
| script line (ie, <tt><script src="[...]/target/target-script.js"></tt>) |
| in your web page, and then that web page connects to a rogue debug |
| server running at that address. |
| |
| <!-- ======================================================== --> |
| <h2>Future Implementation Ideas</h2> |
| |
| <ul class="spaced"> |
| |
| |
| <li><b>use HTTPS with basic auth</b> |
| |
| <p>This shouldn't be a big problem with the debug client, but may be a pain in the ass |
| since basic auth can be a pain in the ass (trying to log out of it). |
| |
| <p>On the debug target side, this is tougher, since the only HTTP access is done via |
| XHR. So, presumably, we will need to tack on the userid/password to XHR requests, |
| unless the browsers do that for us. That is, I assume the browsers don't throw up |
| a password prompt when an XHR returns with an auth-required response code. |
| |
| <p>Storing userid/passwords on the client isn't going to be much fun. How do we even |
| get these from the user? |
| |
| <p>Note that there is also a 'server discovery' issue we may want to do something |
| about. That is, how does the debug target even know the URL of the server? |
| If we want to allow the user to "enter it from the target", then entering the |
| userid/password can fit into the same scheme, I guess. |
| |
| <p>Will need some light-weight userid/password store for the server, if |
| we do this. |
| |
| <p>Will need to get the horrifying SSL keystore dance crap with Java |
| in some kind of usable state. Should we ship a working, basic self-signed keystore |
| that we recommend user's replace? |
| |
| <li><b>use HTTPS with OAuth</b> |
| |
| <p>Been a while, not sure if OAuth even helps with this, |
| or how hard it would be to integrate support for it. |
| |
| <p>Same issue with HTTPS and the SSL keystore above. |
| |
| <li><b>other ideas?</b> |
| |
| </ul> |