PHPでCSRF対策を自動的に行う方法
PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを1つインクルードする以外、ほとんど何も行う必要がありません。
PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを1つインクルードする以外、ほとんど何も行う必要がありません。
クロスサイト・リクエスト(他のWebサイトから自分のサイトへURLリンクやPOSTでアクセスする)を制限したいWebアプリケーションは結構あります。例えば、ホームルーターの管理ページを作る場合、クロスサイト・リクエストは有用などころか有害です。ホームルーターの管理ページにはクロスサイト・リクエストによる脆弱性が多数報告されています。
PHPの基本機能を使えば、クロスサイト・リクエストを簡単かつ丸ごと拒否することができます。CSRFやXSS1を完全かつ簡単に拒否する仕組みを作れます。
リクエストフォージェリを再考してみたいと思います。リクエストフォージェリには
などがあります。これらは「リクエスト」を「偽装」(フォージェリ)する攻撃です。名前からは直感的にどのような攻撃なのかよく解らないですが、「攻撃リクエストのインジェクション」と考えると解りやすいと思います。
リクエストフォージェリ(Request Forgery – リクエスト偽造)はかなり古くから知られている脆弱性です。恐らく1980年代から良く知られていたはずです。昔から知られているSSRFとCSRFの類似性を考えてみます。類似性を考えると、少し解りづらいCSRFも簡単に理解できるかも知れません。
GNUCitizenによると
CSRF – It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack.
http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts
とほとんどのOpenIDのライブラリはCSRFに脆弱だそうです。
tiny problemと書いてありますがとても重要な問題です。OpenIDのようなSSO (Single Sign On)システムが脆弱だとそれを利用しているシステム全体が危険にさらされます。
BaffaloのWHR-G54S
http://buffalo.jp/products/catalog/item/w/whr-g54s/
にCSRF脆弱性とレポートされています。海外製品のレポートは見かけますが、日本製のSOHOルータのレポートは記憶にないです。よくある脆弱性なので日本製のレポートは初めてではないと思いますが、個人的には初物なので書きました。
WHR−G54SはCSRF対策がない(足りない?)ので認証状態にあればFirewall設定を変更できるようです。
SOHOルータはよくターゲットにされるので管理ページにログインしたら、ログオフしてブラウザを終了させた方が良いと思います。ログオフ機能が無くても普通はログオフするとセッション情報は消去されるはずです。ログオフ機能が付いていてもブラウザを終了させるのは、ログオフ機能の実装にも問題あった場合でもセッションが切れるようにする為です。
サンプルコードを見ると
<body onload=”document.CSRF.submit()”>
<form name=”CSRF” method=”post”
action=”http://192.168.11.1/cgi-bin/cgi?req=inp&res=filter_ip.html”
style=”display:none”>
の様にJavaScriptを使ってページを表示するだけでCSRF攻撃を行うコードになっています。フォームも非表示にしているので攻撃された事に利用者はまず気が付かないと思います。
管理用ページには割と頻繁にCSRF脆弱性やXSS脆弱性が見つかっています。SOHOルータに限らず、システム管理者の方は管理用ページにログインしたらログオフとブラウザの終了を行う癖をつけると良いと思います。管理用ページにアクセスするブラウザは普段使わないブラウザにする、仮想環境からのみアクセスする等はより効果的です。
# 私はできるだけ別のマシンから管理用ページを見るようにしています。
この種の攻撃を無闇に見ず知らずの他人に攻撃して成功させるのは比較的難しいと考えられます。しかし、標的型攻撃なら非常に簡単です。例えば、知人がCSRFに脆弱な管理ページで操作している、と知っていればログインしている間に攻撃者が作ったページに誘導して攻撃を成功させるのはそれほど難しくありません。
匿名性保証ができる攻撃者なら製品設定の解説サイトを作り、そのサイトに訪問したユーザに対してCSRF攻撃を行う方法も考えられます。この場合、攻撃に成功する確率はかなり高くなると思います。