如何检查套接字连接到的目的地？
例如，如果我编译的应用程序中的套接字设计为连接到 123.456.789.0。 如何检查它是否连接到 123.456.789.0？ 有没有办法做到这一点？
想法是这样的：我想防止其他人编辑我的程序并将地址更改为例如 127.0.0.1 并使其通过代理连接。
连接套接字后是否有任何功能/方法/技巧来检查地址？
If,for example,The socket in my compiled application is designed to connect to 123.456.789.0.
How do I check if its connected to 123.456.789.0? Is there a way to do this?
The idea is this:I want to prevent other people editing my program and changing the address to,for example, 127.0.0.1 and make it connect through a proxy.
Is there any function/way/trick to check the address after the socket is connected?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 getpeername 函数检索地址远程主机的。
如果有人像您提到的那样编辑您的程序，他们也可能会更改这样的检查。
Use the getpeername function to retrieve the address of the remote host.
If someone edits your program like you mention, they'll probably alter such a check as well though.
nos 关于这种方法不安全的评论是正确的，但不完整。 您甚至不需要更改程序的代码来规避您提出的机制。
最简单的解决方法是将 IP 别名添加到计算机的网络接口之一。 然后，程序可以绑定到您的程序连接的端口上的该接口，并且操作系统的网络堆栈将很乐意将连接发送到攻击者的本地程序，而不是您的远程程序。
那么，现在您说您想知道如何列出计算机的接口，以便可以检测到这种破坏。 你的对手进行反击，在安装一个 Winsock 钩子后将你的程序作为他们的子进程启动，该钩子通过父进程路由 Winsock 回调。
然后，我们希望您询问如何读取加载到进程空间中的特定 DLL 的可执行代码部分，以便您可以检查代码是否是您所期望的。 现在，您的对手放弃了 Winsock shim，切换到 NDIS 层过滤器，在数据包到达 NIC 之前重写您的程序中的数据包。
接下来，我们发现您正在寻找某人来告诉您如何列出 Windows 系统上安装的驱动程序，以便您可以检查这些过滤器之一是否不存在。 你的对手思考了大约 6 秒，决定开始搞乱数据包路由，从我能想到的至少三种不同的攻击中选择一种。 （不，等等，四个。）
我不是安全专家。 然而，我已经花了五分钟的时间来解决这个问题，并且已经通过七种不同的方式击败了您的安全。
你注定了吗？ 也许，也许不是。
与其对你看到的风险提出修复方案，不如发布一个新问题，说明你想要保护的内容，并让专家对风险和可能的修复方案发表评论。 （不要在此处添加它。您的问题已经由 nos 正确回答。这是一个不同的问题。）
安全性很难。 该学科的专业知识比计算机科学的大多数其他领域更重要。
nos's comment about the insecurity of this approach is correct, but incomplete. You wouldn't even need to change the program's code to circumvent your proposed mechanism.
The easiest way around it would be to add an IP alias to one of the machine's network interfaces. Then a program can bind to that interface on the port your program connects to, and the OS's network stack will happily send connections to the attacker's local program, not your remote one.
So, now you say you want to know how to list the computer's interfaces so you can detect this sort of subversion. Your opponent counterattacks, launching your program as a sub-process of theirs after installing a Winsock hook that routes Winsock calls back through the parent process.
We then expect to find you asking how to read the executable code section of a particular DLL loaded into your process space, so you can check that the code is what you expect. Now your opponent drops the Winsock shim, switching to an NDIS layer filter, rewriting packets from your program right before they hit the NIC.
Next we find you looking for someone to tell how to list the drivers installed on a Windows system, so you can check that one of these filters isn't present. Your opponent thinks for about 6 seconds and decides to start screwing with packet routing, selecting one of at least three different attacks I can think of off the top of my head. (No, wait, four.)
I'm not a security expert. Yet, I've spent five minutes on this and already have your security beat seven different ways.
Are you doomed? Maybe, maybe not.
Instead of you coming up with fixes to the risks you can see, better to post a new question saying what it is you're trying to protect, and have the experts comment on risks and possible fixes. (Don't add it here. Your question is already answered, correctly, by nos. This is a different question.)
Security is hard. Expertise counts for far more in that discipline than in most other areas of computer science.