kensyou_jikenboのブログ

yahoo!ブログの同名ブログを移行しました

CSRFとReferer（続き）

日記 #練習用
昨日の図は、「市民からの提案」ページへの正常なアクセス例を示したものである。
想定としては以下の(1)～(4)の流れの内、(1)を除くページを記載した図になっている。
　　(1)googleで「横浜市役所」を検索
　　(2)検索結果ページで横浜市役所の「トップページ」をクリック
　　(3)トップページの「ご意見・ご提案」をクリックする
　　(4)「市民からの提案」投稿フォームに書き込む
現在の横浜市役所のHPでは(3)と(4)の間にも幾つかページがあるが、説明用に省略して簡略化した。
また(1)と(2)は必須なルートではなく、流れをわかりやすくするために付加したもので、(3)に至るまでは別のルートでも構わない。

ポイントは本来の画面遷移設計上で、「(4)投稿フォームへは(3)トップページにある「ご意見・ご提案」のクリックで遷移するルートしか想定していない」と云うことである。
ユーザーは、（4)へ直接遷移する必要はなく、常に(3)から遷移することで操作上の問題はない。

それに対して別サイトから攻撃するCSRFでは、直接(4)投稿フォームのページに遷移してくるので、昨日図の右下欄のようにrefererがハッキリ違ってきて異常なルートであることが分かってしまう。
よって、正常ルートのreferer(この場合はトップページURL)を持ったアクセスしか許可しなければ、この投稿フォームのCSRF対策は出来てしまう。

ただ、refererを送らないブラウザ設定やウィルス対策ソフトもあるので、正常なアクセスでもrefererを送ってこない場合が有り得て、それを弾いてしまうとサイトを見れない人が出てくる。
そのような事があってrefererによるCSRF対策は余り推奨されていない。
また、別サイトからのアクセスではrefererを変更することは基本的に困難であるが、変更する方法も存在する模様。

だが、重要なことは横浜CSRF事件では、referer無しや変更は関係ないということである。
何故なら神奈川県警の報告書にあるように、サーバーログ中に正常ルートではないアクセスを示すrefererが送られてきていたからである。
犯人はreferer無しにすることや変更を行っておらず、ログを見ればCSRFということは一目瞭然だった。（参考用のログ例を追記で示す）

分かってみれば当たり前のことなのだが、これに気がついた時は以前にご紹介した「江ノ島でA子さんがマイクロSDカードをGPSと誤認しなければ首輪は外されていた」こと以上の驚きだった。
神奈川県警では以下の3つがたまたま揃ったのでCSRFと気が付かなかった。
　　(ⅰ)解析担当者がrefererの知見がなかった
　　(ⅱ)同じくCSRFも知らなかった
　　(ⅲ)サイバーセンターには両方を知っている人がいたのに伝わらなかった
サイバー捜査をやったにも関わらず、よくこのようなことが起きたものである。

報告書でも以下のように「CSRFやrefererは専門家にとって比較的容易に思い至る」ということも認めている。
　＜より高度な専門性と知見を有する情報通信部と問題点を共有し、解決策を
　検討していれば、ＣＳＲＦやリファラーといった、専門家にとっては比較的
　容易に思い至る問題点を早期に認識し、的確な対策が図られていた可能性がある。＞
実際は「比較的」も不要で、サイバー捜査では初期段階で疑う項目だろう。
報告書は他にも「なりすまし」を発見できなかった要因を書いているが、ごく普通に捜査していれば250文字2秒問題等に至る前になりすましを判定できていたのである。

そしてもっと驚くのは犯人の認識の方。
ラストメッセージでCSRFの工夫について詳細に説明しているが、それら工夫は本来であれば全く意味がなかったことになる。
基本中の基本と云えるrefererがそのままでは、肝心の部分の考慮が抜けている。

ただ、CSRFで他人のPCから犯行予告させるだけなら充分成功の部類と云えるだろう。
しかし、犯人は誤認逮捕を狙っていた。
そのために被害者のブラウザキャッシュ履歴に横浜市役所や小学校のページなども残すように細工していたが、それをやっても本来はrefererで容易に見破られる。
これでは被害者は任意で聴取されることはあっても誤認逮捕には至らない。
たまたま捜査側のミスの重なりで目論見通りになっただけなのに、犯人はラストメッセージで分かってみれば無意味な工夫を長々と説明したことになる。
犯人はそこまで大間抜けな人物なのか。

個人的には犯人がCSRFをやろうと考えて調べたとしたら、すぐにrefererのことは出てくるから知らなかったことは有りえないと思う。
また、犯人はラストメッセージで「横浜市サイトに脆弱性があったのを見つけた」と書いているので、脆弱性を事前に調査していたことになる。
その時にはまず「サイトがrefererをチェックしているかどうか？」を調べるのが先決なので、ブラウザでrefererを送らない設定にしてアクセスできるか調べたことが考えられる。
つまり、犯人はrefererについて知見があったと想定されるのである（但し当方見解）。
それなのに「referer対策しないで何故誤認逮捕が可能と考えたのか？」という大きな疑問が出てくる。
調べれば調べるほど犯人の意図が不明になってきてしまう。

以上
[追記]
サーバー側ログではないが、当方が横浜市役所にアクセスしてみてPC側で取ったログを参考に示す。
基本的にはPC側から送った内容からサーバーログに記録されるので、当方のログとサーバーログは同じような内容になると考えられる。
・ログの様子（1行毎にログが次々と記録されている）
イメージ 1

・一つの行を取り出してみる
----------------------------------------
2014-04-xx- xx:xx:xx,xxxxxx,xxxxxxxxxTCP_DATAv4,PSH+ACK,xxxxxxxx…,http(80),xxxxxxx,xxxxx,WindowSize=65535 
HttpMethod=GET
HttpProtocol=HTTP/1.1 
HttpUserAgent=Mozilla/4.0_(compatible;_MSIE_8.0;_Windows_NT_5.1;.・・・),
----------------------------------------
１行中の①と②はサーバー側ログでは以下に相当し、ログ行数が多くても犯行予告が書き込まれた時刻は正確に分かるから、その付近を文字列検索等でrefererは容易に調べられる。
　① 現在ページのURL
　② 一つ前のページのURL（referer）

今の横浜市役所のページ構成は当時と相当変わっていると思われるが、考え方としては①が投稿フォームのページURLで、②はトップページURLでreferer。
CSRFでは②が海外サイトのURLになっていたということになる。

追記以上