Security.html - cordova-weinre - Git at Google

 <!doctype html>

 <!--
  * 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
 -->

 <html>
 <head>
 <title>weinre - Security</title>
 <link rel="stylesheet" href="css/main.css" type="text/css">
 <link rel="shortcut icon" href="images/weinre-icon-64x64.png" />
 <script src="scripts/main.js"></script>
 <script type="text/javascript">

   var _gaq = _gaq || [];
   _gaq.push(['_setAccount', 'UA-736164-7']);
   _gaq.push(['_trackPageview']);

   (function() {
     var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
     ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
     var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
   })();

 </script>
 </head>

 <body>

 <a class="no-decoration" href="https://github.com/phonegap/weinre"><div class="ribbon">Fork weinre on GitHub</div></a>

 <!-- ======================================================================= -->
 <h1 class="page-title">weinre - Security</h1>

 <div class="toc">
   <a href="Home.html">Home</a>
 - <a href="TestDrive.html">Test Drive</a>
 - <a href="Installing.html">Installing</a>
 - <a href="Running.html">Running</a>
 - <a href="MultiUser.html">Multi-User</a>
 - <a href="Security.html">Security</a>
 - <a href="Building.html">Building</a>
 - <a href="ChangeLog.html">ChangeLog</a>
 - <a href="License.html">License</a>
 <p>
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 </div>

 <!--
  * 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>&lt;script src="[...]/target/target-script.js"&gt;</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>


 <!--
  * 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
 -->

 <div class="toc">
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 <p>
   <a href="Home.html">Home</a>
 - <a href="TestDrive.html">Test Drive</a>
 - <a href="Installing.html">Installing</a>
 - <a href="Running.html">Running</a>
 - <a href="MultiUser.html">Multi-User</a>
 - <a href="Security.html">Security</a>
 - <a href="Building.html">Building</a>
 - <a href="ChangeLog.html">ChangeLog</a>
 - <a href="License.html">License</a>

 <br><img src="images/weinre-icon-128x128.png">
 </div>

 </body>
 </html>
	<!doctype html>

	<!--
	* 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
	-->

	<html>
	<head>
	<title>weinre - Security</title>
	<link rel="stylesheet" href="css/main.css" type="text/css">
	<link rel="shortcut icon" href="images/weinre-icon-64x64.png" />
	<script src="scripts/main.js"></script>
	<script type="text/javascript">

	var _gaq = _gaq \|\| [];
	_gaq.push(['_setAccount', 'UA-736164-7']);
	_gaq.push(['_trackPageview']);

	(function() {
	var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
	ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
	var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
	})();

	</script>
	</head>

	<body>

	<a class="no-decoration" href="https://github.com/phonegap/weinre"><div class="ribbon">Fork weinre on GitHub</div></a>

	<!-- ======================================================================= -->
	<h1 class="page-title">weinre - Security</h1>

	<div class="toc">
	<a href="Home.html">Home</a>
	- <a href="TestDrive.html">Test Drive</a>
	- <a href="Installing.html">Installing</a>
	- <a href="Running.html">Running</a>
	- <a href="MultiUser.html">Multi-User</a>
	- <a href="Security.html">Security</a>
	- <a href="Building.html">Building</a>
	- <a href="ChangeLog.html">ChangeLog</a>
	- <a href="License.html">License</a>
	<p>
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	</div>

	<!--
	* 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>


	<!--
	* 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
	-->

	<div class="toc">
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	<p>
	<a href="Home.html">Home</a>
	- <a href="TestDrive.html">Test Drive</a>
	- <a href="Installing.html">Installing</a>
	- <a href="Running.html">Running</a>
	- <a href="MultiUser.html">Multi-User</a>
	- <a href="Security.html">Security</a>
	- <a href="Building.html">Building</a>
	- <a href="ChangeLog.html">ChangeLog</a>
	- <a href="License.html">License</a>

	<br><img src="images/weinre-icon-128x128.png">
	</div>

	</body>
	</html>