自分への戒めのためのメモ(CSRF編)

「サービスを作るのは大事だけどユーザーに迷惑かけちゃいけない」


バグがあってもセキュリティに問題があってもいけない。

昨日はCSRFのことがふっとド忘れしまったので、ここに書いておいて忘れないようにする。
歳を取っているという証拠かｗ

CSRF: クロスサイトリクエストフォージェリ
具体例として、掲示板に意図しない書き込みをさせられたり、オンラインショップで買い物をさせられたりするなどの被害が起こる。

攻撃の大まかな流れは以下の通り。 

簡単な HTML を例示して、その原理を具体的に解説する。

1.攻撃者が、攻撃用の Web ページを作成して WWW 上に公開する。

（WWW上ででなくとも、未対策のHTMLメーラーにウェブページをHTMLメールとして送信するだけでもよい。） 

2.第三者が、攻撃用の Web ページにアクセスする。

3.第三者は、攻撃者が用意した任意の HTTP リクエストを送信させられる。 

4.送信させられた HTTP リクエストによって、攻撃者の意図した操作が行われる。

（ここで「第三者」とは、被攻撃サイトに意図せずアクセスさせられると言う意味で用いている。）

(Wikipediaより引用)

iframeでbody onloadでフォームにsubmitするようなhtmlを読ませて自動的に掲示板に書き込みを行わせる等が例としてあげられていた。

利用者側の対策としては、Cookieに依存した攻撃があるのでCookieをこまめに破棄することとか。

サイト運営者側の対策としては、

第三者が知り得ない情報をフォームに入力させる（あるいはフォームの hidden パラメータに設定しておく）というのが基本的な対策方針である。  

ここで利用する第三者が知り得ない情報は、推測されにくい文字列であり、かつ総当り攻撃に対して耐性がある必要がある。具体的には以下の方法が挙げられる。

認証情報を入力させる
認証制の Web システムの場合、入力フォームにユーザIDとパスワードを含めるという方法がある。システムの利用者から見れば、既にログイン画面で認証を行っているため冗長な操作であるが、クロスサイトリクエストフォージェリの対策としては最も効果がある。 

ワンタイムトークンを利用する
入力フォームに、第三者に推測されにくい文字列を hidden パラメータとして指定しておき、フォームの情報を受け取る段階でそのパラメータの整合性をチェックするという方法である。そのパラメータが整合性のチェックでしか使われない一時的なデータであることが多いために「ワンタイムトークン」と呼ばれる。但し、第三者が知り得ない情報として有効である限りは、必ずしも「ワンタイム」である必要は無い。 

また、CAPTCHAなどが対策として挙げられる文献もあるが、このようなチューリングテストはボットによる分散・多発型攻撃への一般的な対策であり、必ずしも推測されにくい文字列であることや、総当り攻撃に対して耐性があることを保証するものではないため、CAPTCHAで表示される文字列について別途セキュリティ的な観点で評価する必要がある。

(Wikipediaより引用)

ということでした。

hiddenパラメータはjsからでもsubmitされたらpostされるんじゃないのか？という疑問があるから
個人的に対策としては認証かワンタイムパスワードかCAPTCHAを使うことにします。

悪さしようと思えばできそうな気もするし。

それに僕はReCAPTCHAが好き。