我正在构建一个服务器应用程序,通过在只对与应用程序连接的相关 IP 端口开放出站流量的防火墙上发起 TCP 连接来维护与其他应用程序的连接。
如果有人接管了我们连接的计算机,他们能够通过我们建立的出站连接向后利用我们的应用程序,这种情况的风险是什么?
连接使用的协议并不难以猜测,但是它是基于定期心跳的(间隔30秒)。如果连续两个心跳被错过,初始发起者(我们)将终止连接并重新连接。
我们应用的源代码或二进制文件将不会提供给我们连接的机构。
我正在构建一个服务器应用程序,通过在只对与应用程序连接的相关 IP 端口开放出站流量的防火墙上发起 TCP 连接来维护与其他应用程序的连接。
如果有人接管了我们连接的计算机,他们能够通过我们建立的出站连接向后利用我们的应用程序,这种情况的风险是什么?
连接使用的协议并不难以猜测,但是它是基于定期心跳的(间隔30秒)。如果连续两个心跳被错过,初始发起者(我们)将终止连接并重新连接。
我们应用的源代码或二进制文件将不会提供给我们连接的机构。
It is straightforward for an attacker to sniff the network traffic to your server if they have access to the machine or network you are connecting to. This could allow him to reverse engineer your protocol, and then either try and inject malicious data into the data going back to your server, or replace the client side application altogether.
Since it sounds like you can t trust the client side application, it doesn t matter who is initiating the connection, once it s up, you have a two-way communication channel. The best thing to do in this case is to validate all the data coming from the client.
If you can trust the client, but not the network, then adding some encryption to your network protocol will help.
If your own application server does not listen for any incoming data then there is very little risk
They can t do anything to you other than speak your protocol to you. The risk is precisely that anything that can be done, from their end to your end, using your protocol, will be done.
N.B. I don t mean they have to speak a well-formed version of your protocol to you. If your system reads incoming messages into a static buffer using fgets(), then buffer overruns are part of what can be done to you using your protocol.
Your scenario is a fairly common one, its really rare to have a network completely isolated from the internet. That said, consider the following factors involved: