<前の日記(2006年08月30日) 次の日記(2006年09月06日)> 最新 編集

高木浩光@自宅の日記

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

2006年09月01日

サイボウズ「闇改修」の件のその後

一昨日の日記の件*1について、出勤前の午前中にサイボウズのお客さま対応窓口から電話があった。 電話の要件は訂正があるとのことで、以下の3点を訂正するとのことだった。(以下は私による要約。)

  1. ディレクトリトラバーサルの脆弱性については、ログインしていない者によっても攻撃され得る。告知文を訂正する。

  2. ユーザの一覧を取得できてしまう問題について、脆弱性としなかったのは、重要度が低いと評価していたという誤った認識によるものだった。告知文を訂正する。

  3. 去年のクロスサイトスクリプティング脆弱性対応について、対策として追加された警告表示機能がデフォルトでオフとなっている理由は、既存バージョンとの互換性を考えたものであり、それはユーザが混乱するのではないかと考えたためで、そのような認識は誤りだった。今後、デフォルトでオンとするように検討する。

そしてさきほど告知ページを見に行ったところ、更新されていた。

あちらからの用件はそれだけだったのだが、「ご不明な点はございますか」とのことだったので、「重要度の認識の誤りとのことだが、先日の電話ではセキュリティポリシーによるものだと説明された」と確認したところ、「担当した者が確認をした範囲でそういう回答になったが経営者などの判断ではなかった」という。

担当者ねえ……。まあ、しかし、同社の同じような方針はずっと以前からおおやけにされていたわけで。たとえば、2002年6月にあった脆弱性の修正の件でも、

  • インシデント事後対応ベストの企業に秘訣を聞く ■第5回■ サイボウズ, Scan Incident Report, 2003年3月4日

    ユーザへの告知は、「Office 4.0(1.4)」が公開された5月27日にサイト内のバージョン更新履歴や「FAQ」に掲載した。すでに21日の段階で「サイボウズ DB メーカー」の対応版が公開されているが、すべての製品において何らかの対応がなされた状態になるまでは、脆弱性の存在を告知することがかえって危険を増やす可能性があると判断したため告知を27日に行ったという。また、まったく公表しないことには問題があると考えつつ、一方でこの脆弱性の影響が極めて少ないユーザに対してまで無用な不安を与えることは避けるべきであると考え、「FAQ」での告知という措置になったという。

という話があった。*2

9月1日付の「セキュリティに関するお知らせ(2) サイボウズ青野の3日ボウズ日記」によると、

今後、より迅速で正確な対応ができるよう、セキュリティ対応ポリシーを改善し、お客様が安心して弊社製品を使い続けてくださるよう努力してまいります。

となっている。

次の質問として、「ユーザ名の入力をメニューからではなく直接入力とする設定が用意されているのは、インターネットでの利用などでのセキュリティとプライバシーを想定してのものなのか、それとも、イントラネットでの利用においても入力の利便性として直接入力の方が楽な場合もあるためなのか、どちらなのか」と尋ねたところ、「基本的にはイントラネット用を想定している。後者だ。」という。

そこで意見として次のように述べた。「『基本的には』などと曖昧なことを言ってはいけない。インターネットでの利用を想定しているのか、いないのかだ。想定していないのなら、そのようにマニュアルに記述して、『インターネットでは使わないでください』と注意書きしない限り、責任はないと言うことはできないでしょう。」

しかし、今になって気づいたが、サイボウズOffice 6のマニュアルにズバリ、「インターネット上での使用を想定している場合」と書かれている(図1)ではないか。

図1: サイボウズのマニュアルが「インターネット向け」と明記している様子

続いて、実態としてインターネットで使っている人がGoogleで見つかる件について述べると、「検索で見つかること自体を問題ととらえており、今後robots.txtやmetaタグを生成するようにして対策していきたい」とのことだった。そこで、「それは解決ではない。悪意ある者が自力でロボットを走らせれば、当然そのような指定は無視して探し出すのだから」ということを述べた。もちろん、やらないよりやったほうがよいことには違いない。

ところで、告知文に書かれている

※上記対象製品をイントラネット内でのみ運用している場合に、外部(インターネット網)から攻撃を受けることはございません。

という(赤字で強調された)記述だが、これは本当だろうか? (せっかく頂いた電話で尋ねるチャンスがあったのに言い忘れた。)

今回の脆弱性の詳細を知らないのでわからないが、SQLインジェクションについては、「データベース内のデータ操作」という脅威があるそうだが、GETにせよ、POSTにせよ、ログイン中のユーザが悪意ある外部サイトのページを開いただけのタイミングでも起きるように思えるのだが。「イントラネット内でのみ運用している場合」といっても、ブラウザがインターネット上のWebサイトを閲覧できないようにしてあるというわけではあるまい。

「イントラネットのURLが攻撃者にはわからないから、影響は極めて少ない」などという主張がありがちだが、たとえば一昨日の日記の「本日のリンク元」を見れば、イントラのURLがバレることは普通にあるということがわかると思う。

テスト用エントリ

Googleが「cache」と自称する機能の動作について実験するため、以下のリンクをここに表示しておく。

*1 ちなみに電話をしたのは28日のこと。

*2 ちなみにこの記事は、これを「インシデント事後対応ベストの企業」などと評価しているが、「Scan編集部」のこの一連のシリーズは、ベストとワーストの判断基準が不明瞭で、客観性に大いに疑問のあるものだと当時から思っていた。そもそも、告知しなければ危険をなくすことのできないソフトウェア製品の脆弱性と、告知しなくてもサイトを直せば危険をなくすことのできるWebサイトの脆弱性を同じ基準で扱って、ベストだのワーストだの言うのがおかしい。


<前の日記(2006年08月30日) 次の日記(2006年09月06日)> 最新 編集

最近のタイトル

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|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
<前の日記(2006年08月30日) 次の日記(2006年09月06日)> 最新 編集