高木浩光＠自宅の日記

■ しばらく日記をちゃんと書けそうにない

先々週から実家の都合で、東京と実家を行ったりきたりしている。先週と来週 は、打ち合わせや講演や取材をドタキャンさせていただいており、各方面には 大変ご迷惑をおかけしてまことに申し訳ないこととなってしまった。

そんな折、

• PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室
• PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの2, PEAK XOOPS サポート&実験室

というコメントを頂いた。しかし、しばらくの間、じっくり日記を書くことは できそうにない。とりあえず、簡単に書けるところだけ書いておく。

JavaScriptによる連続自動POSTをされるようなサイト（悪意があるサイトというより、脆弱なサイト）にセッション継続中に訪問することがある、という前提であるなら、高木氏が4/27に書いた対策法も、対策としては不完全です。

前述の(A)というのは、いわゆるPHPセッションのことだと思われますが、そうであれば以下の方法で破ることができます。

• セッション固定をしかける
• そのセッションが生きた状態でユーザがログインしてしまう（セッションIDは変わらない）
• セッションIDもPOSTにつむCSRFをしかける

PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室

一般に、Session Fixation脆弱性のあるサイトに対して、Session Fixation攻 撃が成功すると仮定した場合、攻撃者は当該サイトに対してセッションハイジャッ クができることを意味する。セッションハイジャックによってもたらされ得る 被害の集合 T_hijack と、CSRF (Session Riding)*1攻撃によってもたらされ得る 被害の集合 T_csrf は、任意のWebアプリケーションにおいて T_hijack ⊇ T_csrf の関係にある。したがって、CSRF (Session Riding)攻撃の防止策を語 る際には、Session Fixation脆弱性がないことを前提とするのが当然である*2

また、「（悪意があるサイトというより、脆弱なサイト）」と書かれているが、 何かの誤りだろう。悪意があるサイトは自由に作ることができる。

• ログインした時点で、セッションIDを変えるようにする。
• ログインしない限りセッションは開始しない
• session.use_only_cookies を on にする

いずれかの方法で、この攻撃は防げますが、この4/27の日 記にはどこにも触れられていません。

PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室

Session Fixationの防止策については、Internet Week 2004と同2005のチュー トリアルで説明している*3が、CSRFの正しい防止策の検討とは関係がない（先述の通り）。

また、「いずれかの方法で」防げるというのは誤りである（3番目だけでは防 げない場合がある）。

次。

なんらかのプロクシ・キャッシュに残る可能性があるからです（HTTPヘッダに キャッシュ不可と書いてあったとしても）。

PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室

まず、cacheは禁止するのが当然であり、cacheを禁止してもcacheに残る場合 というのは、Webアプリケーションの責任ではない。残るような製品の脆弱性 である。

Webアプリケーション以外の構成要素の脆弱性の影響を受けにくいWebアプリケー ションの設計方法について言うならば、セッション追跡用のセッションIDの格 納場所は、cookieよりも、hiddenなパラメタに入れてPOSTで渡す方が安全であ る*4。なぜなら、cookieが漏洩するブラウザの脆弱性が 見つかることによるセッションハイジャックの脅威の方が深刻だからである。 現実には多くのWebアプリケーションがcookie方式を使用しているが、これは、 柔軟な画面設計が可能であることを優先しているためであろう*5。

次。

ワンタイムチケット（トークン）のコードなら4/27の時点でも、ちょっと探せ ばいくらでも見つかったはずです。

PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室

意味がわからない。

次。

なお、SSLの指摘については、山本氏の書かれたことは特段間違っていません。もしかすると、高木氏は「『警告なんて無視すれば良い』なんて状況を作り上げたら、せっかくのSSLの安全機構が意味をなさない」という主張かもしれませんが、そういう思想的な主張と、書籍の脆弱性を同列に並べると、何を言いたいのか、テーマがぼやけると思います。

PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの2, PEAK XOOPS サポート&実験室

これは、

非商用サイトなどで単に暗号化の目的だけならプライベートCAで発行した証明 書でも問題ありません。

山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, p.213

のことだが、これは技術的に間違いである。「特段間違っていない」などとい うのは技術的に間違いである。認証パスの検証ができない証明書によるSSL通 信は、SSL暗号通信として正しく動作しないのであって、盗聴され得るものな のだということをいいかげん知ってほしい。

今時分になってもまだ、技術者がこの種の誤りを自信げに語って憚らない*6というのは、はなはだ嘆かわしい。これ以上 嘘を広めないでくれ。

（今日は私にはここまでしか書く余裕がない。）