HTML/JavaScript 组合以确保安全

发布于 2024-08-27 10:04:02 字数 247 浏览 3 评论 0原文

我刚刚遇到这一点引用了证券Web 应用程序中的漏洞依赖于查看加密网页的大小来推断用户正在做什么。我能想到的最简单的解决方案是使用工具来缩小所有静态内容,以便(加密后)仅存在少量结果大小,从而最大限度地减少窃听者可用的信息。

有没有工具可以做到这一点?

I just ran across this point that references a security vulnerability in Web Apps that depends on looking at the size of encrypted web pages to deduce what the uses is doing. The simplest solution to this I can think of would be to use a tool to minify all static content so that (after encryption) only a small number of result sizes exist so as to minimize the information available to an eavesdropper.

Are there any tools for doing this?

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

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

发布评论

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

评论(2

你的他你的她 2024-09-03 10:04:02

缩小静态内容的默认操作是启用 HTTP 压缩。它会稍微减少结果大小的数量。

但请考虑一下,如果将内容缩小到一半大小,结果大小不一定只有一半!仅当您的原始内容使用所有可能的尺寸时才会出现这种情况。假设您的原始内容提供 4 种不同的大小:10kB、12 kB 和 14 kB。

如果您的压缩将它们分别缩小到一半大小,您最终仍会得到三种不同的大小:5kB、6kB 和 7kB。

注意要明确一点(也许不是):这是一个反对使用缩小/压缩的建议。另请参阅我的评论。

The default thing to do a minification of static content would be to enable HTTP Compression. It would reduce the number of result sizes a bit.

But consider, that if you shrink the content to half the size, there will not necessarily be only half as many result sizes! This would only be the case, if your original content used all the possible sizes. Let's say, your original content offers 4 different sizes: 10kB, 12 kB and 14 kB

If your compression shrinks each of them to half size, you'll still end up with three different sizes: 5kB, 6kB and 7kB.

Note To make it clear (maybe it wasn't): This is rather an advice against using minification/compression. See also my comment.

九厘米的零° 2024-09-03 10:04:02

不,我不知道有什么工具可以防止这种攻击。原因是这是一种非常有限的攻击,在现实世界中并不常见。许多加密攻击在现实世界中完全没有用。

为了防止这种攻击,服务器可以向消息添加随机填充。对于异步脚本,您可以添加垃圾 xml 或 json 元素。在其他情况下,您可以添加 html 或 javascript 注释。这实施起来很简单,我不认为这需要一个“工具”。

军事网络这样做是为了通过使用持续的数据流来防御这种攻击。我认为它在传输层或网络层上实现了以太坊。使用 http 在应用程序层上实现这一点会很棘手。此外,带宽不如军事机密重要,而您的网络应用程序可能并非如此。

No, I do not know of a tool to prevent this attack. The reason why is because this is a very limited attack that isn't common in the real world. Many crypto attacks are completely useless in the real world.

To prevent this attack the server can add random padding to the message. In the case of async-scripts you could add junk xml or json elements. In other cases you could add html or javascript comments. This is trivial to implement and I don't think this warrants a "tool".

Military networks do this to defend against this very attack by using a constant stream of data. I think its implemented ether on the transport or network layer. It would be tricky to pull that off on the application layer with http. Also, bandwidth is much less important than military secrets, where as this is probably not the case with your web app.

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