著作一覧 |
RESTの特性のサーバサイドステートレスという点にこだわりすぎると、CSRF自由自在となってしまう。というよりもどこからでも破壊的なメソッドを受け付けるようにしているのだから、CSRFではなく、単にそういうAPIだということだ。
それらのAPIの最初の時点で認証があれば、少なくともその操作を許可されているのだから(あるいは認証された領域外は許可されていないのだから)あまり考える必要はないと思う。
そうではなく、認証されていないクライアントが所定の遷移に従わなければ破壊的な操作を行えないようにするにはどうすれば良いのだろうか。
すると、HATEOASを使うということを思いつく。いきなり、POST/PUT/PATCH/DELETEできるというAPIでは無く、最初は必ずクライアントからのGETで始まるとする。そして各操作をeditリレーションのリンクで示す。たとえばGETするのが/book/{id}なら、破壊メソッドのURIは、/book/{id}/{key} (keyが破壊許可の識別子)とかすれば良い。
でも、これってセッションIDをパスに埋め込むのと変わらないか。
追記:deleteメソッドにリクエストボディを必要とするAPIみたいなかっこ悪いのはあり得ないことを前提として考える。というか、リソースの要素ではないものが、POST/PUTされるのは気持ち悪い。
ジェズイットを見習え |
キーについてはクライアント毎に変えなきゃいけなくなり、それをサーバーが保持しなければいけなくなるので、スレートフルになってしまいますよね。<br><br>> deleteメソッドにリクエストボディを必要とするAPIみたいなかっこ悪いのはあり得ないことを前提として考える。というか、リソースの要素ではないものが、POST/PUTされるのは気持ち悪い。<br><br>独自ヘッダにパスワードなどの情報を書くのはどうでしょうか。
ETagを使った楽観ロックとして考えるのはどうかな? ETagを上限時間とパスワードの合成とするとか。時間はハッシュできない(ソルトにはできるか)けど見えても困るものでもないし。
CSRF を防ぐ上では、別に上限時間はいらないと思うのです。なぜかというと、パスワードがばれたらそれはセッションハイジャック (セッションはないけど似たような物) なので、ばれないという前提である必要があります。パスワードにハッシュかけるくらいは念のためすべきかも。弱い ETag (リソースが変化しても変わらない ETag) としてパスワードを送ればいいかなーと。
ETag はリソースがかわったら変わらないとおかしいか。すみません酔っ払ってました。