2004年1月15日(木曜日)
Office Update でちょっぴり残念な思い
Microsoft Office XP をインストールして早速 Microsoft Office ダウンロード (office.microsoft.com) におもむいてパッチを当てたのですが、
- パッチを当てるためには SP2 を当てる必要がある
- SP2 を当てるためには SP1 を当てる必要がある
ということで、SP1 をインストール、SP2 をインストール、その他パッチ、と 3回も Update するハメに。
これ、一回にまとまらないのかなぁ……。少なくとも SP2 は SP1 なしで当てられるようにして欲しいと思うのですが。
※Windows 2000 の SP の場合だと、SP なしの Windows 2000 にいきなり SP4 が当たります。
ついでに気になったことがひとつ。「アップデートの確認」(通称 Office Update) を使用とすると ActiveX のインストールを求められますが、これを拒否すると当然エラーになります。そのエラーページを見ると、
コントロールの読み込み中に表示されるセキュリティに関するダイアログ ボックスで、[いいえ] をクリックしました。コントロールの読み込み中にセキュリティに関するダイアログ ボックスが表示された場合は、必ず [はい] をクリックしてください。
って言われているのですね。これ、私なら「ちゃんとダイアログの中身を見て、Microsoft の電子署名がされていることを確認した場合のみ [はい] をクリックしてください」と指導したい感じですけれど……。
※まあ仮にそうなっていたとしても、Office Update を偽装したサイトが出現したら喰らう人は結構多そうな気はしますが。
- 「Office Update でちょっぴり残念な思い」へのコメント (2件)
関連する話題: Microsoft / Microsoft Office / セキュリティ
続・鳩丸高速化計画その11・高速化成功?
結局、こんな感じになりました。
- 掲示板のデータはファイルとしては XML で保存しておくけれども、メモリ上では DataTable (実際にはその派生クラス) に格納して保持しておきます。
- 掲示板のデータを使うときは DataTable.Rows.Find() または DataTable.Select() で該当するデータを引っ張ってきます。
- DataTable はメモリ上に置いておいて、再利用。静的メンバだと同じクラスを別の場所で使ったときなどに色々都合が悪そうな気がしたので、global.asax を利用する形にしました。
- データをロードした時刻を記憶しておきます。DataTable が呼ばれたとき、XML ファイルのタイムスタンプと比較して、古ければリロードします。
ちゃんと検証したわけではありませんが、感覚的にはかなり速くなりました。
以下は今後の課題など。
- 今のところ掲示板だけ DataTable 化してあります。問題なさそうなら (ThreadAbortException が出まくったりしなければ)、日記のデータも DataTable に入れるようにすればさらに速くなるハズ。
- 掲示板のスレッド表示に関しては、階層構造を DataTable に入れるのが面倒なこともあって XmlDocument から読んでくる従来の方法のままです。このままで良いのか、何とかした方が良いのか要検討。
- 記事投稿時に DataTable を更新する処理が未実装。現状では XML ファイルが更新された結果として、XML から全データがリロードされて更新されるようになっています。差分だけ DataTable に直接放り込めばもっと効率が良くなるはず。
- ……たぶん、そこら中にバグがあるでしょう。:-)
関連する話題: C# / プログラミング / えび日記 / hatomaru.dll / 鳩丸高速化計画
全てが Google という時代は終わる?
「Yahoo!、Googleとの提携は3月まで (www.itmedia.co.jp)」だそうで。
これで悪マニ (www6.big.or.jp)の beyond さんも安心……なのかなぁ。
※Yahoo! Japan が Google を使っている限り意味ないですか……。
リピーター?
更新: 2004年10月18日
3年ほど前のことなのですが、あるサイトで、ふと検索フォームに XSS を発見しました。ついでに色々調べたら、cgi-bin 以下が丸見えであることが判明。しかも、そこには見事に個人情報を含む CSV ファイル (たぶんアンケートのデータ) が置かれていて、ダウンロードできてしまう状態でした。
XSS の方はめんどくさかったので放置しておきましたが、個人情報丸見えは流石に教えた方が良いだろうということでこっそりと報告。その結果……全く何の音沙汰もなく、一週間くらいしてみたら cgi-bin 以下は見えないようにされていました。
で先日、偶然にもそのサイトにふたたび遭遇。3年経っても XSS が直っていない事を確認しました。
それはそれで問題ないのですが (ないのか?)、そのサイトのとある場所にログインフォームがあったので、何も入れないで submit ボタンを押してみました。
※ちなみに、私にはフォームを見かけるととりあえず何も入れずに submit してみる習性があります。そうしないとかなり強力に残念な思いをすることがあるので……。
そうしたら、こういうエラーメッセージが出てしまったのですよね。
Warning: PostgreSQL query failed: ERROR: parser: parse error at or near "and" in /home/homepage/public_html/service/system/index.php on line 87 Warning: Supplied argument is not a valid PostgreSQL result resource in /home/homepage/public_html/service/system/index.php on line 88
なんだかとっても嫌な予感がするのですが、突っ込んで検証しようとした瞬間に「不正アクセス禁止法」(不正アクセス行為の禁止等に関する法律) に抵触するような気がしたので、すんなりと忘れることにしました。
医療ミスを繰り返す医者のことを「リピーター医師」と言うそうですが……。
※2004-10-18 追記: IPA に届け出てみたら 2004-09-21 に修正完了の連絡をいただきました (XSS, SQLインジェクション共に修正完了の旨)。SQLインジェクションが可能かどうかは確認しないで届け出たのですが、ホントに SQL インジェクションできちゃっていたみたいです。ともあれ修正されましたので一安心。
関連する話題: Web / セキュリティ / 個人情報 / SQLインジェクション
格安ソフトspam
最近やたらと「格安」ソフトの spam が来るなぁと思っていましたが、よく見たら全部同じ所から来ていました。ひたすら
どう考えても不正コピーなので、こういうのは ACCS に通報すると良いのだろうと思うのですが、前にも書いたとおり、通報のためのフォームがスクリプト無効だと使えないという……。
※ある程度のセキュリティリテラシを持っている人は「セキュリティのためにスクリプトを無効にする」というユーザが存在することを知っていますので、Web サイトも自然とスクリプト無効の環境を考慮した設計になるでしょう。スクリプト無効で使えないということ自体が、そのサイトの「指標」になるわけでして……。
- 前(古い): 2004年1月14日(Wednesday)のえび日記
- 次(新しい): 2004年1月18日(Sunday)のえび日記