为什么 Django 的 [ DEBUG=True] 对黑客来说是一座金矿

错误配置通常是安全环境中最薄弱的环节。Django 中最危险但最容易被忽视的错误配置之一是DEBUG=True在生产环境中出现错误配置。从攻击者的角度来看，这是侦察和利用的金矿。本文探讨了攻击者如何利用此设置以及他们可以从易受攻击的 Django 应用程序中检索的五种最有价值的数据类型。

DEBUG=True 在 Django 中起什么作用？

在 Django 中，该DEBUG设置控制在发生错误时是否显示调试信息（包括错误堆栈跟踪和详细请求信息）。使用DEBUG=True，Django 会输出包含敏感信息的详细错误页面，以便在开发过程中为开发人员提供帮助。

从攻击者的角度来看：

当攻击者发现 Django 网站正在运行 时DEBUG=True，就好像应用程序公开提供详细的内部信息来帮助他们策划攻击。这些详细的错误消息包含从服务器的环境变量到已安装的中间件甚至潜在的攻击入口点的所有内容。

攻击者如何识别具有 DEBUG=True 的 Django 站点

扫描网络上的易受攻击的站点

攻击者使用Shodan、FOFA和Censys等自动化工具在网络上搜索 Django 应用程序。这些工具允许攻击者搜索与 相关的特定错误消息和模式DEBUG=True。

实用方法：

FOFA查询：

“DEBUG=True” && “Django” && “RuntimeError”

这些搜索引擎会扫描互联网以查找开放的端口和服务，然后分析 HTTP 响应以查看它们是否包含已知的 Django 调试模式。利用这些搜索结果，攻击者可以使用 编制一份运行 Django 的易受攻击的网站列表DEBUG=True。

通过 Django 调试页面泄露数据

一旦DEBUG=True设置，攻击者就可以直接从调试页面获取有价值的信息。

实际数据检索：

完整堆栈跟踪：

堆栈跟踪提供了对代码如何执行、错误发生的位置以及请求和响应中可能暴露的变量的深入了解。

例子：

Traceback (most recent call last): File "/path/to/your/project/views.py"...

实际用途：攻击者可以识别代码执行路径并寻找处理输入的点，从而实现 SQL 注入或文件包含漏洞等有针对性的攻击。

请求和响应数据：

• 攻击者可以从请求和响应中了解 cookie、CSRF 令牌和标头。

• 实际用途：利用这些信息，攻击者可以执行会话劫持，窃取 CSRF 令牌或策划更有效的社会工程攻击。

Request Headers: { 'Cookie': 'sessionid=abcd1234; csrftoken=efgh5678...', 
                     'User-Agent': 'Mozilla/5.0...' }

已安装的应用程序和中间件：

Installed apps: ['django.contrib.admin', 'myapp', 'rest_framework'...]

实际用途：通过分析已安装的应用程序和中间件，攻击者可以识别易受攻击的第三方库或未修补的组件。

数据库和文件路径：

• 虽然数据库密码可能不会直接显示，但其他详细信息（如数据库引擎、文件路径和模式）通常会被暴露。

• 实际用途：攻击者可以利用数据库系统或文件系统中已知的漏洞，甚至找到暴露更多凭据或敏感数据的文件。

4. 利用 Django DEBUG=True 配置的实用方法

利用堆栈跟踪

一旦确定了存在漏洞的站点，下一步就是从堆栈跟踪中提取尽可能多的信息。这包括以下敏感细节：

• 文件路径：

File "/var/www/myapp/views.py" in render

文件路径为攻击者提供了有关服务器结构和敏感文件（配置文件、日志等）潜在位置的线索。

查看正在调用哪些函数和方法以及它们如何处理输入可以暴露 SQL 注入点、XSS 漏洞或逻辑缺陷。

CSRF 令牌滥用

如果攻击者可以检索 CSRF 令牌，他们就可以进行跨站点请求伪造攻击。如果令牌与活动会话绑定，攻击者可以：

• 代表用户执行未经授权的操作（例如，进行购买或转移资金）。

• 如果与被盗的会话 cookie 结合，则会劫持用户会话。

CSRF

数据库利用

攻击者可以从调试页面检索部分数据库配置（例如数据库类型和模式），并将其与其他已知漏洞结合起来，以：

• 执行 SQL 注入。

• 通过了解数据库查询的处理方式来绕过身份验证或提升权限。

攻击者可以从 DEBUG=True 中检索的前 5 个有价值的数据

SECRET_KEY：虽然 Django 试图在调试输出中隐藏此密钥，但有时可以通过间接方法或相关文件中的错误配置来检索。利用SECRET_KEY，攻击者可以：

• 生成伪造的会话令牌。

• 绕过身份验证机制。

数据库凭证：如果凭证管理不善，数据库引擎或模式的暴露可能会导致 SQL 注入或直接访问数据库。

CSRF 令牌：一旦 CSRF 令牌被暴露，攻击者就可以操纵用户会话来执行恶意操作或完全劫持会话。

会话 Cookie：如果会话 Cookie 在请求/响应数据中暴露，攻击者可以窃取活跃用户会话并冒充合法用户。

已安装的中间件和应用程序：通过了解安装了哪些中间件和第三方应用程序，攻击者可以利用这些软件包中的已知漏洞，尤其是在这些软件包已过时的情况下。

开发人员如何预防这些攻击

如您所见，留DEBUG=True在生产环境中会为攻击者提供大量敏感信息。为了防止此类问题：

• 始终处于DEBUG=False生产状态。

• 使用特定于环境的设置来确保错误消息中不会泄露任何敏感数据。

• 实施强大的日志记录实践，隐藏敏感数据，但仍提供有用的调试信息。

对于 Django 开发人员来说，保护应用程序免受此类错误配置对于防止攻击至关重要。