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