javascript - 保护 HTML/JavaScript 前端和后端之间的请求(身份验证)

Question

我正在尝试为用户创建一种安全的方式来登录并在我的自定义网站上执行某些授权操作。我试图在不使用 SSL 的情况下获得良好的安全性。 现在登录时，这就是我要改进的地方:

1. 用户输入凭据(电子邮件和密码)
2. 客户端浏览器 (JavaScript) 使用 SHA-512 单向散列密码，将凭据作为登录请求发送
3. 基于 Java 的后端接收请求，进一步加密接收到的密码散列(使用盐等)以适应数据库中的散列(在注册时创建)，检查匹配，并返回包含新 token 的 cookie。
4. 后端还将 token 连接到数据库中的用户，因此后端将根据此 token 知道 future 的请求来自谁(无需在请求中发送凭据)

这个想法是，如果有人设法获取这样的 cookie(或初始请求)，就不可能获得用户的密码。

这很好，但仍然存在重复攻击和中间人攻击的问题，当“坏人”收到请求并使用 token 代表其他用户执行操作时.

通过阅读如何防止这种情况发生，我发现一种可以接受的防止这种情况发生的方法是向 cookie 中的 token 添加一个“计数器”，以显示该 token 已被使用了多少次。 假设 cookie 最初包含一个 token 和一个为 0 的计数器，例如 cookie-content: "abc123:0"，其中 token 为 abc123，计数器为0。建议客户端在每次发出请求时递增计数器。假设一个用户想向另一个用户发送聊天消息。附加到此请求的 cookie 将包含 "abc123:1"。后端存储计数器和 token ，并检查这两个值。如果接收到的计数器大于存储的计数器，那就太棒了。如果“坏人”收到请求并尝试重复它，计数器仍将是 1，服务器将拒绝它，因为存储的计数器也是 1 >(或更多)。 这听起来不错，但我不确定这如何更安全？ “坏人”可以简单地将 cookie 中的计数器值编辑为 99999 并成功吗？

我想应该以某种方式对 cookie 的内容( token 和计数器)进行哈希处理，这样内容就不是纯文本了。但是，客户端是 HTML/JavaScript； “坏人”可以简单地检查使用了哪种加密方法，然后对其进行解密。所有脚本都是公开的。

我读到一些关于通过在发出请求之前从服务器向客户端发送一次性“ secret ”来改进这一点的内容，但我不知道如何实现它。我想，在请求 www.example.com/chat 时，我可以生成一个随机的“ secret ”，并将其发送给客户端，客户端可以在发送聊天消息时将其添加到 cookie 中，或者将其用作 key ，这样加密会更安全，但是服务器在收到请求后如何知道 secret 呢？服务器如何扭转这一局面？服务器在解密时必须知道 secret ，那么它应该存储在哪里呢？哈希旁边的 cookie 中的纯文本？然后“坏人”可以做同样的事情。在数据库中？在请求 www.example.com/chat 时，后端是否应该知道 WHO 正在请求它，以便它可以与该用户一起存储在数据库中？在这种情况下，后端应如何验证用户身份，以确保没有中间人或重复攻击请求/chat？

这种安全方法叫什么，是否可以将其用于我需要的(使用 HTML/JavaScript)？如果没有，除了 SSL，我还有什么选择？

Answer 1

这被称为不依赖于信任的不良安全。

客户端需要完全信任服务器，否则一切——包括用于输入密码的页面——都是不可信任的。目前建立信任的唯一方法是浏览器中提供的证书存储(您应该能够信任浏览器!)。唯一能够跨浏览器使用它的软件是 SSL/TLS。