English 中文(简体)
"反向"利用出站TCP连接的风险"
原标题:
  • 时间:2009-03-26 18:43:44
  •  标签:

我正在构建一个服务器应用程序,通过在只对与应用程序连接的相关 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:

  • Third parties can send info-in based on what the protocol supports. Its pretty much a lost battle, as there isn t anything you can really rely on that would block them completely. See below.
  • If you want to ensure the information is coming from the right third party, then you should need signed information. Some higher level protocols can do this for you. You are exposed to vulnerabilities in the implementation, but if the protocol supports it rolling your own will hardly be less vulnerable.
  • If you want to ensure the information is private, you need encryption. Some higher level protocols can do this for you. The same comments as above apply.
  • You are exposed to any vulnerability in the lower level protocols used (implicitly or explicitly). Its both impossible and impractical to roll your own of everything, and if you did you are likely to introduce vulnerabilities. Of course, make sure to have the latest patches.




相关问题
热门标签