厚顔無恥って普遍するものなのかしら？
http://takagi-hiromitsu.jp/diary/20050427.html
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html
http://www.google.com/search?hl=ja&q=CSRF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
クロスサイトリクエストフォージェリ ( CSRF ) 関連のお話よ。
あたくしも、セキュリティに強いSEという印象を各所から頂いている手前、今回のこの話はいろいろとチェックを入れていたの。
そうして…各所の「あまりにも杜撰な記事」を拝見して、ちょっと色々書こうと思っておりましたの。…でも、敬愛する高木先生 ( http://takagi-hiromitsu.jp/diary/ ) がお書きになってるので(やっぱり、目に余る記事が多すぎたのかしら？)…ちょっとだけ突っ込みを入れる程度にしておきますわ。
まず…大胆なことではあるんですけれども。高木先生の記事から少しだけ。
この方法は私も考えておりましたし、場合によっては実際に使っておりますの。
http://takagi-hiromitsu.jp/diary/20050427.html より
簡潔な対策方法
Webアプリケーションに対してデータ変更を処理させるページ（前述の「3ページ目」）の前のページ（前述の「2ページ目」）に以下のHTML要素を含ませる。
<input type="hidden" name="sessionid" value="セッション追跡用cookieの値">そして、「3ページ目」で、そこに送信されてくるこの値が、cookieのその値と一致しているかを調べて、一致しているときだけ処理を実行する。
ただ、一番の問題点は「複数のPageを同時進行で扱わせたい」というクライアントからの要求が、面倒になりますの。
もちろん、入力系であることを理由に「複数の同時進行はNG」と言い切ってしまえるといいんですけれども、中途半端に詳しい方ほど「Webは同じ登録Pageを何枚も開いて同時進行させても問題ないつくりにすべきだ」などとおっしゃる方がいまして。
…頭の痛い問題ですわ。もっとも、今回のことを盾に「セキュリティ的に甘くなってもよろしくってかしら？」と脅しを入れられるようになったっていう点においては、むしろ好都合だったのかしら？ とも思うんですけれども。
で、ほかのPageの対策と書いてあるモドキ記事は、高木先生が書かれているとおり、不適切ですわ。というか、下手に「記事として体裁をなしている」だけに、あたくしはむしろ「有害である」とすら思っておりますの。
そうねぇ。Googleの検索でも上のほうに出てくる、こんなPageがあるの。
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html
著者のプロフィールを拝見してみるわ。
素敵だわ。「情報セキュリティを世に広げるべく」がんばってらっしゃるなんて。さぞ記事も期待できそうよね？
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html より
上野 宣（うえの せん）
1975年京都生まれ。情報セキュリティを世に広げるべく、講演や執筆活動とさまざまな方面で活動中。近著に「今夜わかるTCP/IP」と「今夜わかるHTTP」（共に翔泳社から2004年12月発売）がある。
では、早速記事を拝見してみようかしら？
素晴らしいわ。ちゃんと対策まで記事に書いていただけるなんて。
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html より
■Webサイト運営者側のCSRF対策
効果的なCSRF対策を講じるためには、Webアプリケーションのプログラムで行う必要がある。多くの対策が考えられるが主なものを次に挙げておく。
………は？
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html より
●リファラーで発信元をチェック
HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー（REFERER）と呼ばれる情報を得ることができる。この情報を活用し、本来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。
この方法は簡単に実装できて比較的効果の高い方法である。しかし、リファラー情報はリクエスト発信者が自由に発行できる情報であるので、偽装されてしまう恐れもあり100％防ぐといった効果はない。
なんかトチ狂った事を書いてないかしら？
そもそもREFERERは、いくつかの理由から「それを出力しないように設定している」人たちがいるわ。そういった人たちをどうやってフォローしようっていうのかしら？
ちなみに、偽装云々ってのはそもそも見当違いね。だってCSRFって「正当なユーザが」行ってしまうものなんですもの。そういった人たちが「意図的にREFERERを書き換える」なんて事が起きると、本当に思っているのかしら？
どこをどんな風に想定したら「CSRF対策としての効果は高い」って言えるのかしら？
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html より
●チェックコードを利用
-中略-
もう1つは、上記の方法を人力で行う方法だ。正式名称を何と呼ぶのか知らないが(筆者追記：「CAPTCHA」というそうだ)、フォーム入力時の画面で画像を使ってランダムな文字列を表示し、それをユーザーに手入力させるという方法だ。この方法は、ユーザーの明確な入力を求めるので、エンドユーザーには少し手間であるが、CSRF対策としての効果は高い。
CAPTCHAを用いたって、正規ユーザがアクセスするんですもの。彼らはちゃんと入力をするに決まってるんじゃなくってかしら？
これも見当違いはなはだしい内容だわね。
http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html より
●GETよりPOST
HTTPリクエストを送る方法にはGETとPOSTがある。GETはURLにすべての情報を載せて送るリクエスト方法である。そのため、GETによるリクエストの受付を行っていると、POSTに比べて多くの攻撃手段を提供してしまうことになる。ただし、GETよりPOSTの方がまだマシだというだけで、 POSTの場合でも攻撃手段はいくつも存在する。
これもNGだわ。確認画面に行く直前をのっとられたらそこでOUTですもの。
●確認画面の追加
例えば“削除”という機能を実行するときに、“削除”ボタンを押したら即実行するのではなく、「削除しますがよろしいですか？」といったWebページを 1枚挟むことによって、ユーザーの確認を促す方法だ。気休め程度の対策であるが、GETのような単一のリクエストには効果がある。しかし、確認画面を含め複数ページに渡ってリダイレクトされる可能性もあり万能ではない。
以上が、書かれている「主な対策」なの。
…素敵だわぁ。まさに「情報セキュリティを世に広げるべく」頑張ってらっしゃる方が書く内容にふさわしい…だめっぷりだわ。
どうして、こういう連中が我が物顔に語りだすのかしら？
もう少し、己のスキルってものを冷静に見ていただきたいものだわ？
こう言った愚かな記事が多々出ていて、それを鵜呑みにしている連中や、鵜呑みにすら出来ない連中が転がっているから、脆弱なサイトっていうのはなくならないのね？
これで、セキュリティで食べていける国でしたら「お仕事万歳」とか「これは仕事を減らさないためのセキュリティ会社の陰謀」とかいろいろ騒いでみたいんですけれども。
今の状況を見ている限りですと…単純に「日本って平和でいい国だわぁ」って感じなのかしら？
牧歌的な状況が嫌いってわけじゃないの。でも、スリルの一つも分かち合えないようなおこちゃまとバニラな夜をすごしたいと思うほど、あたくしは貞淑な女じゃなくってよ？
