■ - hoshikuzu | star_dust の書斎

■CSRF - クロスサイトリクエストフォージェリ

CSRF - クロスサイトリクエストフォージェリ

SpecIII - CSRF - クロスサイトリクエストフォージェリから引用させて頂きます。

CSRFの概略

CSRFはCross Site Request Forgeriesの略です。恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。

CSRFはサイトに対する正規のユーザーの権限を利用した攻撃です。あるサイトのある処理を行うページに正規のユーザーを誘導し、強制的に望まない処理を発生させます。

具体的には記事の編集や削除といった機能を持つページのURLをダミーのリンクに埋め込んで踏ませたり、imgタグのsrcとして指定して知らず知らずのうちにアクセスさせます。特に後者の例ではユーザーが全く気がつかぬうちに攻撃が完了します。攻撃の結果起こるのは、そのユーザーの持つデータがおかしなものに変更されたり、削除されたりと言った事態です。同じ原理でオンラインショップでわけのわからぬ品物を大量に購入させられたり、知らぬ間にサービスを退会させられたりと言う被害もあり得ます。

CSRFではクッキーを利用した自動ログイン機構を持つサイトなどがよく標的になります。サイト側から見ればログイン状態のユーザーがアクセスしてきて編集や削除を要求したのと同じに見えますので、要求の通りに処理を実行してしまうと言うわけです。

SpecIII - CSRF - クロスサイトリクエストフォージェリでは、以下の記事が読めます。

CSRFの概略
プログラミング上のCSRF対策
- GETよりPOST
- セッション変数を利用する
- リファラーチェック
- ワンタイムトークン
- 他のフレームやウィンドウからの操作への対策
- 必ずユーザーからの入力を求める
エンドユーザーとしてのCSRF対策
- 都度ログインログアウト
- 発見したら報告する
現在のCSRF対策の実情
参考サイト

CSRF対策がまとまって書いてある資料ですので素敵です。参考になりました。ブラウザのJavaScriptを切っていてもCSRF攻撃に侵される恐れがありますか。Web上で何か（日記とか）の管理者になっている人は要注意ですね。

なお、高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法という記事が出ていますから、SpecIII - CSRF - クロスサイトリクエストフォージェリと併せて読まれた上で、セッションIDを上手に使った対策を行う王道を歩まれることが一番良いと思われます。

ええと、そのほか、本日読んだURLを以下に。

Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)

http://cert.uni-stuttgart.de/archive/bugtraq/2001/06/msg00216.html

※(CSRF, pronounced "sea surf")ということなので、CSRFのことは「シー・サーフ」と読むのがよさげ。それにしても2001年6月ですか、このポスト。

Chris Shiflett: Foiling Cross-Site Attacks

http://shiflett.org/articles/foiling-cross-site-attacks

※図解やHTTPのやりとりが書いてあって理解しやすく嬉しい。

Chris Shiflett:Foiling Cross-Site Attacks(OSCON 2004)

http://talks.php.net/show/oscon2004-foiling-cross-site-attacks/

Given at O'Reilly Open Source Convention 2004 (OSCON 2004)※要するにオライリーのオープン・ソース・コンベンション2004での講演。

Chris Shiflett: PHP Security Workbook

http://shiflett.org/archive/51

[55 Page PDF covering all major areas (Spoofing, XSS, CSRF, SQL Injections, Sessions, etc.)]

Web Application Security (MIT security camp)

http://web.mit.edu/net-security/Camp/2003/clambert-slides.pdf

[.pdf, ~300kb]

Whitepaper "SESSION RIDING - A Widespread Vulnerability in Today's Web Applications"[.pdf]

http://www.securenet.de/papers/Session_Riding.pdf

Abstract:

In this paper we describe an issue that was raised in 2001 under the name of Cross-Site Request Forgeries (CSRF). It seems, though, that it has been neglected by the community, as it is not part of recent Web Application Security discussions, nor is it mentioned in OWASP's Top Ten or the like. After having frequently observed this vulnerability in our Web Application Security assessments of custom Web applications, we started to examine various public Web applications and other browser-based applications:

popular (commercial) Web sites

popular browser-based console applications such as administration tools for databases, servers, etc.

browser-based administration clients of hardware devices

webmail sites and open source and commercial webmail solutions

We have found out that this vulnerability is present in many of those sites, services and products, some of which perform sensitive tasks. Actually, the list of affected companies contains well-known big players. Our analysis has led us to the conclusion that this vulnerability is the most widespread one in today's Web applications right after Cross-Site Scripting (XSS). Even worse, in some scenarios it has to be considered much more dangerous than XSS.

We feel that a concise description of this issue is necessary, along with a description of scenarios that highlight the danger to all browser-based applications that do not provide appropriate countermeasures, be it Intranet, Internet or console applications. In this paper, we explain this vulnerability in depth, show that it may be used unnoticed by the victim, describe potential threats, and finally give hints on how to make Web applications safe from such attacks.

We prefer to call this issue Session Riding which more figuratively illustrates what is going on.

※う〜ん、ルーター等のセッティングをブラウザでする場合にCSRFでやられるような場合も駄目駄目ならばありうるのかな？管理パスワード記憶してくれるような便利なadmin画面はそもそも駄目ということですが知らないうちにホゲホゲされるのは確かに痛いですね。

Re: Blind cross-domain POST/GET requests

http://lists.virus.org/webappsec-0412/msg00021.html

Oh and BTW, application that use CDSSO (Cross Domain Single SignOn) and ESSO (Enterprise Single SignOn) are at more risk of CSRF attacks, and developers of these application should be extra careful.

※確かにシングルサインオンはやばそうですね。

はてなダイアリー日記 - はてなダイアリーの不正な自動操作についての脆弱性について

http://d.hatena.ne.jp/hatenadiary/20040913/1095063960

※今日まで知らなかったが、はてながCSRFに対応したとのことらしい。

「MT で CSRF」@水無月ばけらのえび日記

http://bakera.jp/hatomaru.aspx/ebi/topic/2038

コラム/セキュリティ - PukiWiki Plus!

http://pukiwiki.cafelounge.net/plus/?%A5%B3%A5%E9%A5%E0%2F%A5%BB%A5%AD%A5%E5%A5%EA%A5%C6%A5%A3

川o・-・）＜2nd life - amazonにCSRF

http://d.hatena.ne.jp/secondlife/20041212/1102863591

川o・-・）＜2nd life - さっきのamazonのCSRFを利用して

http://d.hatena.ne.jp/secondlife/20041213/1102868342

XOOPS日本公式サイト - フォーラム - Re: XOOPS Shared BBS 始動？

http://jp.xoops.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=3892&forum=17&post_id=20864#20864

サンデーラボラトリー - exBlog - CSRF わくわく防御 (Googleキャッシュから引用)

http://216.239.63.104/search?q=cache:0BIkWGbdXKIJ:www.pleple.com/~sunday_lab/modules/exBlog/detail.php%3Fbid%3D1%26id%3D58+CSRF+%E3%82%8F%E3%81%8F%E3%82%8F%E3%81%8F%E9%98%B2%E5%BE%A1&hl=ja

CSRF わくわく防御

jp.xoops で GIJOE さんが CSRF(Cross-Site Request Forgeries)攻撃についてのお話をされていますが、これに絡んで記事を一発。

CSRF 自体、僕は他人からその存在を教えて貰ったのですが、実に巧妙な攻撃です。簡単に言うと、認証機構に守られたシステムに対して、悪意ある URL を踏ませて、本人の意図しない操作を走らせる攻撃です。本来、権限チェック機構がガードするところをスルーしてしまいます。

悪意ある URL は <img> タグで貼り付けることができます。<img> タグの src には php などのコントローラを書いても構わないからです。

怖い話ですが、食指が動くのは、これを防御するために今一般的とされる手法「ワンタイムチケット（トークン）」という防御機構のおもしろさです。これはおそらく次期 X3 では API として標準提供されると思います。

（X2 にはないので、exBlog では自前でやっていますが、こういうモジュールも増えるでしょう）

ワンタイムチケットは、次のような機構です。

1.投稿などをデーターベースに書き込む前、つまりプレビュー画面、もしくは書き込みを行う画面のときに、一回のみ有効な特殊な手形を渡す。

2.書き込みの際にシステム側で記録した手形と、相手から渡された手形を合わせる。

3.合格すればデーターベースへの書き込みを行う。

この機構を搭載したシステムに攻撃をしかけるには、手形（ワンタイムチケット）を手に入れなければいけませんが、そのためにはプレビュー画面と書き込み実行画面の両方に誘導しなければいけませんので、攻撃難易度がぐっと上がります。

手形に有効期限をつける（たとえば５分以内など）と、さらに強度が上がります。exBlog では標準は５分に統一してあります。防御力がどうこうという以前に、実装欲をそそる機構です。ギミックがたまらないです。

exBlog にこの機構が必要なのか？というと、信頼すべきモジュールで構成された X2 サイトであれば標準の CSRF 防御だけで十分です。しかし今 X2 対応のモジュールは活発に増えており、そういったモジュールを通じて X2 の CSRF 防御を突破される可能性も考えておく必要があるのではないでしょうか。

いや、単に面白そうだったので実装してみたかっただけなんですが……（本音？）

X2 が搭載している簡易 CSRF 防御については GIJOE さんの書き込みを参照してください。ただ、 X2 が持つリファラチェックは、ブラウザ側から送出を切ることができます。たとえば Norton Internet Security をインストールしていると送出が切られます。またリファラは偽装することも可能です。

リファラは基本的に切る方向へ世の中進んでいっていますので、今後はリファラに依存しないワンタイムチケット方式が中心になってくるのではないでしょうか。

exBlog は、OneTime Token もそうですが、他に JServlet ライクなプログラムができるかどうか？という実験もやってます。JServlet の経験者なら、実は PHP のほうがコーディングが面倒くさい（フレームワークの問題ですが）ということに気づくはずです。それを手法でどこまで緩和できるか？

当初、攻略対象の中心だった ActionForm モドキをどうやって PHP に取り込むか悩みましたが（Java だとサーブレットエンジンが全部やってしまうが、PHP にそんな機構はない!!）、リクエストをコントローラ毎に取得して擬似的に実装するしかないかな、と思っていたところ、ある方からかなり有効なヒントをいただき、何とか実コード化に漕ぎ着けました。

そのとき、会社でやっていた別件の仕事で、参考になる手法を見かけたのですが、感動してその人の会社に電話して、
「凄すぎっス！！公私ともに参考にさせていただいて構いませんかッ！」
　と許可を求めたところ、
「いや MVC 手法だとたいていこの設計になると思うのですが……」
　と前置きしつつも、
「どうぞ参考にしてください」
　と笑いながら言っていただけました。それ自体も、自作の BSD フレームワークとなっていますが、あれだけのコードが揃っていれば典型的なサイトは java の struts とほぼ同じ効率で PHP 開発できるのではないでしょうか。

で、ここで得たノウハウを元にいかにこれを X2 向けにかっこよくまとめるかということについて、いろいろ試行錯誤して、今もその足跡が残っています（最後にクリンナップせにゃいかん）。

ふつう、ActionForm にはサニタイズのメソッドがついているが、X2 では XoopsObject がサニタイズを持っています。これをどうするか？いっそ XoopsObject を ActionForm の基底class としてとらえるか？などと考えたのですが（正直、それも悪くない）、結局 XoopsObject 自体 ActionForm の実態クラスのプロパティの一種として実装する方式を採りました。

setter/getter メソッドが ActionForm 側なのか XoopsObject 側なのかということもかなり苦しみましたが……（XoopsObject の setVar/getVar をパブリックメソッドとして使う限り、ポリモーフィズムにならないのではないか？ということも今度また考えをまとめて文書にしたいと思います）

これが正解とは全く思えませんが、exBlog を仕上げなくてはいけないので、とりあえずはこのまま進んでいる状況です。これについては、暇をみて「日曜実験室」にまとめる予定です。

XOOPS Hackers2 - フォーラム - XOOPS入門読んで、いきなり難題に直面‥‥！