開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
高木浩光＠自宅の日記 - 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認
■ 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認 楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1 楽天、社内に「CSIRT」を設置, ITmediaエグゼクティブ, 2007年12月6日 「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題（前回の日記参照）は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。 しかし、この問題の根本は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なテンプレートシステムはあるのか | 水無月ばけらのえび日記
