トリッキーコードネット トップへ戻る   C/C++, Java, Perl, PHP, JavaScript, アルゴリズム, ショートコーディング, IOCCCコードの解説, 等々

サイト情報

トリッキーなコード

7行プログラミング

物凄いコード集

アルゴリズム

データ構造

C/C++な話題

コードサンプル

ツール/環境構築

開発ノウハウ 等

ネタ/ジョーク集

おススメ書籍/サイト

サイトTOP >> コードサンプル >> CSRF対策1 - リファラチェック, CAPTCHA対策

CSRF対策1(リファラーチェック,CAPTCHAによる対策)

CSRF(クロス・サイト・リクエスト・フォージェリ)の対応策をご紹介します。
(CSRFについては、WikipediaのCSRF項目を参照して下さい。← 手抜き^^;
 ついでに、言語は必ずしもPHPで有る必要はありませんが、便宜上PHPで説明します)


まず、以下の対策は、一見役に立つようで、全くもってCSRF対策になりません。

・ログインチェック
・IPアドレスチェック
・POSTでフォーム値を渡す。

何故ならCSRFは、
「正規ユーザがログインしている状態」で「正規ユーザからのアクセスを装って」、     // ← ログインチェック無効
「正規ユーザの使用しているPCから」                                               // ← IPアドレスチェック無効
引き起こされるからです。

(※↑ 同様の理由により、通信をSSLで暗号化していようが、全くCSRF対策になりません)


また、フォームのmethodにpostを指定し、そのフォームをsubmitする事でPOSTリクエストも作り出せる為、
POSTで値を渡す事もCSRF対策としては、あまり意味がありません。
<form id="csrfForm" action="hogehoge" method="post">
<input type="hidden" name="fugafuga" value="xxxx" />
・・・・
</form>

<body>タグのonloadで呼び出した関数内で、
document.getElementById('csrfForm').submit();
を呼び出すようにしておく。

  ⇒ このHTMLファイルを読み込ませるだけでCSRF発生!! 
     (メールでURLを送りつける、見えないiframeで読み込ませる、等 いくらでも方法はある。)
※そ~いえば、古いアメリカ(?)のオンラインバンクで、数回のPOST-CSRFを発生させて、 預金をハカーの口座に送金させる事件が、あったとかなかったとか・・・。 というわけで、CSRFの有効な対応策を述べてみます。

リファラーチェック

まず、最も簡単な対応策は、リファラーのチェックを行う事です。 フォームの値を受け取るスクリプトで、
$formUrl = 'http://フォームのURL';

if (strcmp(@$_SERVER['HTTP_REFERER'], $formUrl) !== 0) {
    // 不正なアクセス
    die('ERROR');
}
とし、フォームからのアクセスか、CSRFによるアクセスかを判定します。 よくある突っ込みの、 「リファラーなんてブラウザの自己申告。いくらでも偽装できるじゃんwww m9(^Д^)プギャーッ!!」 という質問はナンセンス。 このリファラーチェックに使われるリファラーは、 正規ユーザブラウザからの自己申告の為、偽装する意味がありません。 (「Webコンテンツ側から、ブラウザのリファラーを任意に操作できる」とかいうバグが発見されない限りは・・・^^;) (↑追記:修正済だそうですが、以前Flashのバグでそういったことがあったらしいです。) ただし、 リファラーを出力しないブラウザの場合、正規ユーザでもアクセスができなくなってしまう ので注意が必要です。

CAPTCHA(画像認証)

2つめの方法としては、CAPTCHA(画像認証)を使う方法が挙げられます。 CAPTCHAとは、よく大手ポータルサイトのアカウントを作成する際に表示される↓の様な画像の事です。 CAPTCHAの例 流れとしては、 ・サーバ側で乱数を生成し、それをセッションに格納します。 ・生成した乱数が載っている画像を動的に生成し、ユーザ(ブラウザ)へ送信します。 ・ユーザは、画像に載っている乱数を読み取り、フォームに入力。そしてフォームをsubmitします。 ・サーバ側で、セッションに保存してある乱数と、ユーザからの入力文字列を比較し、正常なリクエストか否かを判定します。 CAPTCHA動作フロー ・やや実装が面倒なのと、 ・余計な不可がサーバに掛かる事と、(← フォームページを開くたびに画像を動的に生成するため) ・ユーザに余計な1アクションを強要してしまう 事が欠点ですが、 必ず正規ユーザが、画像を目視で確認する必要がある為、 CSRFはもちろんの事、連続アクセス(掲示板でのコメント無限投稿 等)を防止する効果もあります。 (※ CAPTCHAの画像は、「プログラムでは判別不可能・人間にはギリギリ判別可能」な難易度に設定する必要があります。 ・・・そこがまた難しい) CSRF対策2 (セッションチケットによる対策)へ続きます。
         このエントリーをはてなブックマークに追加   


作業効率化・ライフハックのオススメ記事




コンピュータ・テクノロジーのオススメ記事





恋愛・人間関係のオススメ記事




※ 当サイトは、トップページからリンクで辿る事の出来るページに限り、リンクフリーです。
※ 当サイトの閲覧/利用によって生じた如何なる損害も、当サイト管理人は責任を負いません。
※ 当サイトの内容を転載される場合は、当サイトへのリンクをお願い致します。