uwsgi路径穿越漏洞怎么修复

去年冬天，径穿我帮一个做跨境电商的越漏朋友排查服务器异常。他的洞修uWSGI日志里出现了大量类似 /../../../../etc/passwd 的请求路径，当时他还没意识到这意味着什么。径穿直到我在他服务器上发现一个用于测试的越漏Flask应用，通过uWSGI的洞修 --static-map 配置暴露了系统文件，问题才浮出水面。径穿uWSGI路径穿越漏洞不是越漏新问题，但很多运维人员依然踩坑，洞修因为它的径穿触发条件往往藏在看似无关的配置里。

路径穿越的越漏本质是uWSGI在处理静态文件映射或 X-Sendfile 时，没有对URL中的洞修 .. 序列做足够严格的过滤。攻击者构造 /static/../../etc/shadow 这样的径穿请求，如果uWSGI直接拼接路径而未做规范化，越漏就会读取到Web根目录之外的洞修文件。更麻烦的是，有些场景下uWSGI会把请求交给后端应用，但自身已经先处理了路径解析，导致后端框架的防护形同虚设。

先确认你的uWSGI是否真的受影响

别急着改配置。打开终端，用curl发一个带穿越序列的请求，看响应码和内容。比如你的静态文件映射是 --static-map /static=/var/www/static，试试：

curl -v --path-as-is http://127.0.0.1:8000/static/../../../etc/hostname

注意 --path-as-is 参数，不加的话curl会自动规范化路径，测不出真实效果。如果返回了 /etc/hostname 的内容，或者状态码是200但内容明显不是静态资源，那基本可以确定存在漏洞。我见过有些uWSGI版本在遇到 .. 时会返回400，但换个编码方式比如 %2e%2e%2f 又能绕过，所以测试时要多试几种变形。

修复的核心思路：让uWSGI不再自己拼接路径

最直接的办法是升级uWSGI到最新版。官方在2.0.19之后对路径规范化做了加强，但别指望升级能解决所有问题——有些老项目的配置本身就在鼓励路径穿越。比如用 --static-map /static=. 这种相对路径映射，uWSGI会基于当前工作目录解析，攻击者很容易跳出。改成绝对路径，并且确保映射的目录里没有敏感文件。

如果你用Nginx做反向代理，把静态文件处理交给Nginx，uWSGI只负责动态请求。Nginx的 alias 和 root 指令对 .. 的处理比uWSGI严谨得多。配置大概这样：

location /static/ {  alias /var/www/static/; try_files $uri =404; } location / {  include uwsgi_params; uwsgi_pass 127.0.0.1:3031; }

这样uWSGI根本看不到 /static/ 开头的请求，路径穿越的入口直接被切断。我朋友那台服务器就是这么改的，改完之后再测 /static/../../etc/passwd，Nginx直接返回400。

那些容易忽略的配置项

--route 和 --route-run 如果写了文件读取逻辑，也可能被穿越。比如 --route = .* file:%(PATH_INFO) 这种，PATH_INFO里带 .. 就完蛋。检查你的uWSGI配置文件里有没有类似的正则路由。

还有 --check-static 和 --check-static-docroot，这两个选项会检查文件是否存在，但不会阻止路径穿越。有人以为开了check-static就安全了，其实它只是返回404而不是403，攻击者依然能通过响应时间或状态码差异判断文件是否存在。

Python应用的 X-Sendfile 头也要小心。如果后端返回 X-Sendfile: ../../etc/passwd，而uWSGI信任这个头，就会直接发送文件内容。确保你的应用层对用户输入做了路径规范化，用 os.path.realpath 检查最终路径是否在允许的目录内。

一个真实的绕过案例

某次渗透测试中，目标用了uWSGI 2.0.18，静态映射配置为 --static-map /media=/data/media。直接发 /media/../secret.txt 返回403。但把 .. 换成 ....//，uWSGI的过滤逻辑只替换了一次 ../，剩下的 ../ 依然生效。请求 /media/....//secret.txt 成功读取到文件。这个漏洞在2.0.19修复，但如果你还在用老版本，手动在Nginx层加一层 merge_slashes off 和路径重写规则也能缓解。

修复路径穿越没有一劳永逸的银弹。升级、隔离静态文件处理、审查路由配置、在应用层做路径校验，这几件事得一起做。我习惯在部署新服务时先跑一遍 dotdotpwn 这类工具扫一下，虽然误报多，但能快速发现明显的配置错误。别等日志里出现 /etc/passwd 才想起来检查。

本文地址：http://www.79wt.cn/news/869e9199039.html