Weinre security

[Dissidente]

Hi all.

We're trying to implement some sort of security to weinre, in a manner that if a given guid isn't passed on each request the server just won't serve the request.

Our developer is having a hard time understanding where in the code he can implement this verification. Do you have suggestions?

(Patrick, is any sort of security planned in the roadmap? What we are trying to acomplish here is just deny "anonymous" (assessment) requests to the service).

Thanks in advance

[Patrick Mueller]

On Tue, May 15, 2012 at 7:48 AM, Dissidente <dissi...@gmail.com> wrote:

We're trying to implement some sort of security to weinre, in a manner that if a given guid isn't passed on each request the server just won't serve the request.

We have a multi-user token story already, see [1].  It's not "secure" in any fashion.  I'm open for other ideas, but would like to see a proposal for how it would work, before someone ventures into it.

 

Our developer is having a hard time understanding where in the code he can implement this verification. Do you have suggestions?

The main server code is in weinre.coffee [2].  And surrounding modules. 

 

(Patrick, is any sort of security planned in the roadmap? What we are trying to acomplish here is just deny "anonymous" (assessment) requests to the service).

Frankly, I've been rather surprised that there hasn't been more interest in security, authentication, etc.  There are a handful of folks running public access weinre servers - I guess they don't feel like the additional load of the public is too great a burden, today.

So, no, no additional security planned in the roadmap, right now.

[1] http://people.apache.org/~pmuellr/weinre/docs/latest/MultiUser.html

[2] https://github.com/apache/incubator-cordova-weinre/blob/master/weinre.server/lib/weinre.coffee

--
Patrick Mueller
http://muellerware.org

[Dissidente]

Multi-user token works fine, and is indeed useful when debugging different projects at the same time (for teams). That's the way we are currently working.

The security issues I find more relevant are focused in internal networks, but they can be even more relevant towards a public server (honestly I find that a public server is just too much of a risk):

* Privilege escalation

Usually people run weinre on a developer-device perspective, and on a on-ocasion period, so it doesn't stay running at all times. Thus usually people don't mind running weinre as a privileged user. However on our particular case we are running weinre as a Windows service, because our developers need to use it whenever they need. In this case (and in on-ocasion) it's important to run the server with an unpriviliged and limited account. It's not putting little faith in weinre or nodejs, but as a sysadmin I need to be a security freak (and I enjoy it =P). If a vulnerability is found in either weinre or nodejs that allows, for example, to run code in the security context of the user running the server, you'll want to make it harder and give that user the least amount of privileges needed to acomplish it's purpose (basically run nodejs server and weinre).

* Service assessment

We all like to consider our networks safe... however they might be safe until such a point. If you consider that you have an insecure computer in your network (an infected machine, or just a rogue access point some dumb employee has connected to your network) you'll wan't to defend weinre (and thus your server) from malicious assessments, like "oh, what's this service here?". In this point what we were thinking of implementing as a very rudimentary way of defense was using the boundHost feature to filter the requests that didn't use the correct address (which Patrick already told me doesn't work that way) in conjunction with passing an unique argument common to each request (like a guid as a query string). This unique argument would be defined in the script tag in the page pointing to weinre and would be passed by the client also. This would also prevent a "casual" browse of the main page, and ensure that you needed the unique argument to receive any output of the server (I would no longer just browse the service and "oooohhh, it's weinre... =P". Sure, just sniffing traffic you could easily defeat such a mechanism, but this is intended to be a basic way of protection. 

A proper mechanism might pass by some sort of registering the page to be debugged (sorry, I don't know the project's terminology) with the server, having the server check if the referrer is known or not. From the client (developer) side I think plain old authentication might be enough (possibly in conjunction with https support).

[Patrick Mueller]

On Tue, May 15, 2012 at 10:59 AM, Dissidente <dissi...@gmail.com> wrote:

Multi-user token works fine, and is indeed useful when debugging different projects at the same time (for teams). That's the way we are currently working.

The security issues I find more relevant are focused in internal networks, but they can be even more relevant towards a public server (honestly I find that a public server is just too much of a risk):

* Privilege escalation

When you run weinre, the only files/file handles it should be touching are stdout, stderr, and potentially reading a default configuration file.  So you should be able to run weinre easily with a user with very limited access to things.  Of course, who knows, maybe something is inadvertently exposed; and of course I'll attempt to lock these down if found.  Of course, it also has a socket open for accepts, etc.

For this, or for other related issues with the server process, please create a feature request a bug [1].

 

* Service assessment

...

Totally open to doing more here, as you suggest, or even just making easier for folks to do this kind of stuff themselves.  Again, file a feature request.

[1] https://issues.apache.org/jira/secure/CreateIssueDetails!init.jspa?pid=12312420&components=12316604&priority=3&issuetype=2