在这里，和咱们聊聊我自己所知道的一些关于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。

[1] [2]  黑客接单网