Django RCE漏洞分析与防御指南<\/h1>

0x00 前言<\/h2>
Django作为一款高安全性框架，历史上很少出现无条件直接利用的RCE漏洞。本文详细分析两种因配置不当导致的Django RCE漏洞：CVE-2014-0472历史漏洞和FileBasedCache新型RCE利用方法。<\/p>

0x01 CVE-2014-0472漏洞分析<\/h2>

漏洞描述<\/h3>
2014年发现的漏洞，位于`django\/core\/urlresolvers.py<\/code>(现为django\/url\/resolvers.py<\/code>)中的reverse<\/code>函数过滤不当，导致可以任意获取内部函数，当攻击者知道代码内部存在恶意模块时，可导致任意代码执行。<\/p>`

漏洞原理<\/h3>

reverse<\/code>函数用于URL反向解析，根据视图名称查找对应URL<\/li>
漏洞点在于get_callable<\/code>函数中未对传入的函数名进行充分过滤<\/li>
关键危险代码：lookup_view = getattr(import_module(mod_name), func_name)<\/code><\/li>
当传入不可调用函数名时，会直接通过getattr<\/code>调用该函数<\/li>
<\/ol>
漏洞利用条件<\/h3>

存在使用redirect<\/code>或reverse<\/code>函数且参数可控的视图<\/li>
攻击者知道项目内部存在的恶意引用<\/li>
<\/ol>
典型漏洞代码示例<\/h3>
def<\/span> redirect_test<\/span>(request):
<\/span><\/span>    page =<\/span> request.<\/span>GET.<\/span>get('page'<\/span>, None<\/span>)
<\/span><\/span>    if<\/span> page is<\/span> not<\/span> None<\/span>:
<\/span><\/span>        redirect(page)  # 危险：直接使用用户输入作为redirect参数<\/span>
<\/span><\/span>    return<\/span> HttpResponse("OK"<\/span>)
<\/span><\/span><\/code><\/pre>漏洞复现步骤<\/h3>

构造恶意请求：http:\/\/example.com\/example?page=os.system<\/code><\/li>
Django会尝试调用os.system<\/code>函数<\/li>
如果知道项目内部使用的恶意模块，可进一步利用<\/li>
<\/ol>
官方修复<\/h3>

增加了对传入reverse<\/code>函数内部功能的检查<\/li>
检查方法是否存在于URL路由表中<\/li>
补丁地址：https:\/\/github.com\/django\/django\/commit\/8b93b31487d6d3b0fcbbd0498991ea0db9088054<\/li>
<\/ol>
0x02 FileBasedCache RCE漏洞<\/h2>
漏洞描述<\/h3>
Django的缓存配置错误可能引发RCE，特别是使用FileBasedCache时，由于直接使用pickle反序列化缓存文件，攻击者可构造恶意序列化数据实现代码执行。<\/p>
漏洞原理<\/h3>

FileBasedCache使用pickle进行序列化\/反序列化<\/li>
关键危险代码：

pickle.loads(zlib.decompress(f.read()))<\/code> (get方法)<\/li>
pickle.load(f)<\/code> (_is_expired方法)<\/li>
<\/ul>
<\/li>
无任何过滤直接反序列化用户可控的缓存文件<\/li>
<\/ol>
漏洞利用条件<\/h3>

知道缓存文件存储位置(通常为\/var\/tmp\/django_cache<\/code>或c:\/foo\/bar<\/code>)<\/li>
知道缓存文件命名规则<\/li>
有权限写入缓存目录(通过其他服务或文件上传)<\/li>
<\/ol>
缓存文件命名规则<\/h3>

GET方式：
md5("<prefix>:version:views.decorators.cache.cache_page.<prefix>.GET.<全局url的md5>.d41d8cd98f00b204e9800998ecf8427e.<时间区域>") + ".djcache"
<\/code><\/pre>
<\/li>
HEAD方式：
md5("<prefix>:version:views.decorators.cache.cache_page.<prefix>.HEAD.<全局url的md5>.d41d8cd98f00b204e9800998ecf8427e.<时间区域>") + ".djcache"
<\/code><\/pre>
<\/li>
<\/ol>
利用场景<\/h3>


多服务共享临时目录<\/strong>：<\/p>

Django默认缓存权限700<\/li>
但若nginx\/apache运行多个服务，其他服务可能有权写入<\/li>
<\/ul>
<\/li>

错误配置缓存位置<\/strong>：<\/p>

将CACHE_LOCATION配置在MEDIA_ROOT子目录<\/li>
通过文件上传覆盖缓存文件<\/li>
注意：FileField不会覆盖已有文件，但可上传HEAD类型缓存<\/li>
<\/ul>
<\/li>

敏感信息泄露<\/strong>：<\/p>

过期缓存未被删除<\/li>
可能泄露之前视图的响应内容<\/li>
<\/ul>
<\/li>
<\/ol>
漏洞复现步骤<\/h3>

确定缓存位置(检查settings.py中的CACHE_LOCATION)<\/li>
根据URL计算缓存文件名<\/li>
构造恶意pickle序列化数据写入缓存文件<\/li>
访问对应URL触发反序列化<\/li>
<\/ol>
缓存内容读取示例代码<\/h3>
import<\/span> pickle
<\/span><\/span>import<\/span> zlib
<\/span><\/span>import<\/span> sys
<\/span><\/span>
<\/span><\/span>def<\/span> readcachecontent<\/span>(filename):
<\/span><\/span>    f =<\/span> open(filename, "rb"<\/span>)
<\/span><\/span>    pickle.<\/span>load(f)
<\/span><\/span>    previous_value =<\/span> pickle.<\/span>loads(zlib.<\/span>decompress(f.<\/span>read()))
<\/span><\/span>    f.<\/span>close()
<\/span><\/span>    print("Content:"<\/span>)
<\/span><\/span>    print(previous_value.<\/span>content)
<\/span><\/span>
<\/span><\/span>if<\/span> __name__ ==<\/span> '__main__'<\/span>:
<\/span><\/span>    filename =<\/span> sys.<\/span>argv[1<\/span>]
<\/span><\/span>    readcachecontent(filename)
<\/span><\/span><\/code><\/pre>0x03 防御措施<\/h2>
针对CVE-2014-0472<\/h3>

升级到已修复版本<\/li>
避免直接使用用户输入作为redirect<\/code>或reverse<\/code>参数<\/li>
对传入参数进行严格过滤<\/li>
<\/ol>
针对FileBasedCache RCE<\/h3>


官方修复<\/strong>：<\/p>

在manage.py的check方法中增加对MEDIA_ROOT、STATIC_ROOT和STATICFILES_DIRS的检查<\/li>
警告CACHE_LOCATION不应位于这三个路径下<\/li>
补丁地址：https:\/\/github.com\/django\/django\/commit\/c36075ac1dddfa986340b1a5e15fe48833322372<\/li>
<\/ul>
<\/li>

配置建议<\/strong>：<\/p>

使用key_prefix<\/code>参数混淆缓存文件名：
@cache_page<\/span>(60<\/span> *<\/span> 60<\/span>, key_prefix=<\/span>"obfuscating_cache"<\/span>)
<\/span><\/span><\/code><\/pre><\/li>
设置严格的缓存目录权限<\/li>
避免使用默认缓存位置<\/li>
<\/ul>
<\/li>

替代方案<\/strong>：<\/p>

考虑使用其他缓存后端如Memcached或Redis<\/li>
定期清理过期缓存文件<\/li>
<\/ul>
<\/li>
<\/ol>
0x04 总结<\/h2>

Django虽然安全性高，但配置不当仍可能导致严重漏洞<\/li>
历史漏洞CVE-2014-0472展示了URL反向解析的风险<\/li>
FileBasedCache的pickle反序列化是新型RCE利用点<\/li>
防御关键在于严格过滤输入和合理配置缓存<\/li>
遵循最小权限原则和安全配置指南可有效降低风险<\/li>
<\/ol>

Django RCE漏洞分析与防御指南<\/h1>

0x00 前言<\/h2> Django作为一款高安全性框架，历史上很少出现无条件直接利用的RCE漏洞。本文详细分析两种因配置不当导致的Django RCE漏洞：CVE-2014-0472历史漏洞和FileBasedCache新型RCE利用方法。<\/p>

0x01 CVE-2014-0472漏洞分析<\/h2>

漏洞描述<\/h3> 2014年发现的漏洞，位于django\/core\/urlresolvers.py<\/code>(现为django\/url\/resolvers.py<\/code>)中的reverse<\/code>函数过滤不当，导致可以任意获取内部函数，当攻击者知道代码内部存在恶意模块时，可导致任意代码执行。<\/p>

0x02 FileBasedCache RCE漏洞<\/h2>

漏洞描述<\/h3> Django的缓存配置错误可能引发RCE，特别是使用FileBasedCache时，由于直接使用pickle反序列化缓存文件，攻击者可构造恶意序列化数据实现代码执行。<\/p>

0x03 防御措施<\/h2>

0x00 前言<\/h2>
Django作为一款高安全性框架，历史上很少出现无条件直接利用的RCE漏洞。本文详细分析两种因配置不当导致的Django RCE漏洞：CVE-2014-0472历史漏洞和FileBasedCache新型RCE利用方法。<\/p>

漏洞描述<\/h3>
Django的缓存配置错误可能引发RCE，特别是使用FileBasedCache时，由于直接使用pickle反序列化缓存文件，攻击者可构造恶意序列化数据实现代码执行。<\/p>