New 1.87 build of SPJS released for Linux & Windows. Has the terminal and NoceMCU changes in it so you can better interact with your devices. https://github.com/chilipeppr/serial-port-json-server/releases
Don’t want to rain on your latest improvements (we all appreciate it), but is there any way to disable the execution of remote commands? I don’t want to open up myself to arbitrary code execution by visiting any web page that connects to a websocket. Everything I’ve ever read on socket programming has told me that performing blind code execution is a bad idea (unless there is secure auth involved such as ssh).
In the new dev branch you can just add a -noexec in the command line when you launch to disable it. One of the things to keep in mind is that security in SPJS today is non-existent and you are expected to do your own security at a layer higher at your firewall. For example, today if you open your SPJS through your firewall to the Internet, people could move your machine around.
well, but if I understand correctly, this would allow command execution regardless of firewall… since the javascript is being executed in my network, any webpage that has javascript could connect to that websocket and perform arbitrary code execution… is that not right?
I would say there’s not much of a difference to what SPJS has been since its origins. SPJS expects security at a higher layer. When you load http://chilipeppr.com it is connecting to your SPJS via localhost or an IP address without any password and over clear text. You can even program your firmware from SPJS, which means anybody could do that as well. If you are worried about scripting attacks from other websites perhaps consider shutting off SPJS when not in use.
Ok, but just want to confirm I am correct. Don’t tell folks about protecting security with a firewall as that will give a very false sense of security.
I’m fine with a website trying to command my unpowered machine or try to program my microcontroller. What I’m not ok with is arbitrary code execution on my network. That’s a gigantic hole.
What’s interesting is that if rogue websites are resorting to SPJS script injection attacks, we know SPJS has crossed the chasm from a small DIY community to the mainstream masses.
True, but that is hardly the sort of attention you want. And if it happens, and people see that the code allows text from a remote source to be blindly executed (and possibly as root for those running it as a service), developers will line up to say “how could he have done that?”
If you don’t intent to add secure auth, or a certificate based trust on the incoming commands, I would advise making this feature off by default and letting users who need it turn it on.
The Arduino guys are using SPJS as part of their new web IDE, so they are in the same boat. The great thing about open source is that as they tackle this problem we can inherit their code. In the meantime, would you be willing to look at how to add CORS headers to SPJS to only allow http://chilipeppr.com and localhost to access it?
no, unfortunately i’ve got one too many projects going on right now. I think turning it off by default would be a trivial change though.
If the arduino guys really do it this way and have it on by default, and have thousands of developers running this, there is about to be some yelling going on.
something like a websocket to a ssh channel might get around all these issues and actually give you more functionality. something like this: https://github.com/aluzzardi/wssh
and for golang, there is the ssh package, which I believe has an ssh server implementation in it: https://godoc.org/golang.org/x/crypto/ssh
Or just something as simple as asking for the username/password to authenticate. It could be asked once for the workspace where an apitoken is exchanged with SPJS and then stored in the cookie just for that workspace path so its not available anywhere else or any other URL. If another workspace wants to use it they would just have to ask for a username/password again and get their own apitoken. It’s the way Github lets others authenticate to their system.
well, i don’t know all the ins and outs of what you are suggesting or all the various attacks that could be used to exploit it… but i can say that implementing your own authentication rather than using something like ssh seems like a bad idea unless there is a very big technical reason to do so. I can’t imagine just how many hours have been put into securing something such as ssh.
You can’t SSH from the browser. So, since you’re already connected to SPJS but really want to elevate access from SPJS to the OS all you really need to do is authenticate to the operating system for that instance.
i’m suggesting that “all you need to do” is potentially way more complicated than you suggest to do it securely… and yes, you can’t ssh from the browser, i’m just suggesting that the websocket could be a bidrectional bridge to a ssh tty on the SPJS host, similar to the examples I sent. then you don’t have to implement authentication at all, or come up with any new logins or passwords… you can leave all that to ssh on the host.
I think you know what my concerns are and what my suggestions are, so I’ll leave this thread at that.