服务器如何知道请求来自客户端,而不是窃听黑客?
Posted
技术标签:
【中文标题】服务器如何知道请求来自客户端,而不是窃听黑客?【英文标题】:How can a server know the request is coming from client, not an eavesdropping hacker? 【发布时间】:2016-10-12 00:27:09 【问题描述】:我有一个简单的问题,我找不到简单的答案,可能是我遗漏了一些东西,或者我不知道某些网络概念是如何工作的。我想知道我不知道的事情。
简单来说,问题是虽然窃听是可能的,但服务器如何知道请求来自客户端,而不是窃听黑客。
场景:
无论我有什么安全策略,我都应该向客户发送一些东西。它可能是非对称加密令牌或某事。客户端没有私钥,因此无论客户端能够做什么,发送等,黑客都可以做,也可以发送。
保护 Web 应用程序背后的逻辑可能是什么。应该有一些只有客户知道的秘密。
顺便说一句,我正在学习 JWT,这是我第一次学习 auth。但是这个简单的问题是我仍然无法找到答案的问题。
【问题讨论】:
想象一个已经建立的到标准登录网页的 HTTPS 连接(连接是安全的)。黑客可以创建完全相同的连接。现在客户端可以登录 - 只有客户端知道凭据(一些纯文本“秘密”)才能继续。在这种情况下,服务器相信连接是安全的,并且基于提供的有效凭据相信客户端就是他们的身份。这与要求 SSL 客户端证书不同,后者将客户端真实性建立为 HTTPS 连接本身的一部分。无论如何,请参阅Key exchange。 (HTTPS 连接是通过密钥交换建立的,以提供共享密钥:这可以保护通道免受窃听者的侵害,但不足以证明客户端不是攻击者。每当客户端必须证明自己时,客户端必须知道(秘密)某事 - 或者在多因素身份验证的情况下,拥有(受控)某事 -可以验证。) 【参考方案1】:服务器如何知道请求来自客户端,而不是客户端 窃听黑客?
没有。
由客户端来验证服务器是否是它期望与之交谈的服务器。它叫做Public Key Infrastructure。
可以使用 TLS/SSL,因此通过 HTTPS 进行连接 - 请注意,它不必是 Diffie Hellman,还有其他密钥交换机制,例如 RSA。
想象以下场景。
Client --> HTTPS --> example.com
客户端将对 example.com 进行 DNS 查找,并返回 203.0.113.10。客户端将通过 HTTPS 连接到 203.0.113.10,连接的初始部分称为握手过程。在这里,客户端检查它正在考虑连接的域 example.com 是否具有由受信任的证书颁发机构签名的证书,其主题设置为“example.com
”。这将防止以下情况发生:
Client --> HTTPS --> Attacker (fake example.com)
例如,如果攻击者接管了 DNS 服务器并将 example.com 更改为指向他 (198.51.100.200)。
之所以阻止此攻击,是因为攻击者无法向证书颁发机构证明 example.com 的所有权,因此无法签署他们的证书以向客户端证明他们的服务器是受信任的。
HTTPS 还会对连接进行加密,并以安全的方式交换密钥。这可确保无法读取已建立的连接。
所以一旦建立连接,并且用户登录,服务器将向客户端发送一个会话令牌,该令牌可以是 JWT 的形式。如果这是一个 cookie 并且设置了 Secure Flag,则只能通过 HTTPS 连接传输。这就是服务器知道它没有被拦截的方式,因为客户端已经验证了服务器并使用双方同意的唯一密钥对传输到它的数据进行了加密。
Client --> HTTPS --> Attacker (fake example.com) --> HTTPS --> example.com
也不可能(主动中间人),它显示了您原始问题中的情况,即有人拦截通信并将 JWT 传递到真实服务器,观察传输中的私有数据。但是,如果使用纯 HTTP(无 SSL/TLS):
Client --> HTTP --> Attacker (fake example.com) --> HTTP --> example.com
【讨论】:
清晰而出色的答案。谢谢你。你为我节省了很多时间!【参考方案2】:查找 Diffie-Hellman 和 SSL/TLS 加密。这里有一些东西可以帮助您入门。 https://blog.hartleybrody.com/https-certificates/
简短的回答是,当客户端启动与服务器的连接时,他们共享一个未公开公开的密钥。问题是,客户端需要与它认为要连接的服务器建立初始连接。
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
【讨论】:
【参考方案3】:确实,在建立新连接时,只有客户端知道什么。 这就是发明 Diffie–Hellman key exchange 和类似方法的原因。
它们通过在服务器和客户端之间发送问题和答案来工作。 使用(实际上)不太复杂的数学方法多次执行此操作,客户端和服务器可以共享只有他们知道的密钥,即使第三方拦截了流量。
我无法完全解释这个概念,但我可以推荐this StackExchange 问题,它将很好地概述该主题。
编辑:我现在才听说 JWT,所以这个答案可能完全断章取义。
【讨论】:
以上是关于服务器如何知道请求来自客户端,而不是窃听黑客?的主要内容,如果未能解决你的问题,请参考以下文章
在 Django 中为来自客户端的请求和来自服务器的响应(REST API)压缩 JSON 有效负载。