用户使用默认的Laravel身份验证登录，该身份验证将加密的cookie放入浏览器，并将会话保存在数据库中。
用户移动到经典的asp页面，在那里我检查cookie值，获取哈希值，然后调用laravel app返回传递会话ID哈希。
然后我在laravel中使用它来查看该id是否存在活动会话，如果是，则返回true，因此用户可以使用经典asp登录。
在经典应用程序中的每个页面请求中，我检查数据库中的last_updated_time并在每个页面上更新它。所有登录和注销都在laravel中完成，而classic依赖于数据库来查看会话是否处于活动状态。
我还会调用一个公共URL来获取会话变量并使用laravel添加会话变量，因为它都是加密的并且使用经典的asp会很难。
我看到的唯一风险是会话劫持，但我认为风险并不高于平时。
锁定我调用的laravel URL以检查它是否是有效的会话是否很重要？
我在这里错过了一个安全漏洞吗？
答案 0 :(得分：7)
根据您的陈述，可能没有打开任何安全漏洞。会话cookie本身并不在用户计算机上加密，但您确保它们在您的计算机和您的计算机之间以及每台计算机之间进行加密。您应确保已设置Secure Flag以帮助防止Cookie被意外通过传统的未加密传输（HTTP）发送，但如上所述，这并不会影响存储Cookie本身。
话虽如此，你实际上是在劫持你自己的用户会话。虽然现在可能没有引入 的漏洞，但您可能会削弱整个系统，这可能导致未来出现漏洞。
这可能是一个愚蠢的问题，但你确定你需要会话吗？如果您在服务器之间处理凭据，则听起来更像是要使用Access Tokens并废弃会话。
使用访问令牌类似于使用会话，但您需要使您的服务无状态。这意味着您不再存储有关已登录用户的任何特定计算机的信息，因此您每次访问需要该信息的服务器时都需要从数据库中提取所需内容。
从长远来看，这是一件好事，因为当您不必担心会话的内容以及会议内容时，您可以更轻松地扩展服务。
OAuth 2.0是广泛使用的标准版（Facebook，Twitter，Google），专门设计为易于使用。 RFC很复杂，但有good guides的日志，不用担心。
对于OAuth 2，一个轻微的下降（如果你可以称之为），它必须通过加密连接发生。如果您的用例无法保证通过SSL或（最好）TLS加密，那么您应该使用OAuth 1.0（WITH revision A）代替。
这是因为OAuth 2.0暴露了它的秘密＆＃34;请求中的令牌，其中OAuth 1.0仅使用它来提供签名哈希。如果您采用这种方式，建议使用其他人的库，因为哈希非常具体。
（注：接受答案后添加此部分）
我最近一直在探索的一个系统是Json Web Tokens。这些存储有关用户的信息，以便在数据库中重复查找每台计算机。因为令牌是用秘密进行哈希处理的，所以只要你的秘密没有公开，你就可以确定，有效令牌代表一个成功登录的用户，而不必触及数据库。
如果可能的话，你应该避免在代币中加入过于个人化的东西。如果您必须在令牌中存储私人或秘密信息，您可以对其进行加密，或者您可以使用反向缓存代理来交换JWT以获取传统安全令牌。这可能最初似乎打败了目的，但这意味着您的一些服务可能根本不需要数据库访问。
答案 1 :(得分：0)
我不是安全专家，但我没有看到这个问题。打包的Laravel数据库会话处理程序以相同的方式工作。 cookie包含引用数据库中记录的哈希。会话数据是base64编码的，但既不是在这里也不是在那里。我认为你实际上可以避免使用Laravel的DatabaseSessionHandler。
Illuminate/Session/DatabaseSessionHandler
...我只是更深入地阅读了您的问题，并注意到有关设置和检索会话数据的公共URL的部分。我认为这是一个非常糟糕的主意。主要是因为它将为最终用户提供打开的大门，允许他们读取和写入会话数据。这只能结束。
就像我上面所说的那样，数据只是 base64编码所以我相信你能够在asp内解析，读写这些内容。
修改
好的......我认为这是最后一次编辑。数据是php序列化然后base64编码。这question看起来可能会帮助您实现这一目标。如果没有，并且API端点是唯一的方法，那么找一些阻止最终用户访问它的方法。
答案 2 :(得分：0)
除会话劫持外，没有。这是应用程序在内部交互的标准方式。当然，如果您选择除数据库以外的其他类型的会话存储，例如Memcached，则可能有更好的方法来获取数据。
答案 3 :(得分：0)
有几件事可以做。
如果您需要更多信息，请与我们联系。