先々週から実家の都合で、東京と実家を行ったりきたりしている。先週と来週 は、打ち合わせや講演や取材をドタキャンさせていただいており、各方面には 大変ご迷惑をおかけしてまことに申し訳ないこととなってしまった。
そんな折、
というコメントを頂いた。しかし、しばらくの間、じっくり日記を書くことは できそうにない。とりあえず、簡単に書けるところだけ書いておく。
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
また、「（悪意があるサイトというより、脆弱なサイト）」と書かれているが、 何かの誤りだろう。悪意があるサイトは自由に作ることができる。
いずれかの方法で、この攻撃は防げますが、この4/27の日 記にはどこにも触れられていません。
- ログインした時点で、セッションIDを変えるようにする。
- ログインしない限りセッションは開始しない
- session.use_only_cookies を on にする
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というのは、はなはだ嘆かわしい。これ以上 嘘を広めないでくれ。
（今日は私にはここまでしか書く余裕がない。）
*1 ここでは、セッショ ンを使わないCSRF攻撃の話を除外している。
*2 同様の事例として、「そのCSRF対策はXSS脆弱性があると効果がない」などと 言う人も見かけたことがあるが、XSS脆弱性も同じくセッションハイジャック ができることを意味するのであるから、CSRF (Session Riding)攻撃の防止策 を語る際には、それより先にXSS脆弱性が排除されていることを前提とするの が当然である。
*3 なお、Session Fixationには、(1)使用する アプリケーションサーバによらない一般的な問題（使用ドメイン名による）の 他に、(2)セッション追跡方式としてURL rewriting方式からcookie方式へと自 動切換えする機能を持つアプリサーバ製品固有の問題と、(3)PHP固有の杜撰な 仕組みの問題（セッションIDとして無効な文字列を与えるとそれをセッション IDとして有効なセッションを作ってしまうというPHPの欠陥（設定で回避可能）） の3種類がある。
*4 実際、銀行のWebアプリケーションはこの方法で作られているもの が古くから多かった。
*5 セキュ リティを重視したショッピングサイトでは、パスワードの再入力によるセッショ ンの二重化をはかり、外側をcookie方式、内側をhiddenなPOST方式と、ハイブ リッド構成をとっているところもある。
*6 むしろ非技術者の方が直感として正しく理解するだろう。「警告が出た。 暗号通信に異常があるようだ。」と素直に。「SSL暗号化としては問題ない」 などという誤りを信じ込むのは、技術者ならではである（物事を知っている気 になっている）わけだが、そうした半端な技術者が非技術者にまで誤りを吹聴 して広げている現実がある。