HTTPメソッドで変わる権限チェック

このレッスンで学ぶこと

HTTPメソッドで変わる権限チェックとは、読む・書き換える・消すという操作のそれぞれに判定が要るという話です。この回はその判定が操作ごとに揃っているかを、同じURLに違うメソッドを送って確かめます。

読み終えると、1つのURLに対して確かめるべき操作を、画面に出ない分まで列挙できるようになります。

読み取りは守り、削除は素通り

練習用のショップで、/api/orders/1043をGETで開くときは、水平の回で入れた持ち主の確認が効いています。ところが同じ資源をDELETEで消そうとすると、確認を通らず消せてしまうことがあります。

GET    /api/orders/1043   → 持ち主を確かめる。他人のものは拒否
DELETE /api/orders/1043   → 確かめずに消える

原因は、認可の判定を読み取りの経路にだけ書いて、書き換えや削除の経路に同じ判定を通していないことです。人は画面から使う「開く」ばかりを見て守りを入れ、画面に出ないPUTやDELETEを見落とします。同じURLでも、操作が変われば別の判定が要るのに、1つの操作にだけ守りを入れて安心してしまうのです。

メソッドの上書きで、守りを回り込む

もう1つ、メソッドそのものを偽る迂回があります。一部のサーバーは、POSTで送りつつX-HTTP-Method-Overrideというヘッダや_methodという項目で「本当はDELETEとして扱ってほしい」と指定できる作りになっています。

POST /api/orders/1043
X-HTTP-Method-Override: DELETE
  → 入口は POST に見えるので POST 用の緩い守りを通る
  → 中では DELETE として実行される

POSTだけを見て守りを判断していると、上書きヘッダで宣言された本当の操作が、緩いほうの入口をくぐって実行されます。この上書きに対応するかは製品や設定によって違うので、自分の環境が受け付けるかをまず確かめてください。

直し方は、操作ごとに同じ判定を通す

認可は、読む・書き換える・消すのそれぞれで判定します。1つの資源に対する守りを、操作ごとに書き分けず、同じ持ち主の確認をすべての操作が通る場所に置くのが確実です。メソッドの上書きを使わないなら受け付けない設定にし、使うなら上書き後の本当の操作に対して判定してください。

まとめ