blob: ab73f49cc33fc31564d3a1d864ef3d13046e1408 [file] [log] [blame]
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
<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 weinre-node distribution,
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
<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>Let's chat