下划线引起的血案
最近公司搬迁,所有虚拟机都要重新部署,累死了。然后 Python 一堆依赖以前没管理好,直接装全局位置,也忘记导出一份版本号到新机器来安装。这是祸根
换到新机器后,Skynet 和 Golang 相关应用都跑起来了。但是 Python 写的内部应用有点问题,网站认证后,认证用户名 valid_username 一直传不到应用里。检查过内部 Oauth 的代码,以及 Nginx 的转发配置,都没有问题。最终通过重放请求定位到是 Gevent 丢掉了这个参数。同事帮忙翻了下 更新日志 ,发现因为安全问题,带下划线的变量不再传递了,参考 issue 819 和 issue 775
819 很简洁的引用了 waitress 库 以及 Django,Apache 和 Nginx 的安全更新日志 。原来,这是一个下划线和破折号自动转换引起的 WSGI header 欺骗攻击。在 WSGI 环境下,所有 HTTP 请求头会全部转换为大写字母,所有破折号转换成下划线,并添加 HTTP_ 前缀。例如,X-Auth-User 会转换成 HTTP_X_AUTH_USER
这意味着,WSGI 环境无法区分带有破折号的请求头和带有下划线的请求头。比如,为了防止访客伪造请求,我写了过滤规则,将客户端发来的 X-Auth-User 变量都干掉。但是,对方有可能发的是 X-Auth_User,最后依然可以转化成 HTTP_X_AUTH_USER,从而绕过安全认证
这个攻击是 CVE-2015-0219,为了防止这种攻击,各大框架都加上了过滤下划线请求头的功能。内部应用还是用的带下划线请求头,所以触礁了。。。也就是说,以前的应用一直有安全漏洞,valid_username 请求头可能被伪造。当然,正常登录后,也是用 valid_username 来传递信息的,这个也要改掉,WSGI 不分敌我的干掉了。。。
Golang 里还是照样可以使用下划线,因为 Golang 没有 WSGI 这货,天然就可以作为 Web 服务器跑起来。 有篇爆栈的文章解释为什么 Golang 不需要 WSGI