APIの認可漏れを直す

このレッスンで学ぶこと

認可漏れの直し方には、オブジェクト単位・機能単位・テナントの分離という3種の抜けに共通の型があります。この回はその型を4つに束ねて扱います。

読み終えるころには、直したあとに何を送り、何が変われば塞がったと言えるかを自分で決められるようになります。

判定を1か所に寄せる

エンドポイントごとにif文を散らすと、経路が増えたときに1本書き忘れて穴になります。APIは経路が多く、/v1と/v2のように複数のバージョンが同時に生きます。認可の判定は共通の層に集め、すべてのエンドポイントが必ずそこを通る形にします。散らばった判定は、抜けを数えられません。

既定は拒否にする

明示的に許可した操作だけを通し、それ以外は拒否します。ここには使える非対称があります。許可を書き忘れれば403になって気づけますが、拒否を書き忘れれば素通りして気づけません。新しいエンドポイントを足したとき、何も書かなければ拒否になるようにしておけば、書き忘れが穴でなく403として表に出ます。

番号でなく、所有関係で引く

番号で引いてから持ち主を見るのでなく、はじめから所有を引く条件に混ぜます。

SELECT id, total_yen FROM orders
WHERE id = ? AND owner = ?      -- owner はトークンから

テナントならAND seller_id = ?を足します。見つからなければ404です。所有を引く条件にすると、他人の行はそもそも取り出せず、中身を組み立てる前に落ちます。

直したあと、元の攻撃を再送する

直したら、BOLAを見つけたときと同じリクエスト、tanakaのトークンでsatoの1044を叩く、をそのまま再送します。前は200だったのが404に変わって、はじめて塞がった証明です。同時に、正規の利用、tanakaが自分の1043を読む、が200のままかも見ます。SQLインジェクション編で見た再検証と同じ型で、対象がSQLでなく認可になっただけです。攻撃が止まっただけでは、正規の利用まで壊す直し方も合格にしてしまいます。

手を動かすときは、この4つを1本ずつ通します。確かめるのは自分が権限を持つ練習用の環境だけにします。

まとめ