保护 HTTP 请求的部分内容?

发布于 2024-10-01 11:55:44 字数 117 浏览 6 评论 0原文

如何保护 HTTP 请求的某些部分(例如会话 ID)?我知道您可以使用 HTTPS,但是您的服务器必须解密所有请求。仅加密请求的所需部分不是很理想吗?

是否有任何框架或资源可以让您或告诉您如何做到这一点?

How does one go about securing parts of an HTTP request, say their Session ID? I know you can use HTTPS, but then your servers must decrypt all of the request. Wouldn't it be ideal to only encrypt the required parts of a request?

Are there any frameworks or resources out that that allow you or inform you how to do this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

落在眉间の轻吻 2024-10-08 11:55:44

HTTPS 是正确使用的工具。解密数据包的计算负载非常低。今年早些时候,谷歌将整个 GMail 默认改为 HTTPS,他们报告称,其服务器上用于 SSL 加密/解密的 CPU 负载约为 1%。

如果您只加密部分流,那么您仍然会遇到中间人攻击和重放攻击的问题。 SSL 是防止这些问题的唯一方法。会话 ID 是否加密并不重要。如果中间人可以捕获它,他就可以以加密形式重用它,而服务器不会知道其中的区别。

这是一篇博客文章,介绍了自 GMail 切换到 100 以来 Google 的体验%SSL。

HTTPS is the correct tool to use. The computational load of decrypting the packets is very low. Google changed to HTTPS by default for the whole of GMail earlier this year, and they report that the CPU load on their servers for SSL encryption/decryption is around 1%.

If you only encrypt part of the stream then you still have the problem of man-in-the-middle and replay attacks. SSL is the only way to prevent these. It doesn't really matter if the session ID is encrypted. If a man-in-the-middle can capture it, he can reuse it in it's encrypted form, and the server wouldn't know the difference.

Here's a blog post about Google's experience since the GMail switch to 100% SSL.

缱倦旧时光 2024-10-08 11:55:44

HTTPS 要么全有,要么全无。如果页面上的所有元素并非都通过 HTTPS 进行保护,那么用户通常会在左上角看到“损坏的锁”。这是因为攻击者可以利用它来注入类似于 xss 的攻击并获取 document.cookie 值。

此外,如果发送 1 个带有会话 ID 的请求,则攻击者可以获得该值并以您的身份进行身份验证。

HTTPS is all or nothing. If not all elements on a page are secured with HTTPS then users will get usually get a "broken lock" in the upper left corner. This is because an attacker could use this to inject an attack similar to xss and obtain the document.cookie value.

Further more if 1 request is sent with a session id then an attacker can obtain the value and authenticate as you.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文