巷で話題のCSRF攻撃は、ウェブアプリが対策すべきか
最近、CSRFによる掲示板への犯行予告の話が話題になっていますが、その中で「ウェブサイトが対策を怠ったため起きた」「ウェブアプリの脆弱性だ」のような記事やツイートをみかけました。
私は当該ウェブアプリの性質を鑑みると、ウェブアプリの脆弱性とは言い切れず、必ずしもウェブアプリ側で対策しなければならないものではないと考えているため、上記の記事やツイートを見て、違和感を覚えました。他の方々はどのような意見を持っているのか聞いてみたいと思い、普段書かない日記を書くことにしました*1。
そもそもCSRFについて認識がずれていると、意見がかみあわない可能性があるため、まずはCSRFとはナンゾヤというところから整理したいと思います。
CSRF とは何かの整理
CSRFの用語について
CSRFとは、クロスサイト・リクエスト・フォージェリの略です。他のサイトを経由したリクエスト偽装的な意味合いでしょうか。 読み方はシーサーフって読む人もいれば、シーエスアールエフと読む人もいます。私は後者です。
CSRFという単語は、2つの捉え方があります。 一つは攻撃手法で、もう一つが脆弱性の名称です。 ここでは区別するために、攻撃手法を「CSRF攻撃」、脆弱性の名称を「CSRFの脆弱性」と呼びます。
CSRFはどのような脆弱性か
K氏）おまえがやったんだろ！
X氏）いいえ、私はやってません！
K氏）ここに証拠がある！！x月x日xx時に何してた！？
X氏）...たしか変なリンクをクリックしました
＿人人人人人人人人＿
＞ CSRFの脆弱性 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^￣
こんな感じでしょうか。
もう少しまじめに説明すると、CSRFの脆弱性とは利用者に攻撃者が用意したリクエストを送信させ、利用者が意図しない処理を実行させてしまう脆弱性のことです。ウェブアプリにおいて、利用者が意図したリクエストであるかどうかを識別する仕組みがないために起きてしまうものです。
出典：IPAのAppGoatを使った講義の補助資料
なお、CSRFの脆弱性はログイン前提の脆弱性か？という定義に関する問題がありますが、この日記で決着がつく問題ではないため*2、この日記内では「対象のウェブアプリが認証やそれに近い行為により利用者を識別している状態のときに、その利用者に攻撃者が用意したリクエストを送信させ、利用者が意図しない処理を実行させてしまう」ものをCSRFの脆弱性と定義させていただきます*3。
この定義ですと、例えば下記のような事象が発生するとCSRFの脆弱性が存在すると判断できる、と私は考えています。
- ショッピングサイトAは、誰からの注文かを識別し、かつ購入する意図があるのかを確認する必要がある。しかし、ショッピングサイトAにログイン済みの利用者が罠サイトを閲覧しただけで、ショッピングサイトに商品購入リクエストを送信してしまい、ショッピングサイトのウェブアプリが商品購入処理が実行されてしまった。
- ローカルPCで動作するアプリBは、ブラウザ上から各種操作をするアプリであり、暗黙的にローカルPCの利用者のみが使用することを前提としていた。しかし、利用者が罠サイトを閲覧しただけで、アプリBにリクエストを送信してしまい、攻撃者が指定した操作が実行されてしまった。
前者は、認証により利用者を識別している状態です。後者はそれに近い行為により利用者を識別している状態です。 CSRFの脆弱性の定義として、前者は異論ないでしょうが、後者はありそうですね。
しかし、このような広めの脆弱性の定義であっても、巷で話題のCSRF攻撃はウェブアプリの脆弱性ではないと考えています。
次に、話題になっているCSRF攻撃がどのようなものかの認識を合わせたいと思います。
巷で話題になっているCSRF攻撃とは？
声明では、横浜市のホームページに小学校の襲撃予告を書き込んだとして、７月に明治大学の男子学生（１９）が逮捕された事件への関与を詳述し、その方法として、遠隔操作ウイルスは使用せず「クロスサイト・リクエスト・フォージェリ（ＣＳＲＦ）を仕掛けた」と明かしている。
【なりすましウイルス】「閲覧させＰＣ操作」 犯行メールに書き込み 横浜の小学校襲撃予告 - MSN産経ニュース
巷で話題になっているのは、上記の事件のことだと認識しています。
ヨミウリ・オンラインの記事では「市民からの提案」のフォームに問題があったと記載があります（ヨミウリ・オンラインは直リンク禁止らしいのでリンクは載せません）。
上記が事実ならば、CSRF攻撃によって、罠のリンクもしくは罠サイトを閲覧した利用者が、利用者の意図とは無関係に犯行予告をフォームに投稿したことになります。
ここでのポイントは、
- 攻撃者がしかけたCSRF攻撃により、利用者のPCからフォームに犯行予告を投稿させた
- 当該フォームは、(市民からであれば)誰からの意見も受け付けるようフォームであり、利用者を識別するような機能は存在しなかった
でしょうか。
ウェブアプリ側で対策すべきか
さて、ここからが本題です。
巷で話題になっているCSRF攻撃は、ウェブアプリ側で対策すべきでしょうか。
当該フォームは、誰でも意見を投稿できるフォームです。
フォームには公表を希望しない場合のチェックボックスもありますし、「投稿要旨、回答内容等から特定の個人が識別されてしまう恐れがある場合等は公表しません」という記載もありますので、投稿者を識別する機能がなくとも、ウェブアプリの機能上問題ないと思われます。ではなぜ、誰が投稿してもいいはずなのに、CSRF攻撃により他人のPCから犯行予告が投稿できてしまうことが当該ウェブアプリの脆弱性であるかのように（一部で）言われているのでしょうか。
それは、投稿したPCに割り当てられたIPアドレス情報のみで犯人にされてしまう可能性があり、実際に犯人ではないと思われる方が逮捕されている事例が出てきたからだと考えます。たしかにそれは問題ですが、当該ウェブアプリにセキュリティ上の問題があったと言えるでしょうか。
投稿したPCの持ち主が確実に犯人だとは言い切れません。ISPや投稿したPCを保有する組織の協力を得れば、IPアドレスやアクセスした時間から投稿したPCは特定できるかもしれませんが、それだけでは利用者は特定できません。盗んだ自動車で窃盗者が事故を起こしたら自動車の持ち主が逮捕される世の中では困ります。
当該ウェブアプリは投稿した利用者を識別する機能が必要ないのにも関わらず、IPアドレスベースで投稿した利用者であるとされ逮捕されてしまう可能性があることを理由に、ウェブアプリ側で修正すべき問題（脆弱性）であるということになってしまいます。これは逮捕に至るまでの捜査方法の問題ではないでしょうか。*4
以上のような状況を鑑みると、私はウェブアプリの脆弱性とは言い切れず、ウェブアプリ側で対策”すべき”とは言えないと考えています。
ただし、利用者の立場を考えると、逮捕されるかもしれないと怯えながらウェブサイトを閲覧するような状況は好ましくないため、CSRF攻撃への対策をすることは利用者に親切な対応だと思います。
