谈谈我所了解的WEB代理
在这里，和大家聊聊我自己所知道的一些关于Web代理的知识。
WEB代理的类型
Web代理，有普通代理和隧道代理两种，下面简单说说这两种类型。
普通代理
该类型最为简单，代理服务器作为中间人，转发客户端的HTTP请求给目标主机，之后将目标主机的HTTP响应报文回送给客户端。
普通代理这里有个“小坑”，放到后面和大家说。
隧道代理（WebSocket代理）
首先，客户端向代理服务器发送HTTP请求，方法为CONNECT，表示请求代理服务器与目的服务器的特定端口建立TCP连接，之后代理服务器对客户端与目标服务器之间的数据进行盲转发。
具体如下图（《HTTP权威指南》第八章）：
假如我们为浏览器设置了WEB代理，在访问HTTPS类型网站时，会使用隧道代理的方式来进行访问；遇到HTTP类型网站，为了减小不必要的开销，浏览器则通常采用普通代理的方式来进行访问。
这里有篇文章，写得很详细：
https://imququ.com/post/web-proxy.html
扫端口
在渗透测试时，遇到某些WAF时，你会发现连扫端口都没法扫，而WEB扫描/暴力破解，在遇到有WAF时则可以通过Web代理服务器（大量）来进行绕过。于是笔者就幻想着有没有类似WEB代理的东西，能够解决扫端口时被WAF屏蔽的情况。起初我想了想，摇了摇头，“不可能，WEB代理服务器不是与HTTP协议相关吗，这是应用层的东西，扫端口的话，应该是传输层的东西”
现在想想也是好笑，当时都没搞明白Web代理具体是个什么样的东西，实现方法都有哪些。
其实，通过WebSocket代理就可以做到“通过代理进行端口扫描”，当然，该种情况下只能进行TCP端口的信息嗅探，而扫描的结果不只是端口是否存活，同样可以判别端口的服务类型。
原理十分简单。
第一步判断端口是否开放：
CONNECT http://www.test.com:8080 HTTP/1.1Host: www.test.com:8080
如果目标端口为开放的状态，会返回200；未开放的，代理服务器会返回503状态信息，大致分别如下。
HTTP/1.1 200 Connection established
HTTP/1.1 503 Service UnavailableServer: squid/3.3.8...
这里有一个很大的问题：很多代理服务器似乎对访问的域名/IP/端口做了一些限制，完全“开放”的websocket代理服务器数量上就可能更少了。之前笔者收集代理服务器都是通过对一些免费的网站进行爬取，这种收集到的代理在这种用途中的可用性惨不忍睹，选择收费的或是通过Shodan搜索Header中的关键字来进行收集整理或许是更好的方法。
在建立套接字后，有的服务会直接返回banner数据，这种情况下，直接选择接收下一个TCP包即可；有的就需要客户端这边发送些数据才能探测到关于该服务的信息；以及还有其他情况。笔者写了一个简单的py脚本，进行了一些测试，结果如下：
banner信息在代理服务器返回状态码的时候就返回的情况：
脚本：
https://pan.baidu.com/s/1U9MeVfrZgwDsq43EGTGYUA
到头想来，这样搞端口扫描成本太大了，目标得重要到啥程度啊。
一个小坑
前阵子，笔者在写代码时，被这个坑了大半天，当时解决了这个问题，但还是云里雾里的。之后翻开《Web之困》，发现书中已有说明。
引用《Web之困》一书3.1.3小节中的一段话：
GET http://www.fuzzybunnies.com/ HTTP/1.1Host: www.fuzzybunnies.com…
上述例子和普通的HTTP请求最大的语法差异，就是请求内容里的第一行，这时候是一个完整的URL，通过这项信息代理服务器才知道用户要连接的目标服务器在哪里。这项信息实际上有点多余，因为在Host请求头里也标识了主机名称；这种重复是因为这两套机制其实是相互独立发展起来的。为了避免客户端和服务器串通一气，如果Host请求头的信息与请求行里的URL不匹配时，代理服务器应以请求行里的URL为准，或者用特定的“URL-Host”数据对和缓存内容联起来，而不能只根据其中一项信息做出判断。
至此，笔者才恍然大悟，又回想起很久之前在浏览一些网站发生的“奇怪的事情”。有那么一两个网站，笔者在浏览器中进行访问是正常的，但用BurpSuit的Repeater去访问时却发生HTTP 400的情况，之后尝试把请求行中的URI改为完整的URL，访问就正常了，当时也不知道啥回事，没深究就这样过去了…由于问题复现不了，具体症结现在也理不清了，但很可能是Web代理引发的问题。问了一些朋友，有的遇到过，不过没解决。不知道同学们遇到过没。
反向代理
反向代理，按照笔者的理解，客户端把反向代理服务器当作真正的后台服务器即可。反向代理服务接收到客户端的请求后，如有需要会向真正的后台服务器请求资源，并返回给客户端，而客户端无需感知这是不是一台反向代理服务器。
笔者问了一些渗透测试得朋友在工作中遇到反向代理这种情况，很多说太高大上了，基本没遇到。但笔者经常遇到啊…难道是他们没发现？(懵逼)
测试时，遇到一些网站HTTP响应报文的头部有Ngnix字样，则很可能存在反向代理，而要发现反向代理背后的服务器中间件类型也很简单，只要让后端服务器发送一些非200的响应报文就好，似乎反向代理服务器对非200的报文是直接返回的，这可能是配置问题。比如发送一些代理服务器觉得正常但后端服务器无法识别的报文，例如让后端服务器返回400。
在这里，和大家聊聊我自己所知道的一些关于Web代理的知识。
WEB代理的类型
Web代理，有普通代理和隧道代理两种，下面简单说说这两种类型。
普通代理
该类型最为简单，代理服务器作为中间人，转发客户端的HTTP请求给目标主机，之后将目标主机的HTTP响应报文回送给客户端。
普通代理这里有个“小坑”，放到后面和大家说。
隧道代理（WebSocket代理）
首先，客户端向代理服务器发送HTTP请求，方法为CONNECT，表示请求代理服务器与目的服务器的特定端口建立TCP连接，之后代理服务器对客户端与目标服务器之间的数据进行盲转发。
具体如下图（《HTTP权威指南》第八章）：
假如我们为浏览器设置了WEB代理，在访问HTTPS类型网站时，会使用隧道代理的方式来进行访问；遇到HTTP类型网站，为了减小不必要的开销，浏览器则通常采用普通代理的方式来进行访问。
这里有篇文章，写得很详细：
https://imququ.com/post/web-proxy.html
扫端口
在渗透测试时，遇到某些WAF时，你会发现连扫端口都没法扫，而WEB扫描/暴力破解，在遇到有WAF时则可以通过Web代理服务器（大量）来进行绕过。于是笔者就幻想着有没有类似WEB代理的东西，能够解决扫端口时被WAF屏蔽的情况。起初我想了想，摇了摇头，“不可能，WEB代理服务器不是与HTTP协议相关吗，这是应用层的东西，扫端口的话，应该是传输层的东西”
现在想想也是好笑，当时都没搞明白Web代理具体是个什么样的东西，实现方法都有哪些。
其实，通过WebSocket代理就可以做到“通过代理进行端口扫描”，当然，该种情况下只能进行TCP端口的信息嗅探，而扫描的结果不只是端口是否存活，同样可以判别端口的服务类型。
原理十分简单。
第一步判断端口是否开放：
CONNECT http://www.test.com:8080 HTTP/1.1Host: www.test.com:8080
如果目标端口为开放的状态，会返回200；未开放的，代理服务器会返回503状态信息，大致分别如下。
HTTP/1.1 200 Connection established
HTTP/1.1 503 Service UnavailableServer: squid/3.3.8...
这里有一个很大的问题：很多代理服务器似乎对访问的域名/IP/端口做了一些限制，完全“开放”的websocket代理服务器数量上就可能更少了。之前笔者收集代理服务器都是通过对一些免费的网站进行爬取，这种收集到的代理在这种用途中的可用性惨不忍睹，选择收费的或是通过Shodan搜索Header中的关键字来进行收集整理或许是更好的方法。
无奈人生安全网
在建立套接字后，有的服务会直接返回banner数据，这种情况下，直接选择接收下一个TCP包即可；有的就需要客户端这边发送些数据才能探测到关于该服务的信息；以及还有其他情况。笔者写了一个简单的py脚本，进行了一些测试，结果如下：
banner信息在代理服务器返回状态码的时候就返回的情况：
脚本：
https://pan.baidu.com/s/1U9MeVfrZgwDsq43EGTGYUA
无奈人生安全网
到头想来，这样搞端口扫描成本太大了，目标得重要到啥程度啊。
一个小坑
前阵子，笔者在写代码时，被这个坑了大半天，当时解决了这个问题，但还是云里雾里的。之后翻开《Web之困》，发现书中已有说明。
引用《Web之困》一书3.1.3小节中的一段话：
GET http://www.fuzzybunnies.com/ HTTP/1.1Host: www.fuzzybunnies.com…
上述例子和普通的HTTP请求最大的语法差异，就是请求内容里的第一行，这时候是一个完整的URL，通过这项信息代理服务器才知道用户要连接的目标服务器在哪里。这项信息实际上有点多余，因为在Host请求头里也标识了主机名称；这种重复是因为这两套机制其实是相互独立发展起来的。为了避免客户端和服务器串通一气，如果Host请求头的信息与请求行里的URL不匹配时，代理服务器应以请求行里的URL为准，或者用特定的“URL-Host”数据对和缓存内容联起来，而不能只根据其中一项信息做出判断。
至此，笔者才恍然大悟，又回想起很久之前在浏览一些网站发生的“奇怪的事情”。有那么一两个网站，笔者在浏览器中进行访问是正常的，但用BurpSuit的Repeater去访问时却发生HTTP 400的情况，之后尝试把请求行中的URI改为完整的URL，访问就正常了，当时也不知道啥回事，没深究就这样过去了…由于问题复现不了，具体症结现在也理不清了，但很可能是Web代理引发的问题。问了一些朋友，有的遇到过，不过没解决。不知道同学们遇到过没。 内容来自无奈安全网
反向代理
反向代理，按照笔者的理解，客户端把反向代理服务器当作真正的后台服务器即可。反向代理服务接收到客户端的请求后，如有需要会向真正的后台服务器请求资源，并返回给客户端，而客户端无需感知这是不是一台反向代理服务器。
笔者问了一些渗透测试得朋友在工作中遇到反向代理这种情况，很多说太高大上了，基本没遇到。但笔者经常遇到啊…难道是他们没发现？(懵逼)
测试时，遇到一些网站HTTP响应报文的头部有Ngnix字样，则很可能存在反向代理，而要发现反向代理背后的服务器中间件类型也很简单，只要让后端服务器发送一些非200的响应报文就好，似乎反向代理服务器对非200的报文是直接返回的，这可能是配置问题。比如发送一些代理服务器觉得正常但后端服务器无法识别的报文，例如让后端服务器返回400。