4XXBypass

前言

网上可以搜索到的大多数为403Bypass，内容基本上大差不差。然后最近自己在实际渗透测试过程中，发现的一些可能不太相同的地方，简单记录一下。

免责声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失，均由使用者本人负责，所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用！！！

0x01 解析403

先来看下百度百科对于403的定义：

403错误是网站访问过程中常见的错误提示。资源不可用、服务器理解客户端的请求，但拒绝处理。通常由于服务器上 文件或目录 的权限设置导致，比如IIS或者apache设置了访问权限不当。

百度百科描述的大致意思为客户端访问了登录用户被限制访问的资源，并且还介绍了13种出现403的原因，包括SSL造成的、IP地址被拒绝造成的、连接用户过多服务器无法及时响应导致的等等。可以看出，出现403的原因有很多，所以也会有多种不同的方式来“解决“403问题。

0x02 Bypass

  • 绕过IP限制

某些网站只允许特定的IP进行访问，在客户端发送请求时，会验证客户端的IP，如果IP不在IP白名单列表里，则会返回403

此时可使用如下方式，尝试绕过：

1
2
3
4
5
6
7
8
9
10
11
12
13
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

因为我们这里一般不暴力遍历IP，所以尝试用127.0.0.1来尝试，看是否会在允许的访问列表中（一般要限制IP，应该会限制出口IP，但总有人会配置失误，所以也不失为一种思路）

  • URL覆盖绕过

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

可以绕过的原因：有很多的Web应用，只对uri地址内容进行权限检查，这就导致uri路径正常访问之后，又覆盖了新的地址，导致403 Bypass。

1
2
3
4
5
GET /user HTTP/1.1
X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console
Host: www.example.com
Host: 192.168.1.1

应用条件：

Web服务器支持

Nginx等支持重写功能的服务器：Nginx等Web服务器在配置了相应的重写规则后，可以识别并处理 X-Rewrite-URL 请求头。通过配置，服务器可以基于该请求头的内容重写请求的URL，并据此进行资源查找和响应。

挖坑：尝试复现一下使用X-Rewrite-URL绕过的场景

  • 拓展名绕过（路径fuzz）

基于扩展名（路径），用于绕过校验

以下为 burpsuite 插件BypassPro中的 路径 fuzz 参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
suffix:
    - ".js"
    - ".css"
    - ".json"
    - ".html"
    - ";.css"
    - ";.js"
    - "/."
    - "/"
    - "/./"
    - "%20"
    - "%09"
    - "?"
    - "?error"
    - "#"
    - "/*"
    - "%26"
    - "/images/..;"
    - "/public/..;"
    - ";/"

prefix:
    - "/"
    - ";/"
    - "..;/"
    - "images;/../"
    - "images/..;/"
    - "public/..;/"
    - "%2e/"
    - ";/"
    - "./"
    - "%20/"
    - "%09/"
    - ".;/"
    - "..%00/"
    - "..%0d/"
    - "..%5c/"
    - "#/../"

针对路径fuzz，我的理解是服务器在把uri发给controller之前，会先在先对uri做一次权限校验，例如uri数据库，使用严格匹配，拿/admin/userlist举例，在数据库中存放的 即为 /admin/userlist/ ，在用户请求该uri时，服务器首先在数据库中匹配该uri，判断该用户是否有访问该接口的权限，如果可以访问便将请求发送到controller，如果没有则拒绝访问，返回403 。现在我们在对uri进行了修改，导致在权限校验时匹配不上，但服务器仍然把请求发送给了controller，而controller处又使用了模糊匹配，匹配上了对应的接口，导致接口返回了数据，达到绕过权限校验的结果。

以上也仅为一种情况，不过通过路径fuzz的原理也应该大差不差。（以上仅为笔者自己的理解，挖坑，回头搭建一个spring cloud gateway来验证一下，当然，这种路径fuzz的绕过并不是很多，笔者遇到过的这种情况是某项目独立设计的网关导致出现这种情况）

  • 更换协议版本

如果原请求使用的是 HTTP/1.1，尝试使用 HTTP/1.0，或HTTP/2.0

  • HTTP请求方法fuzz

尝试使用不同的请求方法来访问：

1
2
3
4
5
6
7
8
9
10
11
GET
HEAD
POST
PUT
DELETE
OPTIONS
CONNECT
TRACE
PATCH
INVENTED
HACK

导致的原因：

1、在后端，权限校验不是全局统一的，而是每个接口单独配置。如果开发者在实现接口时，只考虑了GET的权限校验，同时该接口也可以使用POST访问，那么就可能导致使用POST方法绕过权限校验

2、中间件或过滤器配置不当，如果中间件或过滤器的配置只针对特定的HTTP方法，那么其他方法就可能不受这些过滤器和中间件的限制

  • 修改Referer

有些网站会限制访问来源，如果访问来源不符合，也会返回403

设置 referer 为访问网站的host就可以

限制访问来源的场景：

网站禁止来至测绘平台的请求

网站只允许来至自己公司资产跳转过来的请求

  • 修改ua

有的应用为了区分爬虫和正常请求，会验证user-agent，校验是否为浏览器发送的请求

  • 自动化工具

这里推荐一款笔者自己常用的burp插件

0x727/BypassPro: 对权限绕过自动化bypass的burpsuite插件

0x03 4xx绕过

明明前面介绍的都是403绕过，但标题却是4xx绕过。

在实际开发环境中，还有一种为业务控制的响应状态码，由开发人员决定在对应情况下响应哪种状态码，我在实际测试过程中，还遇到过500以及401等，但本质与服务器响应的403相同，仍然是访问了不该访问的资源。

因为笔者在实际在做项目的过程中遇到很多由开发者自定义的响应码，例如本来是因为权限不足返回403的，却返回了401、500的等各种状态码，应该是开发不规范导致，所以当遇到这种各式各样的状态码而拿不到数据时，不妨试试Bypass一下，说不定会有意想不到的惊喜。

所以严格来讲，4xxBypass也是不合适的，因为开发者可以自定义响应码，所有出现什么响应码都不足为奇。希望可以提供一点小小的思路，如果读完这篇文章你有所收获，那笔者会非常开心。

ps：由于笔者水平有限，以上仅为个人理解，如有出错，请轻喷，如果你愿意帮助笔者指出错误，欢迎评论。

参考：

渗透技巧之403绕过【总结】-CSDN博客

浅析403bypass - X1ly?S Bloghttps://x1lys.github.io/2024/07/29/浅析403bypass/)