GraphQL (GQL) Security

Regarding the GQL Interface (GraphiQL) that is built-in to SambaPOS …


Additional References:

https://forum.sambapos.com/t/graphql-security-apps-authorization-and-users/13797

GraphiQL interface is for testing and documentation only and should be enabled for Local Network only, so “security” should not be a concern in that regard.

When you are finished with your tests, just disable the Application.

Running GQL inside JScript inside SambaPOS poses no security threat, and does not require App setup at all.

If you are developing an APP, then you are responsible for setting up security however you see fit by limiting to local network, or if exposing to Internet, doing SSL/https, strong passwords, secret key, etc.

Yes. If running SambaPOS on a server and having all clients connect via RDP (using either SSL or native RDP encryption) and the app is running inside a widget, there shouldn’t be any security issue, at least nothing related in this context.

But there is little gained from using access tokens on a non-SSL server without the addition of externally provisoned secure network tunneling. And that isn’t mentioned anywhere on the forum afaik.

My point is that SSL support on the GQL server is something needed to complement the private key and token handling functionality.

That’s what I’m saying though - it is not, because implementing that is up to you. The GQL Server is not going to talk to anyone outside your local network unless you configure it to allow that by configuring the Application as such.

And if you do allow external access (ie. making an App of your own), then you don’t use the SambaPOS Webservice. You use your own, whether that be Apache or IIS or whatever, which you can secure using SSL. Then all communication is encrypted - that is not a role that GQL Server needs to provide.

Forget about RDP for the moment - it has nothing to do with securing GQL, or whether it needs to be secured or not. RDP in the scope of SambaPOS is IMO a hack that happens to work for people. But nowadays, it should be abandoned in favor of GQL Apps. Personally, I have never used RDP with SambaPOS, and now that I have QMX, I never need to use it.

Correct me if I’m wrong … so what you’re in effect saying is that GQL is designed to only operate as an intermediary between a locally hosted web server and SambaPOS? It isn’t designed to work as an online web service or support an app hosted on a different physical machine on the local network, or elsewhere?

In my case i am running separate isolated WiFi networks so the issue is minimal on the local network. But i’m concerned about others’ implementations. They probably don’t realize that issuing “secure” tokens is pointless in many likely scenarios, so these limitations and caveats using GQL need documenting.

I can see how tokens provide an excellent way to provide access compartments with limited rights on the server. But people need to realize that any GQL connection originating external to the physical server (any connection other than localhost) needs to be tunneled by other means … otherwise … those tokens won’t be able to secure access. This is because any logins requesting tokens using a plaintext connection can be easily replayed, so security can be trivially circumvented in such a configuration. Other server transactions can be replayed in realtime by anyone with access to that network. A fine tuned firewall configuration could mitigate this weakness to a large extent but not prevent more advanced packet spoofing etc.

This is obviously a topic for another thread …

I dont think you read all of his post. He said you can certainly do that but you need to host your own web server and secure it not use the built in server from message server.

You are not wrong; you are correct, however…

GraphQL (GQL) is simply a query language that allows “external” access to certain SambaPOS functions. What you use it for, and how, is your responsibility.

Correct again. If an App is not communicating over a secure channel, then App GQL Authorization (Username, Password, Tokens) - in fact, everything (all GQL queries, mutations, and responses) - can easily be seen in plain text. If this only occurs in a local network, it is a moot point.

If the App is used over the Internet, then it becomes a very important consideration - one that needs to be handled appropriately by securing the channel with SSL, and GQL Auth could also be performed Server-side. But again, that is not the role of GQL - it is the role of the App Server-Client.

Whether or not this needs “documenting”, well, maybe, but anyone doing that type of “serious” App development should immediately be able to recognize that fact.

And there is your documentation of this matter :wink: Now everybody knows.

Thanks for the clarification!
ok. I guess I’ll have to put that “documentation” just created here into a post with appropriate subject so it is easily found and not buried inside here.

You can see now the question was somewhat rhetorical, plus the real implied question being “What was the intention behind the key token protocol?”

My observation here is that, without SSL capability built into the native GL server, the tokens are actually rather useless (except when tunneling via an public connection). Reading the documentation as it is, and seeing them there suggests a different intention: of allowing connections from an untrusted client and thus needing to lockdown the services available to that untrusted client.

Now I’m feeling like I should put together a tutorial on this whole subject: about these security caveats and how to set up a secure SSH tunnel for securely exposing the GQL server to the internet.

1 Like

That is a great idea - I am interested to see what you have to share in this regard.

Ideal would be a nice infographic showing the various topologies people are likely to implement, showing the insecure and secure connections, token communication, etc. Also instructions on setting up port forwarding through an SSH server. On windows i don’t know which server would be most appropriate to use though.

Trouble is i’m rather busy debugging some tricky stuff here right now. I hope to get the time for writing it up at some point!

2 Likes