一次完整的浏览器请求响应到403bypass全姿势总结

Hello,因为最近想写一款bypass通杀软件，所以在收集知识复习的过程中就想着写一些文章来分享，内容比较基础，大佬们轻喷。

本篇引用参考文章：

https://zhuanlan.zhihu.com/p/596229063

https://zhuanlan.zhihu.com/p/642297652

https://blog.csdn.net/qq_50854790/article/details/124374247

感谢以上文章的各个师傅。

计算机七层模型自下而上，IP属于传输层协议，TCP和UDP属于网络层协议，而最上层就是HTTP应用层协议，也就是说TCP是TCP/IP协议的调用者，HTTP协议是通过TCP/IP协议进行传输数据的。

 

整个HTTP请求构建过程如下：

1.构造请求行

浏览器构建请求行信息，包含了请求方法、请求 URI和 HTTP 协议版本。

GET /index.html HTTP1.1

2. 查找缓存

① DNS缓存：

请求头中目标服务器HOST通常使用域名，想要获取服务器IP还需要经过一步DNS解析。DNS层层缓存可以帮助我们快速解析找到目标服务器。

② 浏览器缓存：

我们常说“被浏览器缓存了，需要重刷一下页面”，指的是浏览器会将已请求过的资源文件在本地保存一份副本，当再次请求时若存在缓存文件，则不再执行下述步骤，直接返回缓存文件，这时候请求的返回状态码是304。

 

域名解析

如果在第二步查找缓存没有找到DNS记录的话，就会去到根服务器进行请求，但是根域名服务器无法判断ip和域名对应关系，但是他知道是哪个顶级域名，也就是.com这种的ip地址，你去找他，然后找到域服务器后，他就可以查找这个这个解析域名的ip地址，然后寻找解析服务器（运营商提供），最终发来ip和域名的对应关系。

 

TCP三次握手

拿到域名对应的IP地址之后，User-Agent（一般是指浏览器）会以一个随机端口（1024< 端口 < 65535）向服务器的WEB程序（常用的有httpd,nginx等）80端口发起TCP的连接请求。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间通过各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别该连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终到达WEB程序，建立TCP/IP连接

为什么HTTP协议要基于TCP来实现？

TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

3. 准备 IP 地址和端口

为TCP/IP协议请求准备IP地址(DNS解析-查找缓存阶段)与该进程端口号。

4.等待 TCP 队列

将请求事件插入至TCP队列，等待TCP队列轮训执行。浏览器同一时间最多可建立 6 个 TCP 连接，队列长度<=6时，即可建立连接。

5. 建立 TCP 连接

TCP连接进入准备阶段。与目标服务器三次握手，为后续数据传输做好准备。

6. 发送 HTTP 请求

HTTP请求包含三部分：请求行(构建请求阶段)、请求头、请求体。

7.返回请求

服务器端接收到客户端的请求，将作出处理并返回相应数据，包含响应行、响应头、响应体。

 

浏览器会根据响应数据作出不同的反应，例如不同的Content-Encoding（编码格式）对应使用不同的解码方式；Conent-type（数据类型）若为文件类型返回服务器文件，若为json返回XHR；状态码为200代表请求成功，404表示路径不存在等。

状态码

所有状态码的第一个数字代表了响应的五种状态之一，其分类如下：

1xx 信息，表示临时响应并需要请求者继续执行操作

2xx 成功，操作被成功接收并处理

3xx 表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向

4xx 客户端错误，请求包含语法错误或无法完成请求

5xx 这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错

状态码详解

1xx

100：（继续） 请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。

101：（切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。

102：由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

2XX

200：（成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

201：（已创建） 请求成功并且服务器创建了新的资源。

202：（已接受） 服务器已接受请求，但尚未处理。

203：（非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。

204：（无内容） 服务器成功处理了请求，但没有返回任何内容。

205：（重置内容） 服务器成功处理了请求，但没有返回任何内容。

206：（部分内容） 服务器成功处理了部分 GET 请求。

208：（已经报告）一个DAV的绑定成员被前一个请求枚举，并且没有被再一次包括。

226：（IM Used）服务器已经满足了请求所要的资源，并且响应是一个或者多个实例操作应用于当前实例的结果。

3XX

300：（多种选择） 针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。

301：（永久移动） 请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。

302：（临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

303：（查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。

304：（未修改） 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。

305：（使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。

307：（临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

308：（永久转移）这个请求和以后的请求都应该被另一个URI地址重新发送。307、308和302、301有相同的表现，但是不允许HTTP方法改变。例如，请求表单到一个永久转移的资源将会继续顺利地执行。

4XX

400:（错误请求) 服务器不理解请求的语法。

401：(未授权) 请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。

402：该状态码是为了将来可能的需求而预留的。

403：（禁止) 服务器拒绝请求。

404：（未找到) 服务器找不到请求的网页。

405：（方法禁用) 禁用请求中指定的方法。

406：（不接受) 无法使用请求的内容特性响应请求的网页。

407：（需要代理授权) 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。

408：（请求超时) 服务器等候请求时发生超时。

409：（冲突) 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。

410：（已删除) 如果请求的资源已永久删除，服务器就会返回此响应。

411：（需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。

412：（未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。

413：（请求实体过大) 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。

414：（请求的 URI 过长) 请求的 URI（通常为网址）过长，服务器无法处理。

415：（不支持的媒体类型) 请求的格式不受请求页面的支持。

416：（请求范围不符合要求) 如果页面无法提供请求的范围，则服务器会返回此状态代码。

417：（未满足期望值) 服务器未满足"期望"请求标头字段的要求。

418：（我是一个茶壶）这个代码是在1998年作为传统的IETF April Fools‘ jokes被定义的在RFC2324，超文本咖啡罐控制协议，但是并没有被实际的HTTP服务器实现。RFC指定了这个代码应该是由茶罐返回给速溶咖啡。

419：（认证超时）并不是HTTP标注的一部分，419认证超时表示以前的有效证明已经失效了。同时也被用于401未认证的替代选择为了从其它被拒绝访问的已认证客户端中指定服务器的资源。

420：（方法失效）不是HTTP的标准，但是被Spring定义在HTTP状态类中当方法失时使用。这个状态码已经不推荐在Spring中使用。

420：（提高你的耐心）也不是HTTP标准的一部分，但是被版本1的Twitter搜索和趋势APi返回当客户端的速率被限制的时候。其它的服务提供商可能会使用429太多的请求响应码来代替。

421：从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。

422：请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）423 Locked

当前资源被锁定。（RFC 4918 WebDAV）

424：由于之前的某个请求发生的错误，导致当前请求失败，例如 PROPPATCH。（RFC 4918 WebDAV）

425：在WebDav Advanced Collections 草案中定义，但是未出现在《WebDAV 顺序集协议》（RFC 3658）中。

426：客户端应当切换到TLS/1.0。（RFC 2817）

428：(需要前置条件)原始服务器需要有条件的请求。当客户端GET一个资源的状态的时候，同时又PUT回给服务器，与此同时第三方修改状态到服务器上的时候，为了避免丢失更新的问题发生将会导致冲突。

429：（过多请求）用户已经发送了太多的请求在指定的时间里。用于限制速率。

431：（请求头部字段太大）服务器由于一个单独的请求头部字段或者是全部的字段太大而不愿意处理请求。

440：（登陆超时（微软））一个微软的扩展，意味着你的会话已经超时。

444：（无响应）被使用在Nginx的日志中表明服务器没有返回信息给客户端并且关闭了连接（在威慑恶意软件的时候比较有用）。

449：（重试（微软））一个微软的扩展。请求应该在执行适当的动作之后被重试。

450：（被Windows家长控制阻塞（微软））一个微软的扩展。这个错误是当Windows家长控制打开并且阻塞指定网页的访问的时候被指定。

451：（由于法律原因而无效（因特网草稿））被定义在因特网草稿“一个新的HTTP状态码用于法律限制的资源”。被用于当资源的访问由于法律原因被禁止的时候。例如检查制度或者是政府强制要求禁止访问。一个例子是1953年dystopian的小说Fahrenheit 451就是一个非法的资源。

451：（重定向（微软））被用在Exchange ActiveSync中如果一个更有效的服务器能够被使用或者是服务器不能访问用户的邮箱。客户端会假定重新执行HTTP自动发现协议去寻找更适合的服务器。

494：（请求头太大（Nginx））Nginx内置代码和431类似，但是是被更早地引入在版本0.9.4（在2011年1月21日）。

495：（证书错误（Nginx））Nginx内置的代码，当使用SSL客户端证书的时候错误会出现为了在日志错误中区分它和4XX和一个错误页面的重定向。。

496：（没有证书（Nginx））Nginx内置的代码，当客户端不能提供证书在日志中分辨4XX和一个错误页面的重定向。

497：（HTTP到HTTPS（Nginx））Nginx内置的代码，被用于原始的HTTP的请求发送给HTTPS端口去分辨4XX在日志中和一个错误页面的重定向。

498：（令牌超时或失效（Esri））由ArcGIS for Server返回。这个代码意味着令牌的超时或者是失效。

499：（客户端关闭请求（Nginx））被用在Nginx日志去表明一个连接已经被客户端关闭当服务器仍然正在处理它的请求，是的服务器无法返货状态码。

499：（需要令牌（Esri））由ArcGIS for Server返回。意味着需要一个令牌（如果没有令牌被提交）。

5XX

500：（服务器内部错误） 服务器遇到错误，无法完成请求。

501：（尚未实施） 服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。

502：（错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。

503：（服务不可用） 服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。

504：（网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。

505：（HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

506：由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。

507：服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)

509：服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。

510：获取资源所需要的策略并没有没满足。（RFC 2774）。

508：（发现环路）服务器发现了一个无限的循环档处理请求的时候。

511：（需要网络授权）客户端需要授权去火的网络的访问权限。一般用于代理交互中被用来进行网络的访问控制。

520：（未知错误）这个状态码也没有被指定在任何RFC中，并且只会被一些服务器返回，例如微软的Azure和CloudFlare服务器:”520错误。本质上是一个捕获全部的响应当原始服务器返回一些未知的或者一些不能被忍受或者被解释的(协议违反或者空响应)”。

598：（网络读取超时异常(未知)）这个状态码也没有在任何RFC中指定，但是被用在微软的HTTP代理中去标注一个网络读取超时在一个客户端之前的代理的后面。

599：（网络连接超时异常(未知)）这个状态码也没有在任何RFC中指定，但是被用在微软的HTTP代理中去标注一个网络连接超时在一个客户端之前的代理的后面。

403状态码的绕过：

那么有的时候在渗透过程中会出现403的情况，那出现403是说明这个资源我可以访问的到，但是被服务器禁止，那么有没有可以绕过的技巧呢，这里我就收集一下所有的绕过方法和思路：

先来看一下可能造成403的原因：

1、IP被列入黑名单。

2、在一定时间内过多地访问此网站(一般是用采集程序)，被防火墙拒绝访问了。

3、网站域名解析到了空间，但空间未绑定此域名。

4、网页脚本文件在当前目录下没有执行权限。

5、在不允许写/创建文件的目录中执行了创建/写文件操作。

6、以http方式访问需要ssl连接的网址。

7、浏览器不支持SSL 128时访问SSL 128的连接。

8、在身份验证的过程中输入了错误的密码。

9、DNS解析错误，手动更改DNS服务器地址。

10、连接的用户过多，可以过后再试。

11、服务器繁忙，同一IP地址发送请求过多，遭到服务器智能屏蔽。

绕过方式

有的应用为了区分爬虫或者正常请求，会验证user-agent，看是否浏览器发出的请求。

User-agent是用户代理，也叫UA，网站服务器通过识别 “UA”来确定用户所使用的操作系统版本、CPU 类型、浏览器版本等信息。而网站服务器则通过判断 UA 来给客户端发送不同的页面。

这个在实战中其实不是爬虫，绕过的意义不大，但是还是整理一下常见的各个UA：

系统	浏览器	User-Agent字符串
Mac	Chrome	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36
Mac	Firefox	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:65.0) Gecko/20100101 Firefox/65.0
Mac	Safari	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15
Windows	Edge	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763
Windows	IE	Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Windows	Chrome	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
iOS	Chrome	Mozilla/5.0 (iPhone; CPU iPhone OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) CriOS/31.0.1650.18 Mobile/11B554a Safari/8536.25
iOS	Safari	Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4
Android	Chrome	Mozilla/5.0 (Linux; Android 4.2.1; M040 Build/JOP40D) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.59 Mobile Safari/537.36
Android	Webkit	Mozilla/5.0 (Linux; U; Android 4.4.4; zh-cn; M351 Build/KTU84P) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

部门网站只允许特定的IP进行访问，应该会验证客户端的IP，如果不是规定的IP，则会返回403。

可以通过在请求报文中加入下列字段的方式绕过：

需要注意的是，不同的服务器支持的字段不同

X-Originating-IP: 127.0.0.1

（X-Originating-IP是一个自定义的 HTTP 请求头字段，用于指示请求的源IP地址。

通常情况下，当客户端发送HTTP请求时，其源IP地址会被包含在TCP/IP协议的IP头部中。然而，有时在特定环境下，例如通过代理服务器或负载均衡器发送请求时，IP头部中的源IP地址可能会被替换为代理服务器的IP地址。

为了提供更多关于请求的信息，一些应用程序或服务器可能会添加自定义的HTTP请求头字段，例如X-Originating-IP。该字段通常包含了最初发送请求的客户端的真实IP地址。

需要注意的是，X-Originating-IP是一个非标准的自定义字段，它的使用和解释可能因应用程序、服务器或网络设备的不同而有所变化。在某些情况下，这个字段可能被用于记录请求的来源IP地址，以进行安全性分析、追踪或其他目的。

总之，X-Originating-IP是一个自定义的HTTP请求头字段，用于指示请求的源IP地址，但它的具体含义和用途会根据应用程序和环境而有所不同。

因此通过伪造，可以从传输层（IP）这块伪造自己是作为中转服务器然后来请求访问

）

X-Remote-IP: 127.0.0.1

一个自定义的 HTTP 请求头字段，用于指示远程客户端的IP地址，可能是某个服务器实现的支持字段。

True-Client-IP: 127.0.0.1

一个自定义的 HTTP 请求头字段，用于指示客户端的IP地址，可能是某个服务器实现的支持字段。

X-Client-IP: 127.0.0.1

一个自定义的 HTTP 请求头字段，用于指示客户端的IP地址，可能是某个服务器实现的支持字段。

Client-Ip: 127.0.0.1

同上

（常见）X-Forwarded-For: 127.0.0.1

一个常见的 HTTP 请求头字段，用于指示客户端经过的代理服务器链的IP地址。

当客户端通过代理服务器发送请求时，代理服务器会在请求中添加X-Forwarded-For 头字段，以记录客户端的原始IP地址和每个经过的代理服务器的IP地址。这样可以向服务器提供有关请求的来源路径的信息。

该字段的值通常是一个逗号分隔的IP地址列表，最左边的IP地址是最初的客户端IP地址，接着是每个代理服务器的IP地址。例如，X-Forwarded-For: clientIP, proxy1IP, proxy2IP。

服务器可以使用X-Forwarded-For 字段来获取请求的真实客户端IP地址，尤其在多层代理或负载均衡环境中。然而，需要注意的是，由于HTTP请求头可以被伪造，X-Forwarded-For 字段的值可能不可信，因此在安全性敏感的场景中应谨慎使用。

需要注意的是，X-Forwarded-For是一个标准的HTTP请求头字段，广泛被用于代理服务器和负载均衡器之间传递客户端IP地址信息。

总之，X-Forwarded-For是一个用于指示客户端经过的代理服务器链的IP地址的HTTP请求头字段，它提供了关于请求的来源路径的信息。

（常见）X-Forwared-Host: 127.0.0.1

一个常见的 HTTP 请求头字段，用于指示原始请求中的主机名。

当客户端通过代理服务器发送请求时，代理服务器会在请求中添加X-Forwarded-Host 头字段，以指示原始请求中的主机名。这对于反向代理和负载均衡等场景非常有用，因为代理服务器可能会将请求转发给不同的后端服务器，但仍希望后端服务器知道最初请求的主机名。

该字段的值通常是一个单一的主机名，例如X-Forwarded-Host: example.com。

后端服务器可以使用X-Forwarded-Host 字段来获取原始请求中的主机名，以便进行适当的处理和响应。这对于虚拟主机的支持、URL重写和反向代理等功能非常重要。

需要注意的是，X-Forwarded-Host是一个标准的HTTP请求头字段，广泛被用于代理服务器和负载均衡器之间传递原始请求的主机名信息。

X-Host: 127.0.0.1

一个自定义字段

X-Custom-IP-Authorization: 127.0.0.1

一个自定义的 HTTP 请求头字段，用于指示客户端的IP地址进行特殊的授权或认证。

这个字段的具体含义和用途会根据应用程序或服务器的设计和实现而有所不同。一种常见的用法是在服务器端实现自定义的IP地址授权机制。当客户端发送请求时，可以在请求头中添加X-Custom-IP-Authorization 字段，并将客户端的IP地址作为字段的值。服务器端可以根据这个字段的值来验证客户端的IP地址是否有权访问特定资源或执行特定操作。

需要注意的是，X-Custom-IP-Authorization是一个非标准的自定义字段，它的使用和解释完全取决于应用程序或服务器的实现。在使用这个字段时，需要确保服务器端能够正确地解析和处理该字段，并进行相应的授权或认证操作。

X-Remote-Addr: 127.0.0.1

一个自定义字段

（常见）X-Real-IP: 127.0.0.1

一个常见的 HTTP 请求头字段，用于指示客户端的真实IP地址。

当客户端通过代理服务器发送请求时，代理服务器可能会添加X-Real-IP 头字段，以指示客户端的真实IP地址。这对于反向代理和负载均衡等场景非常有用，因为代理服务器可能会替换请求中的源IP地址，而 X-Real-IP 字段提供了客户端的真实IP地址。

该字段的值通常是客户端的真实IP地址，例如X-Real-IP: 192.168.0.1。

后端服务器可以使用X-Real-IP 字段来获取客户端的真实IP地址，以便进行适当的处理和响应。这对于记录日志、安全性分析和访问控制等功能非常有用。

需要注意的是，X-Real-IP是一个非标准的自定义字段，它的使用和解释可能因应用程序、服务器或网络设备的不同而有所变化。在某些环境中，也可以使用其他类似的自定义字段来传递客户端的真实IP地址。

总结

X-Originating-IP: 127.0.0.1

X-Forwarded-For: 127.0.0.1

X-Forwarded: 127.0.0.1

Forwarded-For: 127.0.0.1

X-Remote-IP: 127.0.0.1

X-Remote-Addr: 127.0.0.1

X-ProxyUser-Ip: 127.0.0.1

X-Original-URL: 127.0.0.1

Client-IP: 127.0.0.1

True-Client-IP: 127.0.0.1

Cluster-Client-IP: 127.0.0.1

X-ProxyUser-Ip: 127.0.0.1

Host: localhost

这里存在自定义呢是取决于服务器中间件和应用程序，因此可以先先尝试常见的请求头字段再去尝试自定义的，这里可能还有很多，因此就简单记录一些。

我们来想象一下这种情况，一家公司会有多个WEB应用部署在同一台服务器上，通过Host字段来指定应该由哪个WEB应用来处理用户的请求。

所以有的时候在一台服务器上会有公共的资源路径可以被访问到，那这个时候的host可以因为一些限制原因导致这个请求被禁止，这个时候可以搜集当前host的子域名，然后通过子域名来访问路径，绕过403。

Referer字段是一个常见的HTTP请求字段，用于指示发送当前请求的来源页面的 URL。

它通常用于标识用户从哪个页面链接或跳转而来，以及用于统计分析、日志记录、防盗链等方面的处理。当客户端发送一个 HTTP 请求时，它可以包含一个名为 Referer 的请求头字段，该字段的值是来源页面的 URL。例如：

Referer: http://example.com/page1.html

Referer字段通常由浏览器自动添加，表示用户在当前页面点击链接或提交表单时所在的页面。

它可以帮助服务器端了解用户的行为路径，并进行相应的处理。例如，网站可以根据Referer 字段判断用户的来源，进行相关的统计分析、页面导航、防盗链验证等操作。

那如果网站限制了访问来源，如果访问来源不符合，则也会返回403

绕过方式：

设置referer为访问网站的host

例如：

Request

GET /auth/login HTTP/1.1

Host: xxx 

Response HTTP/1.1 403 Forbidden

Reqeust

GET / HTTP/1.1

Host: xxx

ReFerer:https://xxx/auth/login

ResponseHTTP/1.1 200 OK

 

 

用户可以使用X-Original-URL或X-Rewrite-URL HTTP请求标头覆盖请求URL中的路径，尝试绕过对更高级别的缓存和Web服务器的限制。

可以这样绕过的原因：有很多的web应用，只对uri地址内容进行权限检查，这就导致uri路径正常访问之后（比如下列样例中的normalpath），我又覆盖了新的地址（adminpath），导致403 ByPass

请求包

GET /normalpath HTTP/1.1

X-Original-URL: /adminpath

X-Rewrite-URL: /adminpath

Host: www.darker.com

Host: 192.168.1.1

基于扩展名，用于绕过403受限制的目录。

site.com/admin => 403

site.com/admin/ => 200

site.com/admin// => 200

site.com//admin// => 200

site.com/admin/* => 200

site.com/admin/*/ => 200

site.com/admin/. => 200

site.com/admin/./ => 200

site.com/./admin/./ => 200

site.com/admin/./. => 200

site.com/admin/./. => 200

site.com/admin? => 200

site.com/admin?? => 200

site.com/admin??? => 200

site.com/admin…;/ => 200

site.com/admin/…;/ => 200

site.com/%2f/admin => 200

site.com/%2e/admin => 200

site.com/admin%20/ => 200

site.com/admin%09/ => 200

site.com/%20admin%20/ => 200

(%00,0x00,//,;,％, !, ?,[]等)- 将其添加到路径的末尾和路径内部

从 HTTP 1.2、降级到 HTTP 1.1 等

GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH, INVENTED, HACK

https://redacted.com/admin -> 403 Forbidden

https://redacted.com/Admin -> 200 OK

https://redacted.com/aDmin -> 200 OK

8. 断开连接

若非长连接，TCP将断开与服务端的连接。持久连接可复用信道(keep-alive/webSocker)，减少请求握手、挥手过程。

以上就是HTTP连接全过程，你可以根据下图查看、分析整个连接周期

 

到这里浏览器的一次请求就已完整完成。

好啦，感谢一直坚持收看到最后， 那这次也拜托大家多多支持转发收藏扩散啦

    那好了，这里是HexaGoners六边形者实验室，我们下次再见。

原文始发于微信公众号（HexaGoners）：一次完整的浏览器请求响应到403bypass全姿势总结