PEAK XOOPS - 「しばらく日記をちゃんと書けそうにない」への反論
２つ前記事 前記事 プログラミング解説書籍の脆弱性をどうするか 私自身、３日くらい前に教えていただいたのですが、どうやら、前の記事を書いた1/21の当日に高木氏からコメントを頂戴していたとのこと。ずいぶんとすぐに見つけていただき、恐縮至極です。とても良いお仕事なのでしょうね。 しばらく日記をちゃんと書けそうにない さきほどざっと読ませていただきましたが、予想していたほどの量ではなく、また、こんな大嘘がまかり通っては困るので、当初予定していた「『サニタイズ言うなキャンペーン』の嘘」の前に先んじて一通りのコメントをつけておきます。 POSTでセッションIDを送る方法によるCSRF対策の問題点 Quote: 一般に、Session Fixation脆弱性のあるサイトに対して、Session Fixation攻撃が成功すると仮定した場合、攻撃者は当該サイトに対してセッションハイジャックができること
PEAK XOOPS - 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの2
前記事 プログラミング解説書籍の脆弱性をどうするか 高木氏が12/27のブログエントリで書かれた、拙著「PHPサイバーテロの技法」に対する批判は大きく２点に分けられると思います。 (1) 「サイバーテロ本」では、その場しのぎ的な「サニタイズ」を行うコーディングを推奨している (2) 「サニタイズ言うなキャンペーン」 このメインとなる２点以外についても、拙著「PHPサイバーテロ本」についていくつか書かれているので、それについての回答や反論を先に片づけておきます。 「書籍に脆弱性があることについて」 高木氏、12/27エントリの冒頭部： Quote: 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないと
PEAK XOOPS - 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1
という手法が挙げられていて、これが本命の対策のように書かれているが、これは対策にならない。4月27日の日記に書いていたように、必要なパラメタ値がセッション変数にセットされているということは、前のどこかのページでその値をセットするリクエストがあるはずで、そのリクエストにCSRF攻撃した後に実行ページにもCSRF攻撃するような仕掛けで破られてしまう。 確かに「破られる」部分についてはその通りです。「CSRF対策には、本命と呼べるものが存在しない」ということを説明するためには、なるべく多くの対策法を書くべきだろうと思い、頭の中で簡単にシミュレートしただけのものを載せてしまいました。セッション継続中に、JavaScriptによる連続自動POSTをされるようなサイトに行くことがあれば、対策にはなりません。攻撃側のハードルを高めることにはつながっていますが、せいぜい、「POST利用法」と同程度の「補助
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
