開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
隠されていたSQLインジェクション ― ＠IT
星野君は赤坂さんと一緒にお客さんのWebアプリケーションの検査をすることになった。辛うじて「不必要情報」の脆弱性を見つけたものの、赤坂さんは不満げだ。 「だって、これ、ほかにもっと危険な脆弱性あるよ……」。 赤坂さん 「ってことで、今回は50点ってとこかな」 星野君 「うわっ。厳しいですね……。一応脆弱性は見つけたんだからもう少し……」 赤坂さん 「え。だって、これ、ほかにもっと危険な脆弱性あるよ」 星野君 「（ほかにも脆弱性あるっていってもなぁ……）」 赤坂さんに「ほかにもっと危険な脆弱性あるよ」と指摘されたにもかかわらず、星野君にはサッパリ見当が付かなかった。不必要情報（Unnecessary Information）の脆弱性に気付くまでの作業で、一通り思い付くことはやりつくしていた。 そうこうしているうちに時間は過ぎ、結局ほかの脆弱性を見つけられないまま、お客さんと約束した時間になっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
