渗透django

凌晨两点，渗透我盯着终端里那行403 Forbidden，渗透咖啡杯沿的渗透指纹已经干了三遍。Django的渗透admin后台像块铁板，密码策略严得吓人——八位以上，渗透必须混大小写和符号，渗透连续错五次就锁十五分钟。渗透可真正让我后背发凉的渗透，是渗透登录页返回的Set-Cookie字段里，那个没打HttpOnly标记的渗透sessionid。

多数人以为Django安全，渗透是渗透因为它自带ORM和CSRF防护。但框架只是渗透把门锁换了把更粗的，窗户照样开着。渗透我见过某电商平台，渗透所有API的@csrf_exempt装饰器像牛皮癣一样贴在视图函数上，注释写着“为了对接第三方回调”。结果呢？攻击者伪造一个带管理员cookie的POST请求，直接改了商品价格。

真正有意思的是Django的错误页面。调试模式开着的时候，DEBUG=True会把完整的settings.py路径、数据库连接参数、甚至本地文件目录全吐在浏览器上。有个老哥用Django写了个内部工具，部署到公网忘了关调试，结果攻击者顺着/static/目录的报错信息，一层层扒出项目根目录，最后把SECRET_KEY从环境变量里钓了出来——那玩意儿能反序列化session，等于拿到了所有用户的登录态。

别急着嘲笑。你去GitHub上搜SECRET_KEY =，能搜出上万条硬编码在源码里的Django项目。有人觉得“反正内网用”，有人觉得“改配置太麻烦”，可一旦代码泄露到公开仓库，攻击者拿这个key就能伪造任意session。我做过测试，用Django的signing.loads方法，配合泄露的key，十分钟内就能伪造出一个is_superuser=True的会话。

模板注入是另一个被低估的入口。Django模板语言默认转义变量，可很多人会在模板里写|safe过滤器，或者用mark_safe()处理富文本。有个博客系统就这么破的——作者允许用户提交自定义HTML模板，没做白名单校验，攻击者在模板里塞了{ % load static %}，然后通过{ % include %}标签读取了服务器上的/etc/passwd。Django的模板引擎本来可以阻止这种操作，但{ % include %}配合动态路径变量时，会绕过部分沙箱限制。

说到文件上传，Django的FileField默认只校验Content-Type头，而那个头是客户端随便改的。我见过有人上传了一个.txt文件，里面全是PHP代码，然后通过路径穿越把文件名改成shell.php%00.txt——老式服务器解析漏洞。更阴的是，Django的MEDIA_ROOT如果配置在web根目录下，攻击者上传一个带.html的SVG文件，里面嵌着JavaScript，直接就能在用户浏览器里执行存储型XSS。

最后说个冷门的。Django的cache框架，默认用本地内存或数据库缓存。如果你用Redis做缓存，又忘了设密码，攻击者连上去执行FLUSHALL，所有session和缓存数据瞬间清空——用户全被踢下线，管理员也进不去。更骚的是，有些Django项目把cache_page装饰器用在动态页面上，缓存键里带着用户ID，攻击者通过构造不同ID就能遍历其他用户的缓存数据。

写这些不是劝你弃用Django，而是想说：框架的安全承诺只到“默认配置”为止。你得亲手关掉调试模式，把SECRET_KEY放进环境变量，给session cookie加上HttpOnly和Secure标记，用白名单校验上传文件，对模板变量做二次转义。别信“Django很安全”这种鬼话——它只是把常见坑填了，剩下的坑得你自己绕着走。

我后来把那个403的页面扒到底，发现是WAF拦截了SQL注入尝试。但真正让我睡不着的是：如果那天攻击者换个思路，不走注入，而是去翻/admin/login/的响应头，发现Django版本号，再去查对应CVE——我得承认，我连django.middleware.security.SecurityMiddleware都没启用。