■ はじめに
クロス・サイト・リクエスト・フォージェリ (Cross Site Request Forgeries; CSRF（シーサーフ）)について扱う
目次
【１】クロス・サイト・リクエスト・フォージェリ 【２】手法 【３】具体的な被害 【４】対策 【５】CORS (Cross-Origin Resource Sharing)
【１】クロス・サイト・リクエスト・フォージェリ
サイトに、スクリプトや自動転送によって、 ユーザに意図せず別のサイトで、掲示板への書き込みなどを行わせる攻撃 cf. Forgery = 偽造
【２】手法
[1] 偽装したWebページ（下記の「罠サイトのサンプル」）を用意する [2] ユーザが、(1)の偽装したサイトを閲覧する [3] [2] のサイトからユーザがアクセスするつもりのない 別サイト（掲示板など）に強制的にアクセスさせられ、 意図しない処理（コメントなど）を行われてしまう [4] 別サイト(掲示板、商品購入など）は、 正規ユーザーからのリクエストと思い込み 処理してしまう
簡単なイメージ
利用者 ====> 罠サイト ====> 攻撃対象サイト
罠サイトのサンプル
<!-- hiddenだから非表示になってわからない --> <html> ... <form action="【ターゲットとなるサイト】"> ... <input type="hidden" value="【いけないことをここに書く】"> </form> ... </html>
【３】具体的な被害
* 具体的には、以下のような被害が起こる可能性がある。 + 掲示板に意図しない書き込みをさせられる + オンラインショップで買い物をさせられる + ルーターや無線LAN等のあらゆる情報機器の設定の変更をされる
【４】対策
サイト外からのリクエストの受信を拒否する必要があるので 正規ページかきたリクエストかどうかをチェックする
具体例
* フォームの一部にランダムな文字（トークン）を隠しておいて アクセスの一貫性をチェック <= ★一般的な方法★ * パスワードを再度入力させる * リファラー（REFERER）で発信元をチェック
* リファラー（REFERER）からどこからアクセスしたかを確認できる ※ ただし、ユーザによって、リファラー（REFERER）を 送らないようにもできるので注意
言語ごとの対策
* Html.AntiForgeryToken() / ValidateAntiForgeryToken を使用する
【５】CORS (Cross-Origin Resource Sharing)
背景
とはいえ、ブラウザは、 クロスサイトリクエストフォージェリ(CSRF)などの セキュリティ攻撃を防止するために、 「同一生成元ポリシー(Same-Origin Policy)」という仕組みで、 異なるオリジンのリソースへのアクセスに制約をかけている
CORS (Cross-Origin Resource Sharing)
Same-Origin Policyを一部解除し 異なるオリジン間でリソースを共有するための仕組み
参考文献
https://www.scutum.jp/information/web_security_primer/csrf.html
http://www.trendmicro.co.jp/jp/security-intelligence/threat-solution/csrf/index.html
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/301.html
http://e-words.jp/w/CSRF.html
http://www.atmarkit.co.jp/ait/articles/0504/27/news129.html
関連記事
セキュリティ攻撃一覧
https://dk521123.hatenablog.com/entry/2011/07/19/110702
SQL アンチパターン ～ SQL Injection(SQLインジェクション) ～
https://dk521123.hatenablog.com/entry/2016/01/09/113000
クロス・サイト・スクリプティング
https://dk521123.hatenablog.com/entry/2016/01/01/102800
