我开发了一项服务 (Service)，它可以自动执行用户可以在另一个第三方站点 (3rd Party Site) 上执行的某些操作。
我的服务为用户提供以下功能:
笔记:
我在 Stack Exchange 进行了研究，但没有找到任何解决方案:
此外，通过阅读提供的问题和答案，我倾向于认为没有办法保护用户的登录数据(密码或 3rd Party Site cookie)。 IE。如果攻击者获得对服务服务器的访问权限，则攻击者也获得对第三方站点上用户帐户的访问权限。
如果我尝试将第 3 方站点的 cookie 存储在加密的服务数据库中，那么它们将仅对解密它们的脚本有用。因此，要访问第 3 方站点用户帐户，攻击者不仅需要访问服务的机器，还需要修改脚本(步骤 4)。
在服务上为第 3 方站点存储 cookie 与 OAuth 非常相似，但在这种情况下使用 cookie 而不是 token (不存储密码)。
设计安全模型/架构以在服务中安全存储用户登录数据以允许服务定期代表用户登录第三方站点而无需与用户进行手动交互的方式是什么？
附言我使用 Django，但我想安全模型/架构不依赖于某个技术堆栈。
最佳答案
显而易见:这里重要的事情当然是不要让您网站上的攻击者访问所有 cookie。您无法完全避免这种情况，因为您的服务需要定期访问 cookie(未加密形式)。一个完全破坏了你的服务器的攻击者理论上可以做你的服务可以做的任何事情，所以如果你的服务可以访问 cookie，那么拥有所有权限的攻击者也将能够访问他们。
如果你仍然想这样做，你应该
1) 使攻击者更难访问 cookie
举个例子说明如何思考这个问题:如果您的系统遭到入侵，攻击者很可能会访问您的文件系统。如果 cookie 以纯文本形式存储在文件中，那么攻击者就会很轻松。将它们存储在数据库中会更好(并且可能无论如何您都想做)，但除非您以某种方式保护对数据库的访问，否则不会更好。如果数据库的密码存储在应用程序配置文件中，那么专门的攻击者将不会遇到困难。
一个可以大大改善这种情况的解决方案是，如果 cookie 总是被加密，除非你需要它们。最好的解决方案是，如果加密 key 没有存储在应用程序日志中，而是由运算符(operator)在每次重新启动服务器时提供(输入)。为了打破这一点，攻击者必须读取应用程序的内存(并非不可能，但仍然更加困难)。
另一种措施是将 cookie 存储在专用服务器上的单独数据库中，并将对该服务器的所有访问限制为所需的内容。
一个完整的策略需要更深入地了解您的确切物理和逻辑设置。
2) 创建机制，以便您可以检测 cookie 是否被泄露
这几乎同样重要。如果发生这种情况，您想知道并能够立即采取行动。当然也有可以使用的标准 IDS 系统。您还可以创建适用于您的特定应用程序的更有针对性的系统。系统可以即检测是否有人正在运行使用 cookie 扫描整个数据库表的 sql。由于您知道自己的应用程序的正常行为方式，因此您还可以创建一个监控系统来检测是否发生了不正常的事情。
3) 准备一个系统，以便在检测到所有 cookie 被盗时快速失效
第三方服务可能确实可以选择注销并使 cookie 无效。您应该为您可以轻松激活的所有存储的 cookie 准备一个执行此操作的作业。想想在您禁用所有 cookie 之前告诉您的用户有人可能在 10 分钟内访问了他们的服务和告诉他们有人仍然可以访问第三方服务并且您不知道如何阻止他们的区别。
除此之外，您的用户了解他们在授予您访问权限时所做的事情以及第三方服务提供商对此的批准当然很重要。第三方服务提供商是否会允许这种访问并不明显。如果他们这样做了，他们还可以帮助您创建一个特殊的 session cookie，即绑定(bind)到您的 IP 地址。
关于安全模型 : log in to third-party site with user's credentials，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18595611/