iKo*_*ode 12 php security asp-classic laravel
用户使用默认的Laravel身份验证登录,该身份验证将加密的cookie放入浏览器,并将会话保存在数据库中.
用户移动到经典的asp页面,在那里我检查cookie值,获取哈希值,然后调用laravel app返回传递会话id哈希.
然后我在laravel中使用它来查看该id是否存在活动会话,如果是,则返回true,因此用户可以使用经典asp登录.
在经典应用程序中的每个页面请求中,我检查数据库中的last_updated_time并在每个页面上更新它.所有登录和注销都在laravel中完成,而classic依赖于数据库来查看会话是否处于活动状态.
我还会调用一个公共URL来获取会话变量并使用laravel添加会话变量,因为它全部加密并且使用经典的asp这样很难.
我看到的唯一风险是会话劫持,但我不认为它比平常更高的风险.
锁定我调用的laravel URL以检查它是否是有效会话是否重要？
我在这里错过了一个安全漏洞吗？
根据您的说法,您可能没有打开任何安全漏洞.会话cookie本身并不在用户计算机上加密,但您确保它们在您的计算机和您的计算机之间以及每台计算机之间进行加密.您应确保已设置安全标记以帮助防止cookie被意外地通过传统的未加密传输(HTTP)发送,但如上所述,这不会影响存储cookie本身.
话虽这么说,你基本上是在劫持你自己的用户会话.虽然现在可能没有引入漏洞,但您可能会削弱整个系统,这可能会导致未来出现漏洞.
这可能是一个愚蠢的问题,但你确定你需要会话吗？如果你在服务器之间处理凭据,听起来更像是你想要使用访问令牌并废弃会话.
使用访问令牌类似于使用会话,但您需要使您的服务无状态.这意味着您不再存储有关已登录用户的任何特定计算机的信息,因此每次遇到需要该信息的服务器时,您都需要从数据库中提取所需内容.
从长远来看,这是一件好事,因为当你不需要太担心会话的位置和内部的内容时,扩展服务会容易得多.
OAuth 2.0是广泛使用的标准(Facebook,Twitter,Google),并且专门设计为易于使用.RFC很复杂,但有一个好的 指南记录,不用担心.
一个轻微的下方(如果你可以称之为)到OAuth 2,是它必须发生在加密连接上.如果您的用例不能保证通过SSL或(最好)TLS加密,那么您应该使用OAuth 1.0(WITH revision A).
这是因为OAuth 2.0在请求中公开了它的"秘密"令牌,而OAuth 1.0只使用它来提供签名哈希.如果您采用这种方式,建议使用其他人的库,因为哈希是非常具体的.
(注意:接受答案后添加此部分)
我最近一直在探索的一个系统是Json Web Tokens.这些存储有关用户的信息,以便在数据库中重复查找每台计算机.因为令牌是使用秘密进行哈希处理的,所以您可以确定,只要您的秘密未公开,有效令牌就代表成功登录的用户,而无需触及数据库.
如果可能的话,你应该避免在代币中加入过于个人化的东西.如果您必须在令牌中存储私人或秘密信息,您可以对其进行加密,或者您可以使用反向缓存代理来交换JWT以获取传统安全令牌.这可能最初似乎打败了目的,但这意味着您的一些服务可能根本不需要数据库访问.