■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、
「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。
と書いた。あれから2か月以上が経ってしまったが、今書いておく。
端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」
と考えられてきたためではないか。
荒らし対策をするしないは運営者の自由
あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して
欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって
生じ得る危険性の種類によって異なる。
たとえば、IPA
の脆弱性届出状況の統計資料の付表には、脆弱性の種類として「価格等の
改ざん」という項目があり、深刻度が「低」とされている。
そして、昨年10月に公表された資料には、
ウェブアプリケーションの脆弱性については、修正を完了したものが10 件、
脆弱性を運用で回避したものが4 件、ウェブサイト運営者
により脆弱性はないと判断されたものが5 件あります。
とある。運用で回避とされたものがどのようなものかわからないが、
「価格等の改ざん」の脆弱性であれば、たしかに運用で回避できることもある。
「価格等の改ざん」とは、「Hidden Field Manipulation」とか「Parameter
Tampering」と呼ばれるものの一種にあたるのだが、hiddenなパラメータを
をブラウザ側で操作するというのは、なにも価格情報だけではなく、
ユーザ名やセッションIDを書き換えるのだって、そのパラメータが hidden
フィールドに配置されていれば、hidden field manipulationということにな
るのであって、そのパラメータの内容が何なのかによって、それが脆弱性にな
るのか、どんな危険性をもたらすのかは大きく異なってくる。
価格改ざんの脆弱性とは、比較的小規模なネットショップに存在する。小規模
サイト用の簡易ショッピングカートシステムでは、サーバ側でセッション管理
をせず、前のページから次のページへの情報の伝達をすべて、hiddenフィール
ドに載せて、サーバとブラウザ間を行ったり来たりさせる仕組みになっている
ものがある。商品のページに商品コードと単価が掲載されており、そこをクリッ
クすると、カートに商品番号と、注文数、そして単価が格納される。これが
HTMLのhiddenパラメータに載せられて、次のページである商品発送先住所入力
画面の見えないところに埋め込まれ、注文確定ボタンを押すと、それらのデー
タがサーバ側で注文として記録処理されるという仕組みである。このとき、最
後のページで、単価を差し替えて送信してしまえば、価格を偽って（安く）買
い物ができてしまうという問題である。
これはいわば、バーコードのなかった何十年前のスーパーマーケットで、商品
に貼られた単価シールを別の商品のものに張り替えてレジに持っていくという、
詐欺行為に相当するものだろう。
これはたしかにセキュリティ脆弱性ではあるが、これによって被害を受けるの
は、サイト運営者のみである。
もちろん、システム構築者の立場や、脆弱性監査を行う者の立場からすれば、
この脆弱性はチェックが欠かせないものに違いない。だが、第三者がこの脆弱
性を発見して、サイトに直せと要求するのは滑稽ではなかろうか。
第三者による脆弱性の指摘に不快感を示す者がしばしば持ち出す喩えとして、
「『お宅の玄関、鍵が開いていますよ』と言うようなものだ」という話があり
（つまり、善意の押し付けであるという主張があり）、それに対して、「そう
いう喩えは不適切だ」とする主張も見られるのだが、価格改ざんの脆弱性を第
三者が指摘するというのはまさに「お宅の玄関、鍵が開いてますよ」と言う
レベルのものだ。
IPAへの脆弱性届出は、そういった押し付けのための制度ではない。そのこと
は、制度の根拠となっている経済産業省の告示の中でも次のように書かれてい
る。
IV. 本基準の適用範囲
本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が
不特定多数の者に影響を及ぼし得るものに適用する。
ソフトウエア等脆弱性関連情報取扱基準, 平成16年経済産業省告示 第235号
価格改ざんは「不特定多数の者に影響を及ぼし得るもの」にあたらないだろう。
運営者が「運用で回避」と言って直さないというのは自由である。
IPAはその届出に対し、制度の趣旨の適用範囲外であるとして、不受理として
も差し支えなかったのではないかとさえ思う。
それと同様に、たとえば誰でも書ける掲示板において、荒らし行為を防ぎきれ
ていない「脆弱性」があるとして、それを外部から「おたく、まだ荒らされる
可能性がありますよ」と言って、「脆弱性の指摘だ」と称するのは滑稽である。
IPAへの届出で期待されているのは、サイトの利用者に被害が及ぶ種類の脆弱
性である。特に、プライバシー情報が漏えいするものは、取り返しがつかない
という点で特に重要性が高くなる。この場合は、「お宅の玄関、鍵が開いてま
すよ」ではなく、「御社の顧客名簿が外から見えそうなのですが」ということ
に相当する。
これらの違いを区別することは重要である。
クロスサイトスクリプティング（XSS）脆弱性は、HTMLタグの「<」と「>」な
どをエスケープするところに要点があるが、それと同じことが、掲示板荒らし
対策として考えられていた時代もあった。つまり、タグを書き込めない仕様と
なっている掲示板において、タグを書き込めてしまう方法が残っていると、
巨大な文字サイズをFONTタグで指定して荒らすとか、音の鳴るタグを埋め込ん
で荒らすといった行為が横行していた。荒らす者の勝手な言い分として、「お
たくのセキュリティが甘いからですよ」などと主張することもあったようだ。
そのような種類の問題では、外部から直すべきだと主張する妥当性は低い。
しかしそれが、cookieの漏えいがひき起こされてセッションハイジャック攻撃
に遭うとか、ページ内容を差し替えられてフィッシングに騙されやすくなるといっ
た問題として理解されるようになって初めて、対策の必要な脆弱性として認識
されるようになったわけである。
CSRF攻撃の脅威は荒らし行為だけか
CSRFも、荒らし対策された掲示板への攻撃手法として使われる。たとえば、
荒らし書き込みをしていた人物が、発信元IPアドレスで書き込みを禁止された
場合などに、CSRFを使って他人のブラウザに荒らし書き込みをさせることで荒
らし行為を成功させるということがある。こうした攻撃は２ちゃんねる掲示板
などでも一時期は頻発し、Referer:フィールドのチェックといった方法で対策
されたという経緯がある。
4月27日
の日記で参照した@ITの記
事でも、CSRF対策が荒らし対策と混同されている様子がうかがえる。
記事中の対策方法を挙げている部分で、CAPTCHA方式が持ち出されているが、
CAPTCHAは、機械による自動処理を防止するための仕組みであり、荒らし行為
を防ぐための最後の砦なのであって、CSRF対策に必要なものというわけでは
ない。
掲示板以外、たとえばネットショップのWebアプリケーションにおいて、CSRF
の脅威があるかどうか、そしてそれはどんな脅威なのかというと、まず、
おそらく、登録している個人情報を変更させられてしまうといったものが多い
のではないかと思われる。ユーザがそのサイトにログイン中のときに罠のペー
ジにアクセスしてしまうと、個人情報変更ページに差し替えデータとともに
POSTアクセスさせられるといったものだ。
他には、商品注文画面を連続的にアクセスさせられることによって注文を自動
確定させられるといった被害や、アカウントを削除させられるという被害も考
えられる。
しかしこれも、荒らし行為の延長に過ぎないとみなすこともできる。そうした
操作は、運営者によってキャンセルすることが可能な場合が多いと思われるか
らだ。ユーザが異変に気付くことができるならば、事態が発覚してサイト運営
者が対応を余儀なくされるという点で、運営者に対する業務妨害行為だとみる
こともできるだろう。業務妨害にあたるような攻撃は防ぎきれないのであって、
どこまで技術的に対策するかは、運営者の自由だといえる。
だが、CSRFの脅威は、そうした荒らし行為の部類のものに限られるわけではな
い。
たとえば、4月19日の「水無月ばけらのえび日記」などにも書かれているように、
パスワード変更機能で旧パスワードの同時入力がないと、CSRFによってパスワー
ドを強制的に任意の文字列に変更されてしまうという脅威があることになる。
変更したパスワードで不正アクセスされれば、それによって起きる被害は、
ユーザに降りかかってくる。
他にも、ログイン中のWeb操作で変更が可能な設定項目によって、公開か非公
開かを変更できるようなシステムの場合、非公開にしていたはずのコンテンツ
を、CSRF攻撃によっていつのまにか公開に設定変更させられていたという被害
が考えられる。この被害はユーザにとって取り返しのつかない事態となり得る
ので、サービス提供者にそうした被害につながるCSRFへの対策を求めることの
妥当性は、高いものとなる。
4月にCSRFを有名にさせた「ぼくはまちちゃん」事件の舞台となった mixiのよ
うに、SNSとかblogのWebアプリケーションは、まさにそうした設定項目を持つ
ことが多く、その点で、最近になって脅威の高いCSRF脆弱性が増していると言
うことができる。
CSRF対策が遅れる理由
センスある開発技術者の立場からすれば、「あんな対策も必要、こんな対策も
必要」と言われることは、プログラミング美学に反すると感じられることもあ
る。
XSSやSQLなどのインジェクション系の脆弱性は、脆弱性であるという以前に、
本来正しいコーディングをしていればそういう穴にはならないのだから、
美学に反するものではない。バッファーオーバーフローもそうだ。
センスある開発技術者にとっては「対策」不要というのが美学だ。
その点、CSRF対策が必要というのは、どうにも気持ち悪いものとなる。
画面の遷移をすべてチェックするというのであればまだわかるが、
一部の画面に姑息な手段で対策を仕掛けないといけないとなると、なんだか
美しくないように感じられる。
対策方法はできるだけシンプルであるのが美しい。CAPTCHAなどという大掛か
りなものまで持ち出されたら、「なんか違うんじゃないか？」とか、
「えーそこまでしないといかんの？？」という反応になるだろう。
対策が美しくないのだとしても、ユーザに重大な脅威をもたらすCSRF攻撃の
弱点があるならば、対策はしなくてはならない。しかたがない。
だが、ユーザに致命的な被害が及ばない種類の脅威、つまり「荒らし対策」の
ような種類のものについてまで、「直せ」と外部から言われたら、開発技術者
は反発してしまうかもしれない。
@IT
の記事は、
Webサイトの運営者はエンドユーザーに期待せず、十分にCSRF対策を行っていただきたい。また、読者の皆さんがCSRF攻撃が可能になっているWebサイトを発見した場合には、Webサイトの管理者なり、IPAなりに適切に報告して欲しい。
と締めくくられていたが、こんなふうに書かれると、荒らし攻撃の部類に入る
ものまで、IPAに届け出られるのではないかと心配になった。
サイト運営者に修正を促すような脆弱性報告をするときは、その脆弱性によっ
てもたらされる脅威の重大性を示した上で報告するべきである。
（追記する予定）
（7月10日追記）
これまでの経緯
過去に国内でCSRFに相当する脆弱性のことが話題になっていたかといえば、
2001年7月に「セキュリティホールmemo」メーリングリストに投稿された[memo:846]
が思い起こされる。このときは「セッション管理の脆弱性」という名称で呼ば
れた。その名称は適切でないと思った記憶がある。セッション管理上の何にど
ういう原因があるのかを示唆しない名称であるし、しばしば別の種類の脆弱性
を指す言葉として用いられることもある言葉だ。
このとき、あまり反応がなかったのを覚えている。メーリングリストでのフォ
ローアップも[memo:851]
の一件しかなかった。「セキュリティホールmemo」での取り扱いも次のように
そっけないものだった。
セッション管理の脆弱性
([memo:846], Tue, 17 Jul 2001 18:40:51 +0900)
HTTP を通じたセッション管理における脆弱性と回避方法の考察。 Referer
リクエストヘッダの除去 にもこの記事の記述を追加しました。
セキュリティホールmemo, 2001年7月18日
当時の私の感想は、「こういう脆弱性は無数にある」「やばいな」「やばいか
もしれないが深刻さは相対的に小さめだ」というものだったような記憶がある。
その後も、無線LANルータを買うたびに設定画面とかが危ないのではないかと
たびたび心配になることもあったが、攻撃者の動機が少ないであろうことや、
攻撃が成功するには、別途必要な情報がある（たとえばルータのIPアドレス）
場合が多かったり、被害者のログイン中にしか成功しないことなどから、問題
点を製品開発者に伝えても直してもらえないだろう（おそらく、「設定を終え
たらブラウザを終了してください」という注意文が公表されるだけで終わる）
と予想していた。
他に重要な脆弱性があって、そっちの啓発をしなくてはならない状況において、
開発者に「直さない」という判断をさせるような問題を同時に扱ってしまうと、
脆弱性問題全体の啓発に支障が出かねないということを考えた記憶もある。
しかし時が過ぎるとともに、こうした受動的攻撃（被害者に罠を踏ませること
で発動する攻撃）が予想を超えて現実のものとなっていった。転機となったの
はその2か月後のNimdaワームの蔓延あたりだろうか。さらには、ここ2年ほど
で、phishingが大きな被害を出したことから、受動的攻撃を無差別メール経由
で発動させることが有効な攻撃として十分に成立することが明らかになったし、
スパイウェアやpharmingの手口を見るにつけ、金銭目的による犯行ならば、成
功する確率が低くても攻撃者にとっては見合うらしいことがはっきりとしてき
た。
また、SNSやblogサービスなどのように、ログインしたまま使うサービスが増
えたことも状況を変化させてきている。昨年の5月には、「はてな」の近藤社長とお会いした機会に、
罠リンクを踏むとアカウントを消される問題について口頭で伝えていた。その
後、9月にも別の方からの指摘があったらしく、「は
てな」はこの種の脆弱性を修正したらしい。
いよいよこの種の問題の啓発を進めないといけないかもしれないな、と思いつ
つも、どう進めていってよいか道筋が見えなかった。昨年11月のInternet
Week 2005のチュートリアル「安全なWebアプリ開発の鉄則 2004」では、36
枚目のスライドでこの種の脆弱性を扱った。
このときのタイトルは「きわどい操作を強制させられる」としていた。
この時点では「CSRF」という呼び方を知らなかった。
そしてその半月後、「ほほう、いよいよこの脆弱性に名前がついたんだな」と
思ったのが、securityfocus.com の webappsecメーリングリストにアナウンス
が投稿されて知ったホワイトペーパー「Session Riding ― A Widespread Vulnerability in Today’s Web Applications」だった。
この論文は冒頭で次のように主張している。
In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF) [1]. It seems, though, that it has been neglected by the software development and Web Application Security community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten [2] or the like. （略）
We prefer to call this issue Session Riding which more figuratively
illustrates what is going on.
（私訳）
この論文では、2001年にCross-Site Request Forgeries (CSRF) の名称の下で
提起された問題点について述べる。これは、しかし、ソフトウェア開発のコミュ
ニティにも、Webアプリケーションセキュリティのコミュニティにも無視され
てきたように思える。最近のWebアプリケーションセキュリティの議論の対象
になっていないし、OWASPのトップ10やそれに類するものでも触れられていな
い。（略）
我々は、この問題のことを、何が起きるのかをより比喩的に言い表して、
Session Ridingと呼ぶのを好む。
Thomas Schreiber, Session Riding
― A Widespread Vulnerability in Today's Web Applications, 2004年12月
CSRF対策が進まないのは日本に固有のことではなく、国際的にもいくらか同様
の状況があったとみえる。CSRFの名称は確かに 2001年6月のBUGTRAQへの投稿
が初出のようで、調べてみると、自分も受信していて、「重要」のマークを付
けていた。後で読むつもりで読んでなかったのか、記憶に残らなかったのかは
わからない。
- Cross-Site
Request Forgeries (Re: The Dangers of Allowing Users to Post Images),
BUGTRAQ, 2001年6月15日
Subject: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)
Date: Fri, 15 Jun 2001 01:15:42 -0400
From: Peter W <peterw@usa.net>
Cross-Site Request Forgeries
(CSRF, pronounced "sea surf")
I hope you don't mind if I expand on this a bit. You've come across the
tip, in my opinion, of a rather large iceberg. It's another
Web/trust-relationship problem. Many Web applications are fairly good at
identifying users and understanding requests, but terrible at verifying
origins and intent.
（略）
調べてみると、「CSRF」はwebappsecでは、2001年12月に一度話題になったも
のの、次に登場するのは2003年1月に一度、その次は2004年3月、次は8月、そ
して12月の論文紹介と、たしかに話題になることが少なかったようだ。それが
2005年になると、1月、2月、3月、4月、6月と毎月のように話題となっている。
問題提起が憚られるもうひとつの理由
「CSRF」ないし「Session Riding」の名前を使い、キーワードを連呼して啓発
するというのが適切でないというのは、先に書いたとおり、それによって起き
得る被害の性質に大きな幅があるためなのだが、重大な結果をもたらし得るケー
スについても対策が進まなかった理由として、次の懸念もあったのではないか。
CSRFによる被害が出たとき、罠を仕掛けた攻撃者の行為は、日本の法律に照ら
して違法となるだろうか？
アクセスをするのは被害者自身によるものであるし、そのアクセス自体は制限
された利用の制限を免れるものではないので、不正アクセス禁止法には触れな
いと思われる。
荒らし行為が行われれば、業務妨害罪による立件もあり得ると思われるが、特
定の個人だけを狙ったCSRFの場合には、業務妨害とするのも無理かもしれない。
刑法改正で予
定されている「不正指令電磁的記録作成等の罪」ならば、こうした行為を
罪に問えるかもしれない。これは俗に「ウイルス作成罪」と呼ばれてきたもの
であるが、改正案の条文は次のようになっており、いわゆるウイルスのみでな
く、受動的攻撃全般をも指すようにも解釈できそうである。
人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録
この法改正が必要とされていることからも、現行法で受動的攻撃のようなもの
をカバーしきれていないことがうかがえるところであり、この刑法改正は、
CSRF攻撃も抑止できるかもしれないという意味で歓迎されるところであるが、
去年もこの改正は見送られており、いまだその抑止効果は有効になっていない。
この状況で下手にCSRFの危険性を主張しはじめると、違法でなければ何をやっ
てもよいという輩が、悪戯を繰り返して被害を出しかねないという懸念もあっ
たのではなかろうか。
XSS脆弱性の場合は、罠によって他人に他所のドメインのページの画面上でス
クリプトを実行させるところまでは、CSRF同様に罪に問えないと思われるが、
それによって盗んだcookie（セッションID）を使って当該サイトにセッション
ハイジャックのアクセスをした時点で、不正アクセス禁止法3条2項2号違反と
なると思われるため、安心して啓発活動をすることができた。
そうした法律による保護が、CSRFに対してはまだできていないため、誰も問題
提起せずに来てしまったのではなかろうか。
mixiの事件以来、既に大きく話題になってしまった以上、荒らし行為では済ま
ないような（つまり、情報漏洩など、取り返しのつかない結果をもたらす）
CSRF脆弱性についてはいまこそ対策を進めるべきであろう。
