Open jake-b opened 7 years ago
I was considering another solution to the same problem: hard-coding the host-part of the update URL. Looks easy to implement: just one more #define and one concatenation when ESPhttpUpdate.update() is invoked. This way otaUrl will contain only the path, without prococol://host/. In case the #defined prefix is empty (by default), the current configurations will work without modifications.
Another possible solution: password-protected "safe mode". When in "safe mode", all the configuration changes will be disabled, including firmware upgrade, but also wifi and mqtt credentials, etc. Something like the current WebServer 1 but without an easy way to turn it back to admin-mode. You can even use sysCfg.webserver marking the "safe mode" active (for example: sysCfg.webserver == 3).
In order to make it easier, you may use the wifi password as a a "safe-mode off" password. I.e. cmnd/sonoff/safemodeon will turn safe mode on (webserver 3) and cmnd/sonoff/safemodeoff wifipass will turn safe mode off (webserver 2). Later, when you have some time, you may introduce another config variables for storing the safe mode status and password.
Without firmware security, if someone is able to compromise the mqtt server (or one of it's clients, for example a domoticz instance or even another sonoff), he/she will be able to hijack all your devices and use them for malicious purposes. It will be very easy to start a DDoS attack even without replacing the firmware: just set webserver to 0 and change MqttHost:MqttPort to victim.com:80. The device will start sending connect requests to the victim's web server and (as a "free bonus") it will disconnect from your mqtt server, thus making it quite difficult for you to regain the control (you will have to physically reset the devices one by one).
I heard a really great quote today. The 'S' in "IOT" is for security... as in there is no S for security in IOT. https://twit.tv/shows/security-now/episodes/593?autostart=false I'd like to see improved security, but I'm so new to this project, that I'm not sure how I want it.
Feature request: Password security for firmware update via MQTT or HTTP.
Not that I think there's a huge risk, but IoT security in general is pretty lax, and it wouldn't be a bad idea to take minor security measures.
If a password is configured, then instead of cmnd/upload command taking "1" as trigger, have it take a password. If the password is correct, then start the update. Could even default the password to "1" to maintain existing functionality.
A little harder for the HTTP update, involving an added text field to collect the password.
Just an idea, take it or leave it. Thanks for a nice, feature rich firmware for these devices.