我的 Web 应用程序的身份验证机制目前非常简单。
当用户登录时，网站会发回一个会话 cookie，该 cookie 存储（使用localStorage）在用户的浏览器上。
但是，此 cookie 很容易被窃取并用于从另一台机器重播会话。我注意到其他网站，例如 Gmail，具有更强大的机制来确保仅复制 cookie 不会允许您访问该会话。
这些机制是什么，小公司或单个开发人员是否也可以使用它们？
问问题
2276 次
4 回答
4
我们遇到了类似的问题。如何安全地存储客户端数据？
我们最终使用了包含 UUID 和该 UUID 的附加副本（存储在 localStorage 中）的HttpOnly cookie。每个请求，用户都必须将 UUID 和 cookie 都发送回服务器，服务器将验证 UUID 是否匹配。我认为这就是OWASP 的双重提交 cookie 的工作原理。
本质上，攻击者需要访问 cookie 和 localStorage。
于 2018-04-07T03:31:20.233 回答
1
这里有一些想法：
始终使用 https - 并且仅使用 https cookie。
将 cookie 保存在存储系统（nosql/cache system/db）中并将其设置为 TTL（到期）。
切勿将收到的 cookie 保存到存储中，而是在保存或检查之前添加盐并对其进行哈希处理，就像使用密码一样。
始终从商店中清除过期的会话。
保存发布IP和IP2Location区域。所以你可以检查IP是否改变。
独占会话，一个用户一个会话。
检测到会话冲突（另一个 ip）踢用户和下一次登录请求 2 路身份验证，例如向注册的电话号码发送短信，以便他可以在登录中输入。
在任何情况下都不要加载不受信任的库。最好在自己的服务器/cdn 上托管您使用的所有库。
检查没有注入漏洞。诸如个人资料之类的东西或通常以某种方式将用户输入的内容发回给用户的东西必须经过严格清理，因为它们是妥协的主要载体。通过任何方式发送到服务器的数据也是如此：cookie、get、post、headers 必须对客户端可能使用或不使用的所有内容进行清理。
我应该提到 SQLInjections 吗？
使用 url 会话或在本地存储中存储加密会话 id 的双会话都很好，但它们最终都是无用的，因为它们都可以用于已经包含在您的站点中的恶意代码，例如从域加载的库以某种方式被劫持（dns 毒药、被破坏的服务器、代理、拦截器等）。努力是勇敢的，但最终是徒劳的。
还有一些其他选项可以进一步增加获取和有效使用会话的难度。例如，即使您让用户保持登录状态，您也可以非常频繁地重新发布会话 id，如果它超过 1 分钟，他会得到一个新的会话 id，因此可能的攻击者只有 1 分钟的时间来处理劫持的会话ID。
即使您应用了所有这些，也不能保证您的会话不会以某种方式被劫持，您只会使这样做变得难以置信地困难到不切实际的地步，但不要误以为它是 100% 安全的将是不可能的。
您需要在服务器级别考虑许多其他安全功能，例如执行隔离、数据隔离等。这是一个非常大的讨论。安全性不是您应用于系统的东西，它必须是系统是如何从头开始构建的！
于 2018-04-07T22:56:40.423 回答
0
您可以通过电话号码或电子邮件使用两步验证。Steam 也是一个很好的例子。每次从新计算机登录时，您必须将其标记为“安全计算机”或使用电话号码/电子邮件进行验证。
于 2018-04-09T04:31:07.643 回答
0
确保您绝对不会受到XSS 攻击。 如果你是，下面的一切都是无用的！
显然，您混合了两件事：LocalStorage 和 Cookie。
它们绝对是两种不同的存储机制：
- Cookie是一串数据，随发送到服务器的每个请求一起发送。Cookies 作为 HTTP 标头发送，如果
HttpOnly未设置，则可以使用 JavaScript 读取。 - 另一方面，LocalStorage是浏览器提供的键/值存储机制。数据存储在浏览器本地，不会发送到任何地方。访问它的唯一方法是使用 JavaScript。
现在我将假设您使用令牌（可能是 JWT？）来验证用户。
如果您将令牌存储在 LocalStorage 中，那么只需确保当您将其发送到服务器时，将其作为 HTTP 标头发送，您就完成了，您将不会受到任何虚拟攻击。这种存储/身份验证技术非常适合单页应用程序（VueJS、ReactJS 等）
但是，如果你使用cookies来存储token，那么问题来了：虽然token不能被其他网站窃取，但它可以被他们使用。这称为跨站点请求伪造。(CSRF)
这种攻击基本上是通过添加以下内容来实现的：
<img src="https://yourdomain.com/account/delete">
当您的浏览器加载他们的页面时，它会尝试加载图像，并且它也会发送身份验证 cookie，最终它会删除用户的帐户。
现在有一个很棒的CSRF 预防备忘单，列出了绕过这种攻击的可能方法。
一种非常好的方法是使用同步器令牌方法。它的工作原理是生成一个令牌server-side，然后将其作为隐藏字段添加到您要保护的表单中。然后在提交表单时，您只需在应用更改之前验证该令牌。这种技术适用于使用具有简单表单的模板引擎的网站。（不是 AJAX）
该HttpOnly标志也增加了 cookie 的安全性。
于 2018-04-09T02:22:34.987 回答