会话集成，这种方法安全吗？答案

【问题标题】：Session integration, is this approach secure?会话集成，这种方法安全吗？
【发布时间】：2015-04-10 15:27:56
【问题描述】：

用户使用默认的 Laravel 身份验证登录，该身份验证将加密的 cookie 放入浏览器，并将会话保存在数据库中。

用户转到一个经典的 asp 页面，在那里我检查 cookie 值，获取哈希值，然后通过会话 id 哈希值调用 laravel 应用程序。

然后我在 laravel 中使用它来查看该 id 是否存在活动会话，如果是，我返回 true，以便用户可以在经典 asp 中登录。

在经典应用程序中的每个页面请求上，我都会检查数据库中的 last_updated_time 并在每个页面上更新它。所有登录和注销都是在 laravel 中完成的，classic 依赖数据库来查看会话是否处于活动状态。

我还会调用一个公共 url 来获取会话变量并使用 laravel 添加会话变量，因为它都是加密的，并且为此使用经典的 asp 会很困难。

我看到的唯一风险是会话劫持，但我认为它的风险并不比平时高。

锁定我调用的 laravel URL 是否重要以检查它是否是有效会话？

我错过了这里的安全漏洞吗？

【问题讨论】：

您是否在任何地方都使用 HTTPS，没有混合内容，使用 HSTS，并且在您的 cookie 上使用 HttpOnly=1 和 Secure=1？ :)

标签： php security laravel asp-classic

【解决方案1】：

这种方法安全吗？

根据您的说法，您可能没有打开任何安全漏洞。会话 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 在请求中公开了它的“秘密”令牌，而 OAuth 1.0 只使用它来提供签名哈希。如果您采用这种方式，建议使用其他人的库，因为哈希非常具体。

进一步改进

（注：此部分是在回答被接受后添加的）

我最近一直在探索的一个系统是Json Web Tokens。这些存储有关用户的信息，以保存每台机器在数据库中反复查找。因为令牌是用一个秘密进行散列的，所以您可以确定，只要您的秘密没有暴露，一个有效的令牌就代表一个成功登录的用户，而无需接触数据库。

如果可能，您应该避免在令牌中添加任何过于个人化的内容。如果您必须在令牌中存储私有或机密信息，您可以对其进行加密，或者您可以使用反向缓存代理将 JWT 交换为传统的安全令牌。这可能最初似乎违背了目的，但这意味着您的某些服务可能根本不需要数据库访问。

【讨论】：

【解决方案2】：

我不是安全专家，但我认为这没有问题。打包的 Laravel 数据库会话处理程序的工作方式相同。 cookie 包含引用数据库中记录的哈希值。会话数据是 base64 编码的，但这既不是这里也不是那里。我认为您实际上可以避免自己滚动，而只需使用 Laravel 的 DatabaseSessionHandler。

Illuminate/Session/DatabaseSessionHandler

...我只是更深入地阅读了您的问题，并注意到有关用于设置和检索会话数据的公共 URL 的部分。我认为这是一个非常糟糕的主意。主要是因为它将为最终用户提供一扇敞开的大门，允许他们读取和写入会话数据。这只能以糟糕的方式结束。

就像我上面说的，数据是仅 base64 编码的，所以我相信您将能够在 asp 中解析、读取和写入您心中的内容。

编辑

好的...我认为这是最后一次编辑。数据经过 php 序列化，然后进行 base64 编码。这个question 看起来可以帮助你达到这个目的。如果没有，并且 API 端点是唯一的方法，请找到一些方法来阻止最终用户访问它。

【讨论】：

如果真的序列化了，我担心的是PHP对象注入是可能的。

【解决方案3】：

除了会话劫持之外，没有。这是应用程序在内部进行交互的标准方式。当然，如果您选择数据库以外的不同类型的会话存储（例如 Memcached），可能会有更好的方法来获取数据。

【讨论】：

【解决方案4】：

有几件事可以做。

将通道设为 HTTPS。几乎不可能嗅探您的传输层。
您可以使用JWT 来完成此任务，而不是与您的cookie 进行交互。这将帮助您在连接 ASP 系统的同时使用系统中的现有功能。您可以编写一个允许 ASP 连接的小型 REST Web 服务。你可以使用这个lib。你可以参考this article，它会让你知道应该如何做。

如果您需要更多信息，请告诉我。

【讨论】：

我不认为 HTTPS 可以防止攻击者在他们的机器上运行客户端并使用调试代理查看数据流量。我仍然喜欢无处不在的 HTTPS，我只是认为它不能像你所说的那样保护嗅探。
https 为传输层添加了加密。