0

I've got a server that handles requests from a client to a sql database. The server accepts requests and gives responses in json. I have written the code for the server and the client, and everything is working. While this is for an internal tool only, I have concerns that some people may try to bypass the client and send their own json messages to the server to potentially manipulate data on the sql database.

I'm not a security guru, so here's my question. What would be the proper method to go about ensuring that the server only accepts requests from the client I wrote, regardless of the machine or IP it's running on?

My initial thought is that I should be encrypting messages between the server and client, so if someone tries to spoof the connection with an unauthorized client they won't have the proper encryption. I also realize I should put authentication on the server side, but that means passing around credentials so the messages should be encrypted anyway. If there is a more accepted way of doing this, I would love to know. If not, links to tutorials would be appreciated.

As the tags state, this is on linux in c++. While I'm sure there's probably some open source library out there that does exactly what I want in all things, I'm pretty restricted as to what libraries I can actually use.

Thanks!

  • If you're worried about security issues and can't use a security library, your best bet is to get a Master's degree in a security field or find somebody who has the equivalent. Other than that, [Boost.Asio](https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio.html) has SSL built-in. – Zuodian Hu Apr 06 '20 at 18:45
  • your server is public ? or used only in your local network ? – Landstalker Apr 06 '20 at 18:50
  • @Landstalker the server is only for a local network – Dragonfiremalus Apr 06 '20 at 19:04
  • 1
    You should be limiting what people can do, not how they do it. The former can provide real security, the latter really can't. So long as the server/client protocol doesn't allow users to do anything they're not supposed to do, why do you care what client they use? Implement the security in the server. – David Schwartz Apr 06 '20 at 21:59

2 Answers2

0

The de-facto standard for securing network communication is TLS (transport-layer security). It both encrypts and signs a TCP stream without actually exchanging private keys over the network. This prevents MITM and replay attacks and makes it possible to verify authenticity of the server and/or the client by either checking that their certificate is signed by a trusted party (CA) or simply by storing the hash of it (fingerprint) beforehand. Alternatively, TLS can be used only to encrypt traffic, and a plain password to authenticate clients.

There are many open-source libraries that implement TLS. One popular one is OpenSSL.

rustyx
  • 80,671
  • 25
  • 200
  • 267
  • I'm familiar with a little bit of TLS for server authentication, but sounds like it also can be used for client authentication? Then that does sound like what I want to go for. I was reading up on it, but didn't see that bit mentioned. I'll look deeper into it. – Dragonfiremalus Apr 06 '20 at 19:28
0

I present you some filtering and protection measures of lower level which will complement other software measures (TLS, SSL, ...)
As the server is local, access will only be possible by local clients. This allows you to apply filtering by:

  • IP adress
    when a client connects (on the accept() function of your server) you have a structure indicating your client's IP address. You can reject it ip address is not in the list of authorized IP adresses.

  • Hostname
    If a DHCP is activated, you can use nslookup command to get hostname (name of the machine). You can reject connections that come from a hostname that does not belong to your trusted list.

nslookup xxx.yyy.zzz.www  // Give you the hosname of adresse  

enter image description here

  • Mac address
    With the arp, you can get the MAC address (physical) of the Client's network card. You can reject it if its MAC address does not belong to your trusted list.
arp -a  

enter image description here

Remarques

  • This requires you to manage explicitly trust lists of : IP addresses, MAC, Hostname, ...
  • I remind that these measures can be applied only on a local network and can be applied as a complement to other softwar security protocols
Landstalker
  • 1,368
  • 8
  • 9