総仕上げ APIの認可漏れを見つけて直す

このレッスンで学ぶこと

総仕上げは、この章で見た認可漏れと直しの型を、練習用のショップのAPIを1本ずつ点検する手順に組み直す回です。新しい話は足しません。

読み終えるころには、3本の口を一つの表で点検し、引っかかった口を直して再送まで通せるようになります。

まず、点検する口を並べる

出発点は攻撃面の地図です。ドキュメントに無い経路、/v1と/v2のように併存するバージョン、1つのURLに多数の操作が集まる口も含めて、認可の判定が要るエンドポイントを列挙します。画面が無いAPIでは、載っている口だけを見ても足りません。機械で叩ける口はすべて点検の対象です。

ここに、この章の背骨があります。画面のあるアプリなら、他人の注文や管理者向けの操作は、そもそも導線が表に出ていませんでした。APIにはその画面が無く、URLを知って叩けば口は応答します。だから直しを1本入れても、古いバージョンや見落とした経路が同じ穴を残していれば、攻撃は別の口から通ります。点検は「直したい口」ではなく「叩ける口すべて」を数えるところから始めます。

各エンドポイントに、同じ4つを問う

並べた口の1本ずつに、次を順に当てます。

1 データを返すか → 持ち主を見ているか（オブジェクト単位）
2 操作か         → 役割を見ているか（機能単位）
3 テナントの行か → クエリが出店者で絞っているか
4 直したあとは   → 元の攻撃を再送して塞がりを確かめたか

1では、自分のふたつのアカウントで番号を差し替え、tanakaのトークンでsatoの1044を叩いて200と404と403を読み分けます。2では、tanakaのトークンのまま/admin/usersを叩き、管理操作が通らないかを見ます。3では、midoriのトークンで一覧を取り、aobaのsellerが混じらないかを見ます。4では、直したあとに前と同じ攻撃を再送し、応答が変わったことと正規の利用が保たれたことを併せて見ます。

手を動かす

練習用の環境で、注文を返す/api/orders/1044、管理者向けの/admin/users、出店者の一覧の3本を順に点検します。それぞれがどの問いで引っかかるかを1つの表にし、送った要求とトークンと状態コードと返ったデータの持ち主を、口ごとに書き足していきます。引っかかった口には所有や役割やテナントの条件を足して直します。直したら必ず、その口で前に通った攻撃をもう一度送り、404や403に変わったこと、そして正規の利用が200のまま残っていることを確かめます。認可は画面ではなく、リクエスト1本ごとにサーバーの側で決まります。確かめるのは自分が権限を持つ練習用の環境だけにします。

まとめ