2つ前記事
前記事
プログラミング解説書籍の脆弱性をどうするか
私自身、3日くらい前に教えていただいたのですが、どうやら、前の記事を書いた1/21の当日に高木氏からコメントを頂戴していたとのこと。ずいぶんとすぐに見つけていただき、恐縮至極です。とても良いお仕事なのでしょうね。
しばらく日記をちゃんと書けそうにない
さきほどざっと読ませていただきましたが、予想していたほどの量ではなく、また、こんな大嘘がまかり通っては困るので、当初予定していた「『サニタイズ言うなキャンペーン』の嘘」の前に先んじて一通りのコメントをつけておきます。
POSTでセッションIDを送る方法によるCSRF対策の問題点
Quote:
一般に、Session Fixation脆弱性のあるサイトに対して、Session Fixation攻撃が成功すると仮定した場合、攻撃者は当該サイトに対してセッションハイジャックができることを意味する。
まずここが嘘です。セッション固定とセッションハイジャックは別物です。
単にIPアドレスをセッションIDに結びつけておくだけで、セッションIDが外部に漏れたとしても、セッションハイジャックされないシステムは可能です。
というより、いわゆる「管理者権限」であるなら、特につけることが推奨されます。サイバーテロ本P.106にも書いてあります。もちろん、セッションIDとIPアドレスを結びつけることのデメリットとしては、クライアントサイドのIPアドレスがアクセス毎に変動する場合に利用出来ないことですが、「管理者」に絞れば十分に活用可能です。XOOPS用Protectorモジュールでの運用実績もあります。
そして、CSRFが特に問題になるのは、こういった「管理者」についてです。
その下の部分は、そもそもの前提部分が間違っているので、議論の対象外です。
Quote:
Session Fixationの防止策については、Internet Week 2004と同2005のチュートリアルで説明している*3が、CSRFの正しい防止策の検討とは関係がない(先述の通り)。
高木氏の講演に価値があるかどうかは、
はなはだ疑問ですがさておき、事実として関係があります。(先述の通り)
Quote:
また、「いずれかの方法で」防げるというのは誤りである(3番目だけでは防げない場合がある)。
また良く判らない前提を持ってこないでください。私はすべて、http://takagi-hiromitsu.jp/diary/20050427.html の簡潔な対策方法に書いてあることだけを前提にしています。
Quote:
まず、cacheは禁止するのが当然であり、cacheを禁止してもcacheに残る場合というのは、Webアプリケーションの責任ではない。残るような製品の脆弱性である。
これは嘘とは言いません。事実、Webアプリケーションの責任ではありません。しかし、一般的なワンタイムチケット法であれば、そういった脆弱性さえをカバーできるているのに、わざわざ穴を空けるような手法を勧める行為の是非を問いただしています。
実は次回くらいに書こうと思っていますが、Webアプリケーションプログラムのセキュリティにとってかなり重要な要素は、可能な限り他の脆弱性もカバーしようとする人間としての寛容性です。現実に、Microsoft Internet Explorerにはどう見てもブラウザの脆弱性だろう、と思われる問題が仕様として残っています。これを「ブラウザの脆弱性であり、Webアプリケーションの責任ではない」と責任放棄するのはとても簡単なことですが、それをやってしまったらWebアプリケーションプログラマとして失格です。Quote:
Webアプリケーション以外の構成要素の脆弱性の影響を受けにくいWebアプリケーションの設計方法について言うならば、セッション追跡用のセッションIDの格納場所は、cookieよりも、hiddenなパラメタに入れてPOSTで渡す方が安全である*4。なぜなら、cookieが漏洩するブラウザの脆弱性が見つかることによるセッションハイジャックの脅威の方が深刻だからである。現実には多くのWebアプリケーションがcookie方式を使用しているが、これは、柔軟な画面設計が可能であることを優先しているためであろう
私自身目を疑ってしまったのですが、これはあまりにも都合の良い話ではないですか?
Webアプリケーションプログラマは、「Cacheを残す製品の脆弱性」は気にしなくて良くて、「Cookieが漏洩するブラウザの脆弱性」は気にしなければならないということでしょうか。
私の主張はもとより、「Webアプリケーションプログラマは、それらの外部由来の脆弱性も可能な限り(開発コストの許す限り)、カバーするようなプログラムを書くべきである」というものです。
まずはセッションIDが漏れないように対策を行いますが、万一セッションIDが漏れても、即座にセッションハイジャックにつながらないように、あの手この手で防御網を張っておきます。そこまでやって初めて、一流のWebアプリケーションプログラマであり、そのための方法も拙著サイバーテロ本には書いてあります。
Quote:
Quote: ワンタイムチケット(トークン)のコードなら4/27の時点でも、ちょっと探せばいくらでも見つかったはずです。
PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室
意味がわからない。
次。
ご理解いただけなかったところ大変恐縮ですが、もう少々おつき合いください
2005/4/27の日記において、セッションIDをPOSTに積むCSRF対策法が掲げられていたわけですが、これよりもはるか前の時点で、ワンタイムチケット法が実績あるCSRF対策法として、周知されていました。仮にも自称Webアプリケーションのエキスパートが知らなかったとは言わないと思います。
それを知っていれば、セッションIDをPOSTに積むCSRF対策のデメリットも予想できたはずで、あえて危険な方法を紹介する意味がわかりません。自分で考えた方法を誇示したかったのでしょうか。もしくは、デメリットが想像できなかったのでしょうか。まさか、ワンタイムチケットのコードを実装できなかったか。いずれにせよ、CSRF対策について判っている、などと自称するにはかなりお寒い経緯です。
もちろん他にも、セッションIDをPOSTに積むCSRF対策にはデメリットが「てんこ盛り」です。
それこそ、高木氏が考慮しなければならないとする方の外部由来脆弱性「cookieが漏洩するブラウザの脆弱性」があった場合にどうなりますか? セッションハイジャックそのものはIPアドレスチェックで防ぐことも可能ですが、それをしていたとしても、CSRF攻撃は許すことになります。
さらに、この方法では、セッションIDの再生成処理がとても面倒になってしまいます。セッションIDの再生成処理とCSRF対策は本来機能的に独立したものである以上、別々のモジュールとして実装するのが、「近代プログラミングの基本」でしょう?
そして、私の師匠(
高木氏とは人格も技量も桁違い。本当に尊敬できる方です)は一目見てこう指摘しました。「GETだとだめなので、POST必須。POST必須にしたら、<form> とJSだらけの pageになってしまう。」
なるほど。セッションIDをGETで出したら、リファラーから漏洩しますから。一方、ワンタイムチケットならGETで出しても大丈夫です。出たときには、ペアになる半券ごと廃棄されています。
いかがでしょう。「セッションIDをPOSTに積むCSRF対策」なんて安易な方法、ちょっと考えただけでも、これだけ問題がゴロゴロと出てくるんです。
自説を推すというのは、研究者としては当然の姿勢だろうとは思いますが、明らかに「誤り」という段階をすぎても固執しているようでは、技術者としての技量を疑われることになるでしょう。
山本氏の書籍に対する悪意的な読み違えについてQuote:
Quote: なお、SSLの指摘については、山本氏の書かれたことは特段間違っていません。もしかすると、高木氏は「『警告なんて無視すれば良い』なんて状況を作り上げたら、せっかくのSSLの安全機構が意味をなさない」という主張かもしれませんが、そういう思想的な主張と、書籍の脆弱性を同列に並べると、何を言いたいのか、テーマがぼやけると思います。
PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの2, PEAK XOOPS サポート&実験室
これは、
Quote:
非商用サイトなどで単に暗号化の目的だけならプライベートCAで発行した証明書でも問題ありません。
山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.213
のことだが、これは技術的に間違いである。「特段間違っていない」などというのは技術的に間違いである。認証パスの検証ができない証明書によるSSL通信は、SSL暗号通信として正しく動作しないのであって、盗聴され得るものなのだということをいいかげん知ってほしい。
あいかわらずの説明不足気味で(わざとなのかどうかしりませんが)おっしゃることが良く判りませんが、dns cache poisoningとか中間者攻撃とかの話をしているのでしょうか? 確かにそれらの手法を使えば、エンドポイントになるわけですから、そういう意味では盗聴はできるでしょう。
しかし、それはSSLの基本ではないでしょうか? 私だって知っているくらいですから、経験の長い山本氏も当然に知っていると思います。それでもあえてそう書いているってことは、ルータやサーバへの攻撃を伴わない、単純な盗聴の方がはるかに脅威だ、という意味じゃないんですか? 現実に、無線LANによる問題はかなり深刻です。この観点に立てば、素のHTTPより明らかにマシでしょう。
私が引用部分を素直に読んだ限りでは、「ああ、なるほど、単純盗聴を防ぐってことをいいたいんだな」と判ります。それをわざわざ悪意に読み替える意味が判りません。
実は、今回の一件があるまで「高木浩光」という名前は、まったく聞いたことがなかったのですが、ぐぐってみると、SSLが専門の方のようです。
つまり、この一件は、自分の得意なSSLについての知識をひけらかしたかった。そのために、山本氏が犠牲になった、ということでしょうか? そうではないと信じたいところではありますが。
ちなみに私はもとより、「SSLではXSSすら防げない。SSL導入より先にやるべきことは山のようにある」が持論です。そしてなにより驚いたのは、この高木浩光氏という方は、「独立
行政法人 産業技術総合研究所」の一員であるらしい、という噂です。
この噂がもし本当であるなら、まことにゆゆしき問題です。仮にも「行政」の名を冠した団体の職員が、特定の書籍をきわめて悪意的に解釈し、「焚書」という行政に携わるものなら絶対に使ってはならない言葉を使ってこき下ろす。そんなことが許されてよいものでしょうか?
もしそうなら、九天社さんは、高木浩光氏および産総研を相手に損害賠償請求訴訟を起こすべきです。訴訟を勝ちきるのは難しいかもしれませんが、和解くらいはとれる可能性が大ですし、もし完全敗訴だったとしても、しばらくは高木氏の無礼な発言を封じることができるでしょうし、話題性で書籍が売れる可能性が高いので、「訴え得」の案件のような気がします。(保証はしません
)
九天社さまへ:
高木浩光氏の身元を調査の上、上記の件、ぜひご検討ください。
最後にQuote:
今時分になってもまだ、技術者がこの種の誤りを自信げに語って憚らないというのは、はなはだ嘆かわしい。これ以上嘘を広めないでくれ。
この言葉を、そっくりそのままお返しさせていただくことで、反論の締めとさせていただきます。
-------------------------------------------------
ここでみなさまにお知らせがございます。
拙著「PHPサイバーテロの技法」(ソシム社)は、高木氏の恣意的な妨害活動にも関わらず、好評な売れ行きを続け、ついに3刷を迎えることになりました。関係者一同、読者の皆様に心より感謝をいたします。
高木氏のブログを普段読んでいる方には特にお勧めします。
中身も、象牙の塔の住人の机上の空論ではありません。オープンソースプロジェクトで様々な実戦経験を積んできた筆者の知識と経験がギッシリと詰めこまれています。ぜひ書店でお手にとって中身を確認してください。近くに拙著が置いてある書店がない、ということであれば、
Amazonのなか見!検索でもご確認いただけます。
なお、3刷では、P.67の対策4は明らかな間違いだったために削りました。読者の皆様にご迷惑をおかけしたことをお詫びするとともに、誤りを指摘いただいた高木氏にあらためて感謝します。
------------
(2006/01/27 10:38) 「単なるフレームになるだけなのでやめたほうが良い」と友人からアドバイスを受けたところを2箇所訂正しています。ご助言、ありがとうございました。