金字塔/wsgi os.environ 后门的安全隐患？答案

【问题标题】：Security implications of a pyramid/wsgi os.environ backdoor?金字塔/wsgi os.environ 后门的安全隐患？
【发布时间】：2017-12-20 03:30:21
【问题描述】：

在我的金字塔应用程序中，能够以任何用户身份登录（用于测试/调试，而不是在生产中）很有用。我的正常登录过程只是对哈希密码进行简单的 bcrypt 检查。

当复制用户提交的错误报告时，我发现克隆 sqlite 数据库并运行一个简单的脚本来将每个人的密码更改为固定字符串（仅用于本地测试）很有用。现在我正在切换到不太方便的 postgresql，并且我正在考虑为我的登录功能安装一个后门。

基本上，我希望检查 os.environ（从 apache 通过 mod_wsgi 加载的 debug.wsgi 文件中设置）中的特定变量“debug”。如果存在，那么我将允许使用任何密码（对于任何用户）登录，绕过密码检查。

这有什么安全隐患？据我了解，wsgi 文件是在 apache 加载时获取一次，所以如果 production.wsgi 文件没有设置那个特定的变量，那么攻击者（或不称职的用户）欺骗它的可能性有多大？

【问题讨论】：

您应该将其命名为 ALLOW_LOGIN_WITH_EMPTY_PASSWORD 之类的明确名称，然后在它处于活动状态时禁止使用正确的密码登录……尽管我不确定这是如何完成任何事情的，因为您需要克隆数据库无论如何，一旦你有了它，设置密码就像使用 SQLite 一样简单。（并且很可能在您获得副本之前通过自动化流程删除任何其他敏感信息。）
谢谢，但这并不能真正直接解决安全隐患。
嗯，它通过建议更具体的命名来解决您的“无能用户”场景。 “攻击者”一开始就没有任何意义。
内部命名如何影响不称职的用户场景（除非您指的是未来可能的开发者作为用户）？请您解释一下为什么“攻击者”没有任何意义，因为这对我来说并不是很清楚”
未来可能作为用户的开发者，是的。你还有什么意思？远程用户无法控制您的环境变量（包括攻击者）。

【解决方案1】：

为了在环境中使用该调试功能实例化服务器应用程序，攻击者必须交出您的网络服务器，很可能具有管理权限。

从外部进程，攻击者无法修改加载到内存中的运行服务器的环境，至少没有调试功能和用于重写内存的良好负载。重新加载服务器或尝试在其中执行脚本会更容易。

我认为你走的路是安全的。如果您偏执，请确保将后门从构建隔离（删除）到生产。

【讨论】：