Jump to content

Need REST interface data security


larryllix

Recommended Posts

About twice per year I find data errors operating the wrong devices. I have suspected this has happened many times before, using the REST interface where network comm errors have operated random devices or programs on my ISY system.

Last night I asked …
     Alexa. Turn on the deck lights

Alexa replied "OK" and rang my doorbell. I doubt the vocals sounded anything alike, and conclude this is not a vocal recognition problem or ISY Portal problem.
My doorbell would take...
      Alexa. Turn on the doorbell

This is an occasional occurrence, where some external input operates the wrong program or variable, by what seems to be an Ethernet data comm error. External data inputs to ISY don't seem to require any data integrity security, and really need some, perhaps in the form of checksum or other  technique. In other cases this could result in more serious errors operating the wrong devices, programs or scenes.

This may mean not supporting the existing, poorly security REST interface, but needs to be corrected for serious HA. Even pre-enrollment of device using absolute specification or limit fences could help somewhat.

Link to comment
13 hours ago, Michel Kohanim said:
@larryllix,
Have you looked at the history in SmartHome skill to see what Alexa actually heard?
With kind regards,
Michel


Just looked. No records show anything with the ISY Portal interactions.

Tested again using the web app, and the mobile app. ISY operations do not show up. The app always shows activity by replacing the prompt wording but nothing for ISY ever shows up. The Smart Home skill page shows no activity either.

These random operations have been doing this about twice per year with other external inputs also. It seems ISY doesn't have any security to stop any external device from clobbering it by writing to the wrong place.
 

Link to comment

Personally, I process REST through a proxy  (Think Nginx/A10/F5/etc).

The proxy does fast/secure HTTPS, logs each command (source IP, timestamp, and full REST request string), and can explicitly restrict which user/IP can request which REST endpoint -- for example, IP cameras can only do RunIf.

On 5/2/2019 at 9:35 AM, larryllix said:

This is an occasional occurrence, where some external input operates the wrong program or variable, by what seems to be an Ethernet data comm error. External data inputs to ISY don't seem to require any data integrity security, and really need some, perhaps in the form of checksum or other  technique. In other cases this could result in more serious errors operating the wrong devices, programs or scenes.

All Ethernet packets have a checksum, and SSL/TLS adds another layer of checksums on top.   Assuming you are using encryption (HTTPS), it is basically impossible for an Ethernet or network stack error to result in a REST command that is well-formed enough to be accepted, but with a small enough error (in just one or two bytes at most) such that the wrong program, device, or scene is referenced successfully.

In the case of Alexa, I find it much more likely that the issue is with a backend database or elsewhere in software, not in the network.

On 5/2/2019 at 2:03 PM, larryllix said:

These random operations have been doing this about twice per year with other external inputs also. It seems ISY doesn't have any security to stop any external device from clobbering it by writing to the wrong place.

Some basic role-based controls would be handy,  even if just being able to make new usernames allowed only a subset of REST calls.

Adding security is a trade-off, it's difficult to do much more than what the Portal already does without adding a ton of overhead and complexity (to the software, and in the configuraiton) that will just drive users away and onto a simpler (and less secure) solution.       My proxy has strong role-based access control, but what I built would've been a five-figure project if I was doing it for my day job.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...