Information leakage: X-Watchman-Version

[mwarkentin]

As raised by @blag in #35:

if an attacker can get the version of watchman, they can limit their known range of versions of Django (eg: version x.y.z of watchman only supports version a.b.c through d.e.f of Django). Given this information, an attacker can refine their attack strategy, allowing them to attempt fewer exploits than they would otherwise. That, in turn, makes it easier to evade IDS systems.

Basically: version information disclosure to malicious parties violates defense-in-depth guidelines.

Now, this is only an issue when either of the following is true:

there is no authentication done on the status or dashboard endpoints
a malicious party has access to the status or dashboard endpoints
The first is unlikely yet possible with PR #30 if the authentication/authorization decorator is flawed, and the second is a misplaced trust issue to being with.

Given all of that, this isn't a huge deal, I just want to recognize that this PR creates a small, mild defense-in-depth violation for essentially what are misconfigured systems already. Making a note about this issue in the documentation for watchman might be a good idea to help users avoid this potential pitfall. But I think "secure by default" should be the accepted practice, so I would also suggest turning off this feature by default, and letting users turn it on if they wish.

[mwarkentin]

Basically, this feature came up as a result of managing about 10 or so systems, and those systems running 3 different versions of watchman - there were some questions about the names of the checks to use in the GET query params, which had changed between 0.4.0 and 0.5.0. It was pretty annoying to figure out which version of watchman was running where - basically came down to a github search, or ssh-ing into 10 different boxes to check.

I figured this was something safe to enable as watchman is a read-only service, and I figured most people would've used the token auth to restrict access.

[mwarkentin]

Also, I've verified that this header is not set when you attempt to hit the endpoint without authentication:

(cde-provisioning)[vagrant@vagrant templates]$ curl https://my.wave-local.com/watchman/ -D -
HTTP/1.1 403 FORBIDDEN
Server: nginx/1.0.15
Date: Thu, 02 Jul 2015 23:44:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding

(cde-provisioning)[vagrant@vagrant templates]$ curl https://my.wave-local.com/watchman/?watchman-token=foo -D -
HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Thu, 02 Jul 2015 23:44:40 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Watchman-Version: 0.6.0

{"databases": [{"default": {"ok": true}}], "storage": {"ok": true}, "caches": [{"default": {"ok": true}}]}

[blag]

Awesome! Since that's a potential security issue, I think that is an excellent candidate for a test. 😜

[mwarkentin]

@blag this definitely sat a lot longer than I expected, but I've just merged #63 which disables it by default. Not sure if you're still using watchman, but if you are, it should be out in 0.15 sometime soon.

[blag]

Yep, I am still using it, thanks for the update!

[mwarkentin]

Awesome, good to hear! Feel free to open an issue if you have any other suggestions!