我的网络应用程序的身份验证机制目前非常简单。
当用户登录时，网站会发回一个会话cookie，该cookie会在用户的浏览器中存储（使用fun foo _ 0 = ()
| foo filenm n = let val _ = TextIO.openIn(filenm) in foo filenm (n - 1) end
fun bar _ 0 = ()
| bar filenm n =
let val ins = TextIO.openIn(filenm)
val _ = TextIO.inputLine(ins)
val _ = TextIO.closeIn(ins)
in bar filenm (n - 1) end
）。
但是，这个cookie很容易被盗，并用于从另一台机器重放会话。我注意到其他网站（例如Gmail）有更强大的机制来确保只复制cookie不允许您访问该会话。
这些机制是什么，小公司或单个开发人员是否有办法使用它们？
答案 0 :(得分：3)
我们遇到了类似的问题。如何安全地存储客户端数据？
我们最终使用HttpOnly cookie，其中包含UUID和该UUID的另一个副本（存储在localStorage中）。每个请求，用户都必须将UUID和cookie都发送回服务器，服务器将验证UUID是否匹配。我认为这就是OWASP's double submit cookie的工作方式。
基本上，攻击者需要访问cookie和localStorage。
答案 1 :(得分：1)
以下是一些想法：
始终使用https - 并且仅使用https。
将cookie保存在存储系统（nosql / cache system / db）中并将其设置为TTL（到期）。
永远不要将收到的cookie保存到存储中，但在保存或检查之前添加salt并哈希，就像使用密码一样。
始终从商店清理过期的会话。
保存发布IP和IP2Location区域。因此，您可以检查IP是否更改。
独家会话，一个用户一个会话。
检测到会话冲突（另一个ip）踢用户和下一次登录请求2路认证，例如发送短信到已注册的电话号码，以便他可以在登录中输入。
在任何情况下都不会加载不受信任的库。更好的是托管您在自己的服务器/ cdn上使用的所有库。
检查没有注射漏洞。像个人资料或通常会以某种方式向用户回复的东西必须大量消毒，因为它们是妥协的主要载体。对于通过任何东西发送到服务器的数据也是如此：cookies，get，post，headers必须对客户端可能使用或不使用的所有内容进行清理。
我应该提一下SQLInjections吗？
使用url会话或在本地存储中存储加密会话ID的双重会话很不错，但它们最终都无用，因为两者都可以访问已包含在您网站中的恶意代码，例如从一个以某种方式被劫持的域名（dns毒药，complomised服务器，代理，拦截器等......）。努力是勇敢的，但最终是徒劳的。
还有一些其他选项可以进一步增加获取和有效使用会话的难度。例如，您可以重新发出会话ID非常频繁地重新发出会话ID，如果它早于1分钟，即使您保持用户登录，他也会获得新的会话ID，因此可能的攻击者只需要1分钟就可以通过劫持会话做一些事情标识。
即使你应用了所有这些，也无法保证你的会话不会被这种或那种方式劫持，你只是难以置信地做到不切实际，但不要搞错。 100％安全是不可能的。
在服务器级别需要考虑许多其他安全功能，例如执行隔离，数据隔离等。这是一个非常大的讨论。安全性不适用于系统，它必须是系统从头开始构建的方式！
答案 2 :(得分：0)
确保您绝对不会受到XSS attacks. 的影响。如果您有以下所有内容，则无效！
显然，你混合了两件事：LocalStorage和Cookies。
它们绝对是两种不同的存储机制：
HttpOnly，则可以使用JavaScript 读取。现在我假设您使用令牌（可能是JWT？）来验证用户。
如果您将令牌存储在LocalStorage中，那么只需确保将其发送到服务器，将其作为HTTP标头发送，并且您将全部完成，您将不会受到攻击什么东西。 这种存储/认证技术非常适合单页面应用程序（VueJS，ReactJS等）
但是，如果您使用Cookie来存储令牌，那就会出现问题：虽然令牌可以不被其他网站窃取，但它可以是由他们使用。这称为Cross-Site Request Forgery. (CSRF)
这种攻击基本上可以通过添加类似的东西来实现：
<img src="https://yourdomain.com/account/delete">
当您的浏览器加载其网页时，它会尝试加载图片，并且还会同时发送身份验证Cookie，最终，它会删除用户的图片帐户。
现在有一个很棒的CSRF prevention cheat sheet列出了解决这种攻击的可能方法。
一个非常好的方法是使用Synchronizer token method.它基本上可以通过生成令牌服务器端，然后将其作为隐藏字段添加到您尝试的表单中以确保。然后，在提交表单时，您只需在应用更改之前验证该令牌。 此技术适用于使用简单表单的模板引擎的网站。 （不是AJAX）
HttpOnly标志也为cookie增加了更多安全性。
答案 3 :(得分：0)
您可以通过电话号码或电子邮件使用2步验证。蒸汽也是一个很好的例子。每次从新计算机登录时，您都必须将其标记为“安全计算机”或使用电话号码/电子邮件进行验证。