Django debug调试模式漏洞：一个回车键就能让你裸奔

把`DEBUG = True`留在生产环境，调洞等于把服务器密码贴在键盘底下。试模式漏这不是调洞危言耸听。2019年某知名电商平台因此泄露了完整数据库配置，试模式漏攻击者连密码都没猜，调洞只是试模式漏访问了一个不存在的URL。

Django的调洞debug模式会打开一扇后门——错误页面。正常情况下，试模式漏404页面只显示“页面不存在”。调洞但在debug模式下，试模式漏页面底部会吐出一整套调试工具栏：所有settings配置、调洞数据库连接串、试模式漏环境变量、调洞甚至本地文件路径。试模式漏这些信息不是调洞给管理员看的，是给攻击者看的。

举个真实案例。某创业公司用Django写API，员工图省事，部署时没关debug。结果攻击者访问`/api/v1/orders/999999/`，触发一个不存在的订单查询。错误页面直接暴露了`DATABASES`字典，里面躺着生产库的密码。更绝的是，页面还提供“局部变量”面板，能直接看到SQL查询语句和ORM内部逻辑。攻击者顺着这条线索，用泄露的账号密码登录了后台，把订单数据全拖走了。

这还不是最恐怖的。debug模式下的错误页面支持“交互式调试”——如果你装了`django-extensions`，页面会嵌入一个Python shell。攻击者可以执行任意代码，比如`import os; os.system('rm -rf /')`。这等于把服务器控制台直接递给陌生人。我见过一个测试环境，开发人员把debug开着，结果被爬虫扫到，对方在shell里输了一行`print(open('/etc/passwd').read())`，系统文件就裸奔了。

为什么有人会犯这种错？因为本地开发时debug太方便了，报错直接看堆栈，改完代码热重载。但部署时忘了改`settings.py`，或者图省事用`python manage.py runserver`直接跑生产——这命令本来就带debug，还自带单线程，并发一高就崩。更隐蔽的是，有些项目把`DEBUG`写死在环境变量里，但服务器上忘了设置，Django默认值又是`True`，于是静默开启了漏洞。

检测方法很简单。访问任意不存在的路径，比如`/test_debug_vuln/`，如果页面显示黄色背景的堆栈信息，带SQL查询和文件路径，那基本就中招了。更狠的是，Django在debug模式下还会把请求的`HTTP_HOST`头反射到页面里，攻击者用`curl -H "Host: evil.com"`就能看到自己的域名出现在错误信息中，确认漏洞存在。

修复手段不复杂。第一，部署前检查`settings.py`，确保`DEBUG = False`，最好用环境变量强制控制，比如`DEBUG = os.environ.get('DJANGO_DEBUG', 'False') == 'True'`。第二，关掉debug后，记得配置`ALLOWED_HOSTS`，否则Django会拒绝所有请求，报错“Invalid HTTP_HOST”。第三，如果确实需要查看线上错误，别开debug，用`logging`模块把异常记录到文件或日志服务，或者用Sentry这类工具。

最后说个反直觉的点——debug模式漏洞不只是泄露信息。攻击者可以利用错误页面里的“Request信息”面板，看到完整的Cookie和Session数据，伪造登录状态。我做过测试，用debug页面泄露的session key，直接替换到浏览器cookie里，就能冒充管理员身份，连密码都不用破。这比SQL注入还干脆。

别把调试工具当护身符。它是个随时可能走火的枪，对着自己还是对着别人，全看你的部署习惯。