Bride-API design implicates security problems

Nuki APIs Bridge HTTP-API
1

The action calls can be performed like

curl -X GET 'http://Nuki-Bridge-FOO:8080/lockAction?action=1&token=BAR&nukiId=BAZ'

In particular using the GET method is a violation of the HTTP specs. In short: “GET” may not have side effects. Unlocking a door is like the mother of all side effects.

This is not just a theoretical argument. Here is one example: somebody writes down the URL http://Nuki-Bridge-FOO:8080/lockAction?action=1&token=BAR&nukiId=BAZ in a wiki in the local network. In the simple case some other user just clicks it by accident and unintentionally unlocks the door. Worse: the wiki might be a fancy one. In a background process it calls the in the wiki entered URLs to provide enrichments. It might do this even periodically, or at some unexpected time in the future (after a software update for example). Every time it calls this URL the door will then unlock!

There are other applications which behave likewise (chat apps, …). They all perform reasonably because GETing an URL may not have side effects.

Please deprecate GET on this URL and switch to POST soon.

In the long run you might want to redesign your API in more depth. I am aware that devices like the bridge come with (hardware) constraints. But there are a few other bad practices currently implemented in the API. One of them makes the stated problem from above as bad as it is.

Best wishes, Tom

2

While I totally see all the points in your arguments I just wanted to add an important information for readers of this:

We covered parts of this issue with our hashed token, which we highly recommend using:

https://developer.nuki.io/page/nuki-bridge-http-api-190/4/#heading--token

By adding the timestamp to the hash-calculation a HTTP-request can not be easily reused.

And as you correctly stated we will have to take a look at the hardware constraints for further improvements on this.

1 Like
3

I agree that hased tokens help. You might emphasis them more in the documentation and strongly discourage unhashed tokes; probably even deprecate them.

A also agree that it would be bad practice to note the URL anywhere. But the problem doesn’t go away with this (yet alone for the reason that people just do that stuff anyways). What I gave was just one example. There are endless possibilities where in particular plain URLs can be stored (transparent proxies, logs, …). In the end it all boils down to the the GET. You can try to work around that but you can never be sure if you have anticipated every problem that comes with it.

Tom

2 Likes
4

When will this be added to the software bridge application? It’s a sad thing that I am constantly sending the plain API token over my wifi via a non ssl-encrypted connection.