weinre - Security

About security for weinre: there is none.

Obviously there should be some. The question is, what do we need to do?

Background and potential exposures

Currently weinre uses plain old HTTP - not HTTPS - and provides no level of authentication for requests.

The primary security exposure with weinre is via the debug server.

Currently, the server only reads files from the weinre.jar file, and from the ~/.weinre/ directory (for property files). The only thing the server writes to is stdout and stderr.

If you use the default --boundHost option value of localhost, 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.

If you use a non-default --boundHost option value, then any software on any machine that can access that specified host can communicate with the debug server. This is a much bigger deal.

The most obvious exposure with using --boundHost 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.

Other exposures include leaving a debug target injection script line (ie, <script src="[...]/target/target-script.js">) in your web page, and then that web page connects to a rogue debug server running at that address.

Future Implementation Ideas

• use HTTPS with basic auth

  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).

  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.

  Storing userid/passwords on the client isn't going to be much fun. How do we even get these from the user?

  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.

  Will need some light-weight userid/password store for the server, if we do this.

  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?

• use HTTPS with OAuth

  Been a while, not sure if OAuth even helps with this, or how hard it would be to integrate support for it.

  Same issue with HTTPS and the SSL keystore above.

• other ideas?