3

我开发了一项服务 (Service)，它可以自动执行用户可以在另一个第三方站点 (3rd Party Site) 上执行的某些操作。

我的服务为用户提供以下功能：

  • 用户在服务中注册

    1. 用户向服务提供他/她的第 3 方站点用户名/密码
    2. 服务使用该凭据代表用户登录到第 3 方站点
    3. 该服务将由第 3 方网站发布的 cookie 存储在其数据库中
    4. 从现在开始，服务开始使用之前存储的cookie（第三方站点的用户名/密码没有保存在任何地方）代表用户定期（cron）登录到第三方站点，并对第三方站点执行一些操作。代表第 3 方网站的用户

用例图

笔记：

  • 在注册服务之前，会向用户提供描述服务与第 3 方网站之间交互的完整信息
  • 自动化用户登录到第 3 方站点具有一定的价值，并且用户有兴趣在第 3 方站点上自动登录和执行某些操作，即他们有兴趣在第 3 方站点上为他们做一些工作的服务
  • 第 3 方站点上没有 OAuth 功能
  • 第 3 方站点上没有任何用户身份验证令牌功能

我在 Stack Exchange 进行了研究，但没有找到任何解决方案：

此外，通过阅读提供的问题和答案，我倾向于认为没有办法保护用户的登录数据（密码或 3rd Party Site cookie）。即，如果攻击者获得对服务服务器的访问权，则攻击者也获得对第三方站点上用户帐户的访问权。

如果我尝试将第 3 方站点的 cookie 存储在加密的服务数据库中，那么它们将仅对解密它们的脚本有用。因此，要访问第 3 方站点用户帐户，攻击者不仅需要访问服务的机器，还需要修改脚本（步骤 4）。

在服务上为第 3 方站点存储 cookie 与 OAuth 非常相似，但在这种情况下使用 cookie 而不是令牌（不存储密码）。

设计安全模型/架构以将用户的登录数据安全地存储在服务中以允许服务定期代表用户登录到第三方站点而无需与用户进行手动交互的方式是什么？

PS我使用Django，但我猜安全模型/架构不依赖于某个技术栈。

4

2 回答 2

3

显而易见：这里重要的事情当然是不要让您网站上的攻击者访问所有 cookie。您无法完全避免这种情况，因为您的服务需要定期访问 cookie（未加密形式）。一个完全破坏了你的服务器的攻击者理论上可以做你的服务可以做的任何事情，所以如果你的服务可以访问 cookie，那么拥有所有权限的攻击者也将能够访问他们。

如果你仍然想这样做，你应该

1) 使攻击者更难访问 cookie

举个例子说明如何思考这个问题：如果您的系统遭到入侵，攻击者很可能会访问您的文件系统。如果 cookie 以纯文本形式存储在文件中，那么攻击者就会很轻松。将它们存储在数据库中会更好（并且可能无论如何您都想做），但除非您以某种方式保护对数据库的访问，否则不会更好。如果数据库的密码存储在应用程序配置文件中，那么专门的攻击者将不会遇到困难。

一个可以大大改善这种情况的解决方案是，如果 cookie 总是被加密，除非你需要它们。最好的解决方案是，如果加密密钥没有存储在应用程序日志中，而是由操作员在每次重新启动服务器时提供（输入）。为了打破这一点，攻击者必须读取应用程序的内存（并非不可能，但仍然更加困难）。

另一种措施是将 cookie 存储在专用服务器上的单独数据库中，并将对该服务器的所有访问限制为所需的内容。

一个完整的策略需要更深入地了解您的确切物理和逻辑设置。

2) 创建机制，以便您可以检测 cookie 是否被泄露

这几乎同样重要。如果发生这种情况，您想知道并能够立即采取行动。当然也有可以使用的标准 IDS 系统。您还可以创建适用于您的特定应用程序的更有针对性的系统。系统可以即检测是否有人正在运行使用cookies 扫描整个数据库表的sql。由于您知道自己的应用程序的正常行为方式，因此您还可以创建一个监控系统来检测是否发生了不正常的事情。

3）准备一个系统，以便在您检测到它们被盗时快速使所有 cookie 失效

第三方服务可能确实可以选择注销并使 cookie 无效。您应该为您可以轻松激活的所有存储的 cookie 准备一个执行此操作的作业。想想在您禁用所有 cookie 之前告诉您的用户有人可能在 10 分钟内访问了他们的服务和告诉他们有人仍然可以访问第三方服务并且您不知道如何阻止他们的区别。

除此之外，您的用户了解他们在授予您访问权限时所做的事情以及第三方服务提供商对此的批准当然很重要。第三方服务提供商是否会允许这种访问并不明显。如果他们这样做，他们还可以帮助您创建一个特殊的会话 cookie，即绑定到您的 IP 地址。

于 2013-09-12T21:08:35.373 回答
2

您的问题似乎专门询问如何“安全地存储”凭证信息，所以让我先解决这个问题的狭隘方面。

安全存储凭证信息

唯一要存储的信息是cookie，它是以明文形式获取的，以后需要以明文形式使用。这使您别无选择，只能使用某种“秘密”来使用双向加密。为了使方案安全，您只需要保护您的“秘密”，最好将其嵌入到编译可执行模块中（例如，使用像 Java 这样的编译语言）。这样，即使攻击者获得了对您整个机器的访问权限，他/她也无法解码 cookie，除非运行您的程序并使用编译程序中内置的逻辑使用解码后的 cookie。

整体架构考虑

如果问题是关于整体架构，但没有 OAuth 或某些类型的令牌支持，那么您的机制将不可靠。因为“服务”会使 cookie 过期，并且您需要不断地使用 cookie 来访问服务，并说服“服务”永远不会使您的会话过期（因此是 cookie）。即使您在几小时或几天后这样做，或者当“服务”重新启动时，您的 cookie 也将不再有效，并且您的访问将被拒绝。

于 2013-09-14T23:47:17.483 回答