授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一个 IP 凭什么能同时放很多站很多网站共用一个 IP是极常见的部署方式。你 ping 几个不同的域名回来的地址可能是同一个你在同一台机器上放了好几份站点内容浏览器访问不同域名却各进各家。服务器凭什么分得清「路由依据」这个身份是规范给的先把这句话原样搬出来因为本文后面所有内容都从它长出来。RFC 9110 §7.2 的原文是The “Host” header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names.这句的每一处用词都值得盯住Host提供的是来自目标 URI 的主机与端口信息它的作用是让源服务器在同时服务多个主机名时能够区分资源。换句话说Host不是网址的装饰也不是某种加密标记它是一份路由信息——服务端拿到它才知道这一次请求要落到哪一份内容上。规范把这件事的机制称为 application-level routing mechanism中文口径就是应用层的路由依据。理解了这个身份很多现象就不再奇怪为什么同一个 IP 上能放很多站、为什么请求里总有这一行、为什么它既被正常路由依赖又被规范专门点名——都能顺着它是路由依据这条线解释下来。还要注意「区分资源」这四个字的分寸。规范说的不是服务器会去猜你要什么而是服务端在应答之前必须先知道这一次请求该落到哪一份资源上。Host提供的正是做这个判断所需的那份信息它是判断的输入不是判断的结果更不是内容本身。一个地址配多个名字靠什么对齐Host的语法本身短得出奇RFC 9110 §7.2 里写作Host uri-host [ “:” port ] ; Section 4也就是说它由目标 URI 里的主机分量加一个可选的端口组成。主机分量怎么取值规范指向 §4这部分本文只作定性不展开。你要记住的是它携带的信息来自目标 URI而不是凭空生成的一个标签。再读一遍那条语法Host uri-host [ : port ]。方括号在语法记号里表示可选也就是说端口可写可不写写出来时取值就是目标 URI 里的端口。这意味着Host承载的信息可以细到同一个主机名下的不同端口也可以只到哪一个主机名。正因为它是从目标 URI 里取出来的后面几章里那些对得上、对不上才都围绕它展开。把常见的几种现象摊开对照一下能看清它到底在管什么。你看到的现象实际发生的事依据两个不同域名 ping 到同一个 IP两个名字指向同一地址请求都被送到同一台机器本文只作定性不展开名字解析同一台机器上有多份站点内容服务端按请求里的主机信息挑一份来应答HT01换一个主机名去请求返回内容变了路由依据变了选到的资源也就变了HT01请求里缺少主机信息源服务器无从区分你要哪一个HT01、HT03本章可以带走的一句Host的身份是应用层的路由依据它不是网址的装饰而是源服务器在一个地址多个站点时用来区分你要哪一个的依据。请求里那行 Host 是从哪来的如果它是路由依据那这份信息是本来就有的还是每次都得随请求带上规范把这件事说得相当硬。用户代理必须发而且被建议放在首位RFC 9110 §7.2 的原文The target URI’s authority information is critical for handling a request. A user agent MUST generate a Host header field in a request unless it sends that information as an “:authority” pseudo-header field. A user agent that sends Host SHOULD send it as the first field in the header section of a request.拆成两件事看一来目标 URI 的权威信息对处理请求至关重要所以用户代理MUST生成Host字段——除非它改用:authority伪首部来承载这份信息这一条留到第 4 章细说二来发Host时SHOULD把它放在请求头部的第一位。这里要分清 MUST 与 SHOULDMUST 是硬要求没有看情况的空间SHOULD 是除非有充分理由否则应当这样做。放在首位这条属于后者——它是一个强建议不是铁律。把这条规定放进排查里看MUST 那一句说明请求里携带主机信息是用户代理的义务不是可选装饰如果一次请求里这份信息出了问题从规范角度看是用户代理这一侧没有尽到它该尽的义务。SHOULD 那一句则说明位置靠前是被期望的写法不是硬性约束——所以你看到它并不总在第一位时也不必立刻判成异常。把硬要求和强建议分开能少制造一批假的异常。规范自带的那两行样例规范里给了一个最小示例原文只有两行GET /pub/WWW/ HTTP/1.1Host: www.example.org本文只引这两行不再构造任何其它报文样例。你能从这两行里看到的东西是请求行之后紧随其后的就是那一行主机信息——位置靠前内容来自前面那个 URL 里的主机名。想看真实请求里这一行长什么样可以借助命令行工具做一次纯观察不改写任何内容。⚠️代码待验证# 用 -v 观察一个请求的头部里是否出现主机信息这一行只观察不修改请求内容curl-vhttp://example.org/-o/dev/null说明一句-v会把请求的头部打到终端你可以对照看到那一行。这里做的是观察动作不是构造动作。另一处值得留意的是规范在这个位置只给了两行并没有给完整请求应该长什么样的整段样例。它定义的是字段、语法和位置而不是外观。也正因为如此本文除这两行之外不再另外构造任何请求样例——那既不是规范给的也容易把某个工具的写法误当成协议的规定。有地址不等于真的有服务器还有一个容易想当然的地方规范专门提示过。RFC 9110 §4.2 的原文Note that the presence of an “http” or “https” URI does not imply that there is always an HTTP server at the identified origin listening for connections. Anyone can mint a URI, whether or not a server exists and whether or not that server currently maps that identifier to a resource.翻译成排查口径URI 里写着http或https并不代表那个 origin 上一定有个 HTTP 服务器在监听连接。任何人都可以造出一个 URI不管那台服务器存不存在、也不管它当下有没有把这个标识符映射到某个资源上。所以排查时不要从URI 里写的是这个主机直接推出这个主机上一定有服务在等我。这两件事之间没有必然关系。换个说法URI 里写着某个主机是名字层面的事那个主机上有没有服务在听是运行层面的事二者相互独立。排查时把它们分开能避开一个很常见的误判——因为 URL 看起来很正常就默认对面一定有东西在应答。本章可以带走的一句请求里的主机信息是用户代理必须生成、并被建议放在首位的而 URI 里写着某个主机并不代表那个主机上一定有个服务在等你的连接。服务端拿到请求之后先看什么请求送到了服务端并不是看到就答。规范把它的决策过程写得很清楚。先解析出目标 URI再决定怎么处置RFC 9110 §7.4 的原文Once a request is received by a server and parsed sufficiently to determine its target URI, the server decides whether to process the request itself, forward the request to another server, redirect the client to a different resource, respond with an error, or drop the connection. This decision can be influenced by anything about the request or connection context, but is specifically directed at whether the server has been configured to process requests for that target URI and whether the connection context is appropriate for that request.拆开看顺序是固定的收到请求 → 解析到足以确定目标 URI的程度 → 然后做五选一的判断自己处理、转发给另一台服务器、重定向客户端、回一个错误、或者直接断开连接。而这五选一具体怎么选规范点明了两个专门指向的因素一是这台服务器有没有被配置为处理这个目标 URI二是收到请求的这条连接上下文对这个请求合不合适。注意规范用的是can be influenced by anything about the request or connection context, but is specifically directed at——影响面可以很宽但落点就这两处。把这五类处置再念一遍会发现它们是递进的先看能不能自己答不能就考虑转给别人再不行考虑把客户端引到别处还不行回一个错误最后才是断开连接。规范把它们并列给出恰好说明服务端该不该答从来不取决于请求长什么样而取决于它自己的配置边界与这条连接是否合适。服务端的处置触发条件规范口径自己处理服务器被配置为可处理该目标 URI转发到另一台服务器同样取决于配置与连接上下文重定向客户端目标是另一个资源返回一个错误目标 URI 或连接上下文不合适断开连接规范给出的最激烈的一种处置依据HT06想看服务端到底答没答、答成了哪一类同样可以用工具只看响应这一侧。⚠️代码待验证# 只看响应头与状态行响应正文丢弃用于判断服务端如何处置这个请求curl-sS-D--o/dev/null http://example.org/主机信息与连接对不上意味着什么还有一种情形规范专门提了请求里携带的主机信息与收到这条请求的连接的主机或端口对不上。RFC 9110 §7.4 的原文本文只取它的定性不往下写任何一种做法For example, a request might have been misdirected, deliberately or accidentally, such that the information within a received Host header field differs from the connection’s host or port. If the connection is from a trusted gateway, such inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server into delivering non-public content, or poison a cache.规范把这种情况分两类如果连接来自可信网关这种不一致可能是预期之内的否则它可能是想绕过安全过滤、诱导服务器吐出非公开内容、或者污染缓存。本文只到这句定性为止任何一种怎么做都不在本文范围内。作为一个在自建环境里排查的人你需要带走的是主机信息与连接上下文是否一致本身就是服务端做判断时会看的输入之一。规范为什么要特意把它分成可信网关与否则两类因为这条判断背后有一个前提问题这条连接究竟是谁送来的。请求经由你信任的中间环节进来时主机信息与连接对不上可能是链路的正常结果请求若是直接来的这种不一致就更值得警惕。本文不展开任何一种利用方式但这条判断逻辑可以带走——它看的是这份信息与这条连接是否自洽。本章可以带走的一句服务端先解析出目标 URI再决定自己答、转给别人、重定向、报错还是断连主机信息与连接上下文相不相符是它判断时会看的输入之一。换成 HTTP/2、HTTP/3 之后那行 Host 去哪了讲到这里Host一直待在请求头里。可如果你在新一代协议下抓包可能会发现这一行不见了。它去哪了它有了一个替身RFC 9110 §7.2 里紧跟着一句说明本文只引这一句不展开版本之间的完整差异In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in some cases, supplanted by the “:authority” pseudo-header field of a request’s control data.关键在 “in some cases”——是某些情况下被取代不是一律被取代。也就是说在较新的协议版本里承载你要哪一个主机这份信息的位置可能从请求头部挪到了请求控制数据里的:authority伪首部。承载它的信息没有丢换了个位置而已。换个角度说变的只是承载位置不是信息本身。路由依据这个身份没有变——服务端依然要靠你要哪一个主机来做区分只是在新协议里这份信息被放进了请求的控制数据。记住这一点比记住某个字段名更有用。⚠️代码待验证# 用支持 HTTP/2 的客户端发起请求观察承载主机信息的位置与 HTTP/1.1 下的呈现不同curl--http2-vhttps://example.org/-o/dev/null说明能不能在输出里直接看到那个伪首部取决于客户端与它的输出方式本文未核具体的呈现形式这里只做观察不据此下结论。知道有替身排查时少绕一圈抓包时如果发现这一版的请求里看不到主机那一行先别急着下没有主机信息的结论。按 HT02 的口径它很可能就是被:authority取代了。知道有这么一个替身能省掉一轮误判——这属于排查里的少绕一圈。本章可以带走的一句在新一代协议里主机信息的替身是请求控制数据里的:authority而且是某些情况下取代不是一律取代。它为什么既是路由依据也被规范点名为风险点同一份信息一边被路由依赖一边被规范专门点名这件事值得单独说清楚。规范自己就说它是常被盯上的目标RFC 9110 §7.2 的原文本文只取性质不写手法Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.这句话的信息量在为什么正因为主机与端口信息扮演的是应用层路由机制的角色它才成了常见的目标。规范点出的脆弱环节也很具体——凡是拿它来把请求转给内网服务器、或拿它当共享缓存的键、却没有先核实这条连接的目标地址是否真的是这个主机的合法地址的中间环节尤其危险。请把边界记清楚规范讲的是常见的目标以及哪些环节脆弱本文一句手法都不往下写。为什么路由依据几乎注定要成为风险面因为它会被信任。一个中间环节如果把主机信息当成可信的路由指令就等于把往哪儿送、拿什么当缓存键的决定权交给了请求方提供的内容。规范点到的那类脆弱本质都是先用了、却没有先核实。这个道理可以带走凡是拿请求里的信息去做路由或缓存决策的环节都该先问一句——这条连接真的指向那个主机吗。https 资源上的那条硬要求https资源上还有一条更硬的。RFC 9110 §7.4 的原文Unless the connection is from a trusted gateway, an origin server MUST reject a request if any scheme-specific requirements for the target URI are not met. In particular, a request for an “https” resource MUST be rejected unless it has been received over a connection that has been secured via a certificate valid for that target URI’s origin, as defined by Section 4.2.2.译成排查口径除非连接来自可信网关源服务器一旦发现目标 URI 的 scheme 相关要求没有被满足就MUST 拒绝。落到https资源上更具体——这条连接必须经过一张对该目标 URI 的 origin 有效的证书保护否则必须拒绝。这就解释了一个常见的困惑靶场里端口通、连接也建起来了服务端却还是拒。它拒的不是你不该连过来而是这个 origin 还没有以它能接受的方式被证明过。§4.2.2 本身的内容本文未核只引到这里的引用句。注意 MUST reject 的分量——拒绝在这里不是可选应对而是规范认定的默认正确动作。这条要求也解释了一种常见的困惑连接建立成功和这条连接能不能代表那个 origin是两回事后者才是https资源真正关心的门槛。421服务器说「你找错地方了」对应地规范给了一个明确的状态码。RFC 9110 §15.5.20 的原文The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI. An origin server (or gateway acting on behalf of the origin server) sends 421 to reject a target URI that does not match an origin for which the server has been configured (Section 4.3.1) or does not match the connection context over which the request was received (Section 7.4).客户端侧它也给了话A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection …归纳一下421 的含义是这台服务器不能或者不愿为这个目标 URI 给出权威应答。触发它的两类典型情形是——目标 URI 不匹配这台服务器被配置的 origin或者不匹配收到请求的那条连接上下文。而客户端这一侧收到 421 之后MAY可以不是必须换一条连接重试规范特意点了无论请求方法是否幂等。客户端那侧的 MAY 也值得记一下规范并没有要求客户端必须重试只说它可以而且是换一条连接去重试。这意味着客户端有自主判断的空间——它得先想清楚是不是自己选错了服务器再决定要不要重来。读规范读到这种地方就能解释为什么同样的请求客户端有时会自己再试一次。把三种拒放在一起对照边界会更清楚。现象规范给的名字一句话服务器说这个目标不属于它421 Misdirected Request目标 URI 或连接上下文对不上服务器的配置https资源走了不合格的连接规范要求 MUST rejectHT08连接须被对该 origin 有效的证书保护过主机信息与连接对不上判为一致性问题后按处置决定HT07来自可信网关可能是预期的否则可疑⚠️代码待验证# 观察 TLS 握手里客户端声明的目标主机名用于理解连接上下文是否匹配# 注意它与 Host 的关系本文未核这里只做观察不据此下结论openssl s_client-connectexample.org:443-servernameexample.org/dev/null⚠️代码待验证# 只看状态码判断某个请求是否被拒以及被拒成了哪一类curl-sS-o/dev/null-w%{http_code}\nhttps://example.org/本章可以带走的一句主机信息是应用层的路由依据所以它既被路由器依赖也被规范点名为风险点在https资源上连接无法证明该 origin 时源服务器必须拒绝。完整版协议对照资料这份资料把 HTTP 语义里与请求路由相关的几个字段、状态码与必要条件整理成一页对照正好对应本章讲到的路由依据 硬要求 421。放在资料包里扫码即可获取四个常见判断逐个说清初学时最容易把几件事揉成一句连不上。这里拆成四问逐个对。前两个它们直接就是路由问题一、域名解析到多个 IP。这就意味着同一个名字可能被送到不同的机器上。但要注意请求里携带的主机信息并不会因此改变——它来自目标 URIHT01。所以解析变了和路由依据变了是两件事。名字解析这一段本文不复述另有专文写过。二、同一 IP 上多个域名。这正是Host存在的理由HT01。服务端按请求里的主机信息区分目标资源你看到同一个地址回来内容不同就是这一步在工作。把这两问放在一起能看出一条分界线**请求送到哪台机器与这台机器该给哪份内容是两个独立的问题。**前者和地址有关后者和请求里携带的主机信息有关。弄清楚这条线很多地址明明没写错、却进错了站的困惑就能解释。后两个一个未核一个要分段看三、Host 与 SNI 的关系。本文未核。规范里Host是 HTTP 层的字段HT01、HT02而 TLS 握手里还有一个客户端声明的目标主机名的位置两者是不是总一致、由谁生成本文没有核到一手依据标待验证。排查时如果发现两者看起来不一致不要凭印象下结论。四、改了本地的名字记录能不能连上。本地记录作用在名字解析这一段——本文不复述这条轴。你需要分清的是请求里携带的主机信息来自目标 URI 的 authorityHT01、HT02 语法而各客户端具体如何填充这一字段本文未核HT11。所以能不能连上要么卡在请求有没有送到该去的地方要么卡在送到之后服务端认不认这是两段要分开看。这四问的排列也有用意前两问能直接用已核事实回答后两问里一个明确标着未核一个需要把两段分开看。把我知道的和我还没核的摆在一起本身就是一种诚实——规范之外的东西不该靠印象去补。你可能遇到的判断是不是在改路由依据该看什么名字解析到多个 IP否请求有没有送到对的地址同一 IP 上多个域名是这正是它的用途请求里的主机信息Host 与 SNI 是否一致本文未核一手依据待验证改了本地名字记录否只动送到哪这一段把送到与认不认分开看本章可以带走的一句名字解析、路由依据、TLS 握手这几件事各管一段不要揉成一句连不上。一张排查顺序表把前六章的事实压成一张顺序表遇到问题照着问。按这个顺序问四个问题第一步问连接请求有没有送到对的地址第二步问路由依据请求里携带的主机信息是什么第三步问配置服务端被配置为处理这个目标 URI 吗HT06第四步问连接上下文这条连接合格吗尤其httpsHT07、HT08为什么把送对地址放在第一步因为它是最外层的前提请求没到该去的地方后面三步都无从谈起。为什么把连接上下文放在最后因为它最容易被忽略而https上的拒绝恰恰常常卡在这里。顺序本身就是一层经验排序。顺序问什么对应事实不合格时的典型表现1请求送到对的地址了吗连接层连不上或超时2请求里的主机信息是什么HT01、HT03选错站点3服务端被配置为处理该 URI 吗HT06被转接、报错或断连4连接上下文合格吗HT07、HT08被拒https的硬要求⚠️代码待验证# 一次把过程看清楚连接、请求头、响应按上面四步逐个对照curl-vhttps://example.org/-o/dev/null回到开头那个问题服务器凭什么知道你要哪一个凭请求里那份来自目标 URI 的主机信息HT01。它是用户代理必须生成的HT03在服务端它被用来区分资源HT01、决定怎么处置这次请求HT06在https上它还要配合连接能证明该 origin这条硬要求HT08证明不了就会吃到 421 一类的拒绝HT09如果换了协议版本它可能改由:authority承载HT02。一路看下来会发现所谓服务器知道你要哪一个其实不是服务器会读心而是请求每次都把这份信息带上了服务端按它做判断而已。还要意识到这几个环节是层层递进的不是并列的选项地址先对了才轮到看主机信息主机信息有了才轮到服务端判断配置配置覆盖了才轮到检查连接上下文。任何一环不满足后面都无从进行——这也解释了为什么排障时跳步往往越查越乱。本章可以带走的一句排查一个地址多个站点的问题按送到对地址 → 看主机信息 → 看配置是否覆盖 → 看连接上下文是否合格四步走比一上来就猜服务端要靠谱得多。完整版协议速查卡把本文用到的 RFC 9110 条款§7.2、§7.4、§4.2、§15.5.20压成一张速查卡排查时对着条号回溯一手原文。放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表编号事实要点出处本文位置HT01Host提供目标 URI 的主机与端口信息使源服务器在服务多个主机名时能区分资源逐字原文见第 1 章RFC 9110 §7.2第 1、5、7 章HT02HTTP/2、HTTP/3 中Host在某些情况下被:authority伪首部取代语法为Host uri-host [ : port ]RFC 9110 §7.2第 2、4 章HT03目标 URI 的权威信息对处理请求至关重要用户代理 MUST 生成Host除非改用:authority发Host时 SHOULD 放首位RFC 9110 §7.2第 2 章HT04规范给出的两行样例报文仅此两行RFC 9110 §7.2第 2 章HT05主机与端口信息充当应用层路由机制故常被盯上用于污染共享缓存或把请求引向非预期服务器中间代理在未先核实连接目标地址时尤其脆弱只作定性RFC 9110 §7.2第 5 章HT06服务端解析出目标 URI 后在自己处理 / 转发 / 重定向 / 报错 / 断连间决定取决于是否被配置处理该 URI 与连接上下文是否合适RFC 9110 §7.4第 3 章HT07Host与连接的主机或端口不一致来自可信网关可能是预期的否则可能是绕过过滤、诱导非公开内容或污染缓存只作定性RFC 9110 §7.4第 3、5 章HT08除非来自可信网关源服务器在 scheme 相关要求未满足时 MUST 拒绝https资源须走被对该 origin 有效证书保护的连接§4.2.2 本体未核RFC 9110 §7.4第 5 章HT09421 语义服务器不能或不意为该目标 URI 给出权威应答客户端 MAY 换一条连接重试RFC 9110 §15.5.20第 5 章HT10存在http/httpsURI 并不代表该 origin 一定有 HTTP 服务器在监听连接RFC 9110 §4.2第 2 章HT11Host语法中uri-host的取值见 §4各客户端/工具的默认填充行为本文未核RFC 9110 §7.2、§4第 2、6 章附表 B术语速查表术语一句话Host请求里携带目标 URI 主机与端口信息的字段应用层的路由依据:authorityHTTP/2、HTTP/3 请求控制数据里的伪首部某些情况下取代Host目标 URI服务端解析后用来判断该不该答、怎么答的依据421 Misdirected Request服务器表示该目标 URI 或连接上下文对不上不能或不愿给出权威应答连接上下文收到请求的那条连接的性质例如是否已按该 origin 合格地保护过origin由目标 URI 的 scheme 与其主机相关信息共同界定的来源本文只作定性写在最后这篇用到的资料写这篇文章时把 RFC 9110 里和一个地址多个站点相关的几条原文逐字核了一遍顺手也整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份把靶场的地址与主机名对齐再抓包本文讲的那些字段会对得上号。