<前の日記(2006年01月15日) 次の日記(2006年01月29日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1805   昨日: 2967

2006年01月21日

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

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

そんな折、

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

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というのは、はなはだ嘆かわしい。これ以上 嘘を広めないでくれ。

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

*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暗号化としては問題ない」 などという誤りを信じ込むのは、技術者ならではである(物事を知っている気 になっている)わけだが、そうした半端な技術者が非技術者にまで誤りを吹聴 して広げている現実がある。

本日のTrackBacks(全8件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20060121]

同内容の過去エントリの引用とリンクを置こう。たいしたことを書いていないのにトラックバックしたのはこのためなので、以前から高木さんの日記を読んでいる人はこのトラックバックを辿ってくる価値はないです。 たとえば、 金庫の上にその鍵が置いてあります。この金庫は..

以前高木氏がCSRF対策について「セッションIDをhiddenに入れればよい」と書かれました。その時僕は「キャッシュに残ると危険だ」という理由で適当な対策ではないと主張したのですが、同様の主張について以下のような反駁がありました。

...

高木浩光氏と GIJOE (本名・後藤峰陽) 氏が、GIJOE氏の著書「PHPサイバーテロの技法―攻撃と防御の実際」をめぐって論争している。論争の場所は「[http://takagi-hiromitsu.jp/diary/ 高木浩光@自宅の日記]」と「[http://www.peak.ne.jp/xoops/md/news/ PEAK XOOPS サポ..

高木さんの日記
・プログラミング解説書籍の脆弱性をどうするか
・ぜひ買いたいこの一冊(脆弱性コードレビュー練習用その1)
・しばらく日記をちゃんと書けそうにない



後藤さ

んっと。先日書いたお話…おもったよりもあちこちで火の手が上がっております(苦笑 まぁ興味ありありのネタなので、色々と。 …微妙にBlogの趣旨からずれますが、まぁ頑張って沿うようにしてみます。 まず、高木先生の記述。しばらく日記をちゃんと書けそうにない( http

さきほどざっと読ませていただきましたが、予想していたほどの量ではなく、また、こんな大嘘がまかり通っては困るので、当初予定していた「『サニタイズ言うなキャンペーン』の嘘」の前に先んじて一通りのコメントをつけておきます。

http://www.peak.ne.jp/xoops/md/news/arti...

リンク集 新規ページ作成: FrontPage/ IP認証によるアクセス制限のテクニック(2/2) -- 2005-07-17 (日) 01:57:47 mod_access - Apache HTTP サーバ -- 2005-07-17 (日) 01:58:00 Macな生活 - www.mac-life.info - -- 2005-08-08 (月) 01:05:10 Mac...

検索

<前の日記(2006年01月15日) 次の日記(2006年01月29日)> 最新 編集

最近のタイトル

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2006年01月15日) 次の日記(2006年01月29日)> 最新 編集