総仕上げ権限の穴を見つける｜認証・認可の脆弱性

このレッスンで学ぶこと

権限の穴の点検は、ここまで見てきた崩れ方を、口1本に何を送り、どの応答を見て、何を疑うかの順番にする作業です。この章の締めくくりとして、練習用のショップでそれを通します。

読み終えると、1本の口に5つの問いを順に当てて、見つけた崩れに名前を付けられるようになります。

点検の順番

エンドポイントを1つ選んだら、上から順に当てはめます。

役割。一般利用者tanakaのログインのまま、管理者用の口が開けるか。開けるなら垂直の権限昇格です
持ち主。自分の資源の番号を、別の利用者の番号に変えて開けるか。開けるなら水平の権限漏れ、名前を付ければIDOR、API側から見ればBOLAです
役割の出どころ。リクエストやCookie、JWTのペイロードにroleがあり、それを書き換えると判定が変わるか。変わるなら名乗りを信じています
操作。GETが守られていても、PUTやDELETEが素通りしないか。メソッドの上書きヘッダで緩い入口をくぐれないか
テナント。出店者Aのまま、出店者Bの店の資源が引けるか。引けるならテナントの条件が抜けています

練習用のショップで通す

/api/orders/1043を例にします。まず自分の注文で200が返る基準を作り、番号を1044に変えて他人の注文が出れば2番の水平の漏れです。同じ番号をDELETEで消せるか試して、消えれば4番の操作の抜けです。次に/admin/usersをtanakaのまま開いて、返れば1番の垂直の昇格です。出店者Aで入り直し、/api/orders/2087で他店の注文が引ければ5番のテナントの漏れです。

プレーンテキスト

GET    /api/orders/1044   他人の注文が出る → 水平/IDOR
DELETE /api/orders/1043   消せる → 操作の抜け
GET    /admin/users       tanaka で開ける → 垂直
GET    /api/orders/2087   他店が引ける → テナント

どの応答も、読み方は前の章から同じです。正常な反応を基準に置き、探りの反応との差を見ます。他人の資源が読めた口では、直したあとに、拒否の応答が存在しない資源と同じ形になっているかまで確かめてください。

直しの結論はどの崩れでも同じ場所に集まる

5つの崩れは入口が違っても、直しはサーバー側の1か所に判定を寄せ、既定を拒否にすることに収束します。点検で見つけた穴ごとに別々の対策を貼るのではなく、判定の抜けている口を、共通の関門に通す形へ寄せてください。

まとめ