我知道这个问题已经被问过很多次了，但是我对此有一些不同的看法。这是一个两部分的问题。
首先，我要实现自动登录，我想知道工作流程中的任何漏洞。
其次，我不清楚黑客如何利用他们窃取的信息来危害系统。
第一部分，这是我的工作流程，哪些部分易受攻击。以下是一些可能会有所帮助的信息，我正在使用PHP 5.6.21。我将使用他们的新哈希API，该API使用最新的哈希技术并自动对其进行加盐处理。我使用的是MVC体系结构，因此除前端控制器和个人资产外，几乎所有其他内容都不在Web服务器的根目录下。
成员登录并选择自动登录复选框
将具有与成员表中的哈希值匹配的哈希值的cookie写入其浏览器。Cookie只能从服务器上位于根目录之外的成员目录中访问。同样，设置了httpOnly属性。
成员下次登录时，将检查该cookie是否存在，如果存在，则使用哈希值作为在成员表中查找成员的键。
如果找到它们，则将其登录。如果设置了cookie，但是没有找到匹配的记录，则可能是cookie被篡改了。在这种情况下，请在数据库中创建一个新的自动登录哈希，然后在成员浏览器中删除cookie。然后，强制他们手动登录。如果他们再次选择自动登录，则使用新的哈希返回到步骤1。
因此，它非常简单，没有用户数据存储在cookie中，只是无意义的哈希。
我的问题的第二部分更为笼统。假设某位黑客以某种方式破坏了自动登录Cookie并获取了has代码。他们能做什么呢？他们如何使用它来危害我的系统？
就SQL注入而言，我了解可能会进行数据转储，并且黑客可能会获得数据库的只读视图。在这种情况下，必须对密码进行哈希处理和加盐处理！他们可以通过自己的恶意机器运行这些哈希，并可能获取您的登录凭据。
我正在阅读一些安全性文件，以了解采取所有这些措施的重要性。它一直在说，如果黑客可以访问您的数据库...但是，如果黑客可以访问您的数据库（具有写权限），那么这都不重要，因为无论您的哈希值有多强大，您都被搞砸了。
谢谢你的时间！
这有两个部分：
第二部分更有趣，因为许多人停止了“生成随机令牌，将其存储在cookie中，然后在数据库中查找它”的步骤。
您可以放心地认为，经过高度优化的数据库查询不是在恒定时间比较字符串，就像为了防止计时攻击而需要的一样。
解决方案是将令牌分为两部分：一个用于数据库查找（定时泄漏），另一个用于固定时间比较。
根据选择器检索令牌后，您可以使用hash_equals（）将用户提供的验证程序的哈希值与存储的哈希值进行比较。
每个长期身份验证令牌仅应使用一次。之后，应向最终用户发出替代品。注销应清除cookie，而会话应在关闭浏览器时到期。
仅当您将HTTPS与HSTS一起使用并且cookie设置为仅HTTPS时，这才是安全的！（这意味着secure和httpOnly都设置为true。）
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句