Hello there, ('ω')ノ
1. プラットフォーム層でのアクセス制御とは？
一部のアプリケーションでは、サーバーやアプリケーションフレームワークの設定によってアクセス制御を行います。 例えば：
DENY: POST, /admin/deleteUser, managers
これは「managers グループのユーザーが /admin/deleteUser に POST リクエストを送るのを拒否」という意味です。
しかし、この設定方法には複数の抜け道があります。
2. URLベースのアクセス制御を回避する手口
a. 特殊なHTTPヘッダーでURLを上書き
一部のフレームワークは X-Original-URL や X-Rewrite-URL などのHTTPヘッダーをサポートしています。
例：
POST / HTTP/1.1 X-Original-URL: /admin/deleteUser
こうすると、フロント側のURLチェックをすり抜けて本来禁止されている処理を実行できる場合があります。
b. HTTPメソッドを変える
アクセス制御が「URL＋HTTPメソッド」に依存している場合、許可されていない POST の代わりに GET や他のメソッドで実行できるケースがあります。
例：
GET /admin/deleteUser
これが成功すれば、メソッドベースの制御は無効化されます。
c. URL表記の違いによる回避
プラットフォームやアプリケーションは、URLの大文字小文字や末尾のスラッシュに対して寛容な場合があります。
例：
/ADMIN/DELETEUSER→ 実際は/admin/deleteUserと同じエンドポイントに到達/admin/deleteUser/→/admin/deleteUserと同じ扱い
もしアクセス制御側がこれらを別エンドポイントとみなすと、制御がすり抜けます。
d. 拡張子付きURLの利用（Springの例）
Springフレームワークの useSuffixPatternMatch が有効だと、
/admin/deleteUser.anything → /admin/deleteUser にマッピングされます。
Spring 5.3以前ではデフォルトで有効だったため、これを悪用できることがあります。
3. 水平権限昇格（Horizontal Privilege Escalation）
これは、他人のデータや機能にアクセスできてしまう脆弱性です。 多くの場合、URLやパラメータの値を変えるだけで発生します。
例：
https://insecure-website.com/myaccount?id=123
id=124 に変更すると、他ユーザーのアカウントにアクセスできてしまうことがあります。
このように、ユーザーが直接オブジェクト（データIDなど）を指定できる実装は、IDOR（Insecure Direct Object Reference） と呼ばれる脆弱性を生みます。
4. 脆弱性発見のコツ
- HTTPヘッダーを確認
X-Original-URLやX-Rewrite-URLの挙動を試す。 - HTTPメソッドを切り替えて送信 POST → GET / DELETE → PUT など。
- URLの大文字小文字、末尾のスラッシュ、拡張子追加を試す。
- パラメータを他人の値に変更（IDORの確認）。
Best regards, (^^ゞ
