2004年10月
2004年10月31日(日曜日)
某大学でも……
そういえば某大学でも、規律を守らせるべき立場の人が自ら教室で喫煙しているそうな (禁煙マークも目立つように表示されている場所で)。
喫煙のルールも守れないような人が「ちゃんとルールを守れよ」などと発言しても全く説得力がないのですが、その人がなまじ偉かったりすると、周りの人は失笑すらしないで表面上は「ハイハイ」と聞いちゃったりするのですよね。しかしもちろん説得力はないので、その結果として、何度言っても返事は良いがいっこうに徹底される気配がない、という現象が発生します。
しかし、その教授も気の毒です。もう明らかに禁煙とわかっている場所で我慢ができないわけですから、これは既に性格云々の問題ではなく、治療が必要な状態だと思われます。しかし、鬱病が病気である (ちゃんとした治療が必要であり、本人の気の持ちようでどうにかなるものではない) という認識は最近ではもう一般的ですが、喫煙習慣は未だに本人の気の持ちようで何とかなると思われていますよね。この辺をもう少し改革して、治療を受けやすい土壌を作ってあげられると良いと思うのですが……。
※でも事業者としては、治療を受けさせるコストよりも喫煙所のコストの方が安かったりするのかな。
- 「某大学でも……」にコメントを書く
2004年10月30日(土曜日)
盛り上がり
天皇制の話題と
喫煙者さえいなければ、テンションを一晩維持することは可能な模様。
※「首大」というのは「首都大学東京 (www.daigaku.metro.tokyo.jp)」の略称。略称も凄いですが正式名称からして凄いですね。
関連する話題: 出来事
2004年10月29日(金曜日)
ASAHIネットの spam ブロック
「ASAHIネット、会員向けに迷惑メールフィルタリングサービスを無償提供 (internet.watch.impress.co.jp)」。
これは非常にありがたいですね。しかもメールアドレスごとに設定できるので、Web で公開しているメールアドレスだけフィルタする、なんてこともできるみたい。
ともあれさっそく設定してみました。
RFC2821 と RFC2822
メールアドレスの仕様については RFC2821 と RFC2822 の両方に記述があるのですが、どの記述がどちらにあるのか良く混同します。
長さの定義は RFC2821
local-part
The maximum total length of a user name or other local-part is 64 characters.
domain
The maximum total length of a domain name or number is 255 characters.
使える文字の定義は RFC2822
atext = ALPHA / DIGIT / ; Any character except controls,
"!" / "#" / ; SP, and specials.
"$" / "%" / ; Used for atoms
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
以上、RFC2822 3.2.4. Atom より
……ということで。
local-part には意外な記号が使えることになっているので注意。
2004年10月28日(木曜日)
非難する人たち
「香田さんの実家や市役所に中傷の電話・メール 邦人人質 (www.asahi.com.)」
実家を訪ねた市職員によると、２７日夜に中傷の電話が実家に数多くかかってきたという。２８日の日中は家族と旧知の市幹部が家に詰め、手助けをした。
市役所や県には、電話や電子メール、ファクスが４０件近くあった。「自分の意思で行った人を税金で助ける必要はない。災害で困っている人のために使うべきだ」「身勝手なことをする人に支援するのは納得いかない」など、ほとんどが香田さんの行動を非難する内容だという。大半は匿名だった。
たとえその人がどんな愚かな行動をとったのであっても、人の命を助けるために税金が使われるというなら問題ないと思うのですが。これで税金を払えと言うなら私は気持ちよく払えますけれども (もちろん払える額に限度はありますけれど。って前も書いた?)、そうでない人も多いということなのでしょうね。
Flash が SSL で保護されているか確認できる?
通常、入力フォームに入力された内容が安全に送られるかどうか確認するためには、
- フォームの HTML が SSL 保護されており、問題ないサーバ証明書がついていることを確認する
- そこで確認したサーバと同一のサーバに SSL で送信
とすれば基本的には大丈夫なはずです。送信前のフォームが改竄されていると意味がありませんし、送信後に罠に気づいても手遅れですから、サーバ証明書の確認は送信前に行わなければなりません。
……と、これはフォームが HTML の場合。
さてここで問題なのですが、入力フォームが Flash で実装されているような場合は、いったいどうすれば良いのでしょうか? フォーム部分となる SWF ファイルが SSL 保護付きであり、有効なサーバ証明書がついていることを確認する必要があるはずですが、どうやって確認したら良いのかがわかりません。右クリックしても変なメニューが出るだけですし……。
※まあ HTTP をトレースしていれば一応わかるのですが、もっとふつうのインターフェイスで確認できないとあまり意味がないような気がするので。
ちなみに、HTML が SSL で保護されていて、その中に SSL 保護されていない Flash が埋め込んであって Flash 内にフォームがある場合……ステータスバーには鍵マークが出ているし、サーバ証明書も確認できるのですよね。
2004年10月27日(水曜日)
サイバー攻撃の被害特定システム
「警察庁、サイバー攻撃の被害特定システム開発 (www.asahi.com)」
……この記事を読むと Web サイトの改ざんすら検知しそうな勢いを感じますが、@police (www.cyberpolice.go.jp) のインターネット治安情勢 (www.cyberpolice.go.jp)にある「SYN flood 攻撃被害観測システムについて」という PDF を読むのが吉のようです。SYN Flood 攻撃に際して発生する大量の SYN/ACK パケットを検知するシステムみたい。
関連する話題: セキュリティ
また拉致
「イラクで日本人男性拉致、福岡出身の香田証生さんか (www.asahi.com)」
国際テロ組織アルカイダに関係があるとされるヨルダン人ザルカウィ氏の率いる武装グループが２６日、日本人男性１人を拉致したとする映像をイスラム系ウェブサイトに流し、４８時間以内に自衛隊を撤退させなければ人質の男性を殺害すると警告した。
以上、イラクで日本人男性拉致、福岡出身の香田証生さんか より
アルカイダ系、48時間。この前の話とはまるきり異なる状況……。
神浦さん (www.kamiura.com)の見解でもやはり厳しい状況ようです。
それに今回はアルカイダ系の犯行である可能性が高くなっています。人質解放交渉は非常に難しくなると思います。彼らは日本人に残忍な行為（斬首など）を見せて、米国に協力しないようにする目的があるからです。
以上、メールにお返事 より
2004年10月24日(日曜日)
ラップのユーザインターフェイス
最近のサランラップにはわざわざ切り方が表示してあったりするようで、「カチッとフタを閉じてココを押さえて切ってください」などという指示が書かれていたりします。
で、その下に「右親指」「左親指」の表示があるのです。
これ、「右親指」とあるところに右手の親指を添えつつ、「左親指」とあるところに左手の親指を添えて切れば良いのだろうと思いました。が……実際にそうやってみると、両手でラップの箱を捧げ持つような格好になるだけで、引きだしたラップの切りようがありません。
訳が分からずに適当に切ったのですが、その後良く箱を調べてみると、切るときの図が出ていたりして……。
ああ、「右親指」とあるところに右手の親指を添えるか、または「左親指」とあるところに左手の親指を添えるという意味でしたか。うーん、あのマークの表示から直感的にそれを理解できるのが普通なんでしょうか。
関連する話題: ユーザビリティ
ヤミ改修
DataTable.Select() に渡す string の中で、
- データは '' で括る
- データ中の ' は \' とする
という処理をしていたのですが、どうも後者は駄目なようで、例外がスローされます。
ひとまずデータ中の ' はバッサリ削除という処理にして対処。
関連する話題: プログラミング / C# / えび日記 / hatomaru.dll / XML
2004年10月23日(土曜日)
バッテリ完全死亡
……ノート PC が全く動かなくなって大ピンチ。普通に起動しようとしても何も起きず、AC 電源を繋ぐと……電源ランプはついてハードディスクの駆動音がし、起動するか……と思いきや、わずか数秒で沈黙。BIOS 画面すら出ません。そのまましばらく見ていると、しばらくしてまた起動……数秒後に沈黙、という謎の動作を繰り返す始末。
直感的にバッテリの問題だと思い、バッテリを外して AC 電源のみにしたところ、何事もなく起動しました。
そもそも私が使っているノート PC はもともとバッテリが 1時間半くらいしか
バッテリ交換で普通に動くようになると思いますが、なんかこのままでもそれほど問題ないような気がするのと、そもそも PC 自体買い換え時かもしれないと思ったりするのが微妙です。
※でも、バッテリを外した跡を塞ぐものが何もないのがちょっとなぁ。
関連する話題: コンピュータ
2004年10月22日(金曜日)
軽く修正
掲示板の URL がアンカーに置換されたとき、xmlns="" がついていたのを修正。Firefox などでは XHTML1.1 の a要素ではないとみなされ、アンカーとして機能しなかったりしていたようです。そりゃそうですよね……。
ちなみに、空の xmlns 属性が存在すること自体は不正ではありません。
The default namespace can be set to the empty string. This has the same effect, within the scope of the declaration, of there being no default namespace.
以上、Namespaces in XML World Wide Web Consortium 14-January-1999 より
と明確に定められています。
※なので、xmlns="" が指定されていると落ちちゃったりするようでは、ちょっと困ります。
関連する話題: プログラミング / C# / えび日記 / hatomaru.dll / XML
別のタブウィンドウにダイアログを出す
改めてメモしてきます : 「Mozilla、Operaなど多くのブラウザにダイアログボックス偽装の脆弱性 (internet.watch.impress.co.jp)」
ちなみに Sleipnir などもこの影響を受けます。参考 : 「Sleipnir」「Firefox」などのタブ切り換え型Webブラウザーに存在する脆弱性 Secuniaで報告されたソフト以外のWebブラウザーも編集部にて検証 (www.forest.impress.co.jp)
原理的には、別のページへ遷移直後、タイミング少しを遅らせてダイアログを出しているだけなのですが……。「フィッシング」という言葉が知られていない頃なら、問題視されることさえなかったかも。
インストールしてはいるが……
Lynch氏は、Flashはインターネットに接続されているPCの98％にインストールされており、新しいバージョンをリリースしてから12カ月で80％のユーザーに行き渡るといったデータを紹介。
この 98% という数字には、私は含まれているのかなぁ。
FTTH がもう少し安くならないかなぁと
「光」の持ち腐れ (www.itmedia.co.jp)……?
「光」は安くなったといえど高い。7000円はそう気軽にお財布から出せる金額ではない。
いやー、全くその通りというか、グローバル IP アドレスつきで 5000円/月以下になればなぁとずっと思っているのですが。
しかも Bフレッツなんかだと、屋内回線使用料だのなんだのといろいろな名目がついて、実質 9000円とかするんですよね……。
関連する話題: Web
ログイン前にセッション ID を発行するシステム
かつて、ログインする前にセッション ID を発行するシステムが存在していたという噂は聞いていたのですが……。
Session Fixationが公表されたとき、まさかこんな動作をするアプリケーションはないだろうと思っていたのだが、その後診断を行ったいくつかのサイトでこの問題が見つかった。このような動作をする理由がいまいち把握しきれていないのだが、これは明らかにアプリケーションの問題だろう。
さて、私の目の前にはとあるログインフォームがあって、ログインしていない状態です。ソースを見ると、フォームには PHPSESSID という名前の hidden パラメータが含まれていて、めちゃくちゃセッション ID っぽい雰囲気を醸し出しています。しかもこれ、アクセスするたびにランダムに変化しています。どう見てもログイン前にセッション ID を発行しているようにしか見えないのですけれど……。
このシステムはモロに個人情報を扱いますし、非常に嫌な予感がします。杞憂なら良いのですけれども。
2004年10月21日(木曜日)
知らないファイルに FTP でアクセス?
裁判の方も進んでいたのですね。ACCS裁判を追う 元研究員「HTMLソースの改変は通常の閲覧の範囲」 (www.itmedia.co.jp)……。
また、HTMLソースを見たり改変することは趣味のようなものだと話した。
趣味ですか……まあ別に良いのですけれど、ブラウザのセキュリティの設定を固くしておくと、レベルの低いサイトではソースを見たり改変しないとアクセスできないことがあるということを話して欲しかったですね。スクリプト無効だと真っ白なだけとかいうサイトがあって、そういうサイトではソースを見ないと先に進めなかったりします。スクリプト無効だと POST できないフォームなんてのも普通にありますし。
この辺の事情を知らない人には、「ソースの改変が普通」という感覚はあまり理解してもらえないのではないかしら。
検察側は、同様のファイルにはFTP経由でアクセスするのが普通だと主張した。サーバを管理していたファーストサーバやACCSもFTPからアクセスしており、HTMLからのアクセスは通常利用の範囲外。
うーん、これはいったい何のことを言っているのでしょうか。FTP からアクセスも何も、ACCS は問題のファイルの存在自体を知らされていなかったと主張しているのですが、存在も知らないファイルに FTP 経由でアクセスしていたということなのでしょうか。
そしてファーストサーバが FTP でアクセスしていたなら、ACCS が収集した個人情報をファーストサーバが見ていたということになるわけでして、それが事実だとするとこれまた大変なことなのですが……。
※あと「HTML からのアクセス」というのも意味が分からないのですが、この検察官は大丈夫なのかなぁ。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / ファーストサーバ
2004年10月20日(水曜日)
疑惑レベルで届出OK
更新: 2004年11月4日
MYCOM PC WEB にも出ていましたね……「脆弱性届出制度、開始から3カ月 - 92件の届出、13件の修正完了 (pcweb.mycom.co.jp)」。こちらは興味深い点が二点ほど。
早貸セキュリティセンター長は「"(脆弱性が存在する)可能性があるかもしれない"程度のレベルで届け出てもらってかまわない。あとはIPAが調べる」と述べており、詳細な脆弱性情報を届け出なくてもIPA側では情報を受け付け、検査、ベンダーとの調整が行われることを強調した。
まあ私も SQL のエラーメッセージを見ただけで「SQLインジェクションの疑いあり」とか言って届けちゃってるんですが、それで OK みたいですね。それでもさすがに「input type="hidden" にファイル名っぽいパラメータがある」というだけで届け出るのは抵抗があったのですが、そんなのでも届け出ちゃって良いということかしら。
※軽い疑惑のレベルで届けたりすると IPA 側がパンクするのではないかと懸念していましたが、現状の届出件数を見る限りではパンクしそうにないですね。:-)
ちなみに届け出られた脆弱性情報は現在92件だが、脆弱性を届け出た人は22人となっており、一人で複数の脆弱性を届け出ている例が多かったという
22人というのはまたえらく少ないですね。
office さんの逮捕は、思ったよりもずっと悪い影響を及ぼしているのかもしれません。
※2004-11-04 追記: 「input type="hidden" にファイル名っぽいパラメータがある」というだけのものを一件届け出てみたのですが、受理され、取り扱われ、そして修正されました。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ / SQLインジェクション
2004年10月19日(火曜日)
ファーストサーバ側が動いたようで
「ファーストサーバ、ACCSに対する不正アクセス事件の調査結果を公表 (internet.watch.impress.co.jp)」ということで動きがあったようです。ACCS 側も「ファーストサーバ（株）が公表した文書について (www.askaccs.ne.jp)」という文書を公開していますね。
※どうでもいいんですけど、いきなり見出しに文中リンクがあるというセンスが凄いです。
ACCS 側の結論としては……
ファーストサーバ（株）は、結果的にはACCSを含む顧客に対して間違った情報を提供したと言わざるを得ません。十分な情報公開があればこのような事態に至らなかったと残念でなりません。
以上、ACCSのファーストサーバ（株）が公表した文書について より
……ええと、これはなんといいますか「私は悪くない、ファーストサーバが悪いんだ」というニュアンスが漂ってしまっているような気がしてならないのですが、そういう意図で良いのでしょうか。何というか、対外的に発表する文章の内容はもう少し慎重に検討した方が良いのではないかと思ったりしましたが、よけいなお世話ですよね。
ファーストサーバの PDF の方はまあ普通です。いちおう新事実として、
旧標準 CGI が残存していた原因は、2002年12月の CGI 上書き作業の際、当社が、当該 CGI が標準 CGI であるにもかかわらず、カスタマイズ CGI と誤認し、上書きを実施していなかったことにあると判明いたしました。
以上、不正アクセス事件に関する当社の対応について より
ということが公表されています。ASK ACCS の脆弱性が放置された原因は単純な作業ミスだったようですね。
あと微妙に気になるのが、
2003年8月
新標準 CGI への移行期間として 5ヶ月をおいた後、旧標準 CGI を当社のサポート外とした。
以上、不正アクセス事件に関する当社の対応について より
この「5ヶ月」という数字がどこから出てきたのかということです。office さんが問題の脆弱性を確認したのは 7月25日のことで、その直後にファーストサーバに通知されたとするとちょうど良い感じのタイミングだったりします。もちろん偶然なのかもしれませんが、なんとも微妙な感じがしますね。
……あとはヨセフアンドレオンが出てくれば役者が揃うといったところでしょうか。伝説となった「声明文」がいつのまにか復活していますが、
なお、今回の事件に関して「河合やAD200Xとの交渉の経過も含めてジャーナリストとして明らかにせよ」との声を多数頂戴しております。この件につきましては、ユーザの個人情報の安全が確認されてからとしてきましたが、同様の事件の再発防止につながると思われる事実に関しては、今後、一つひとつ明らかにしていく所存であります。
以上、ヨセフアンドレオンの声明文 より
と書いてあるわけでして、ここはひとつ期待させて頂きたいところです。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / ファーストサーバ
ブロードバンド時代到来
「Web利用でブロードバンド環境からのアクセスが90％超に (internet.watch.impress.co.jp)」ということだそうで。少し前から同様の話はちらほら出ていましたが……。
90% というラインは大きな意味を持ちますね。というより、「全体の一割に満たない」というラインが大きな意味を持つわけですが。
少し気になるのは、何をもってブロードバンドと定義しているのかが良く分からない点です。調査資料には
ブロードバンドユーザーのみの集計（NetViewIMS のデータによる、スピードテストによりＢＢユーザーを自動判定）
と書いてあるのですが、何処で線を引いたのかが分かりません。いや、どうも最近「56K のブロードバンド」はひょっとするとブロードバンドではないかもしれないという気がしていまして……。
関連する話題: Web
新タイプの詐欺サイト?
Websense、新タイプのフィッシング詐欺サイトが急増と警告 (internet.watch.impress.co.jp)。要は何かをまねた偽サイトでフィッシングするのではなくて、オリジナルの悪意あるサイトを作って詐欺をはたらくようですね。よく知らないサイトでフォームに何か入れるのはヤバイということになるのかしら……?
ちなみに原文ではこれを "fraud-based websites" と呼んでいて "phishing sites" とは明確に区別しているようです。原文のニュアンスは「フィッシングサイトではない詐欺サイト」という感じだと思いますが……まあ、こだわらない方向で。
2004年10月18日(月曜日)
global.asax のそれは不十分なんだって……
更新: 2005年2月10日
IT Pro (itpro.nikkeibp.co.jp) に、ASP.NET の脆弱性関連の記事が出ていますが……。
マイクロソフトは，おそらく「Webサーバー管理者の中には，ソースコードを読めない人がいる」と判断し，2日後に，公開したソースコードを実装した修正パッチ（Microsoft.Web.ValidatePathModule.dll）を用意したものと思われます。
以上、IT ProのWindowsユーザーのためのワンポイント・レッスン 第44回 : IT Pro １週間で学ぶIT基礎の基礎 より
いやいや、ValidatePathModule はそのコードの実装ではありません。global.asax にそのコードを追加しても exploit は通ってしまいます (ASP.NET の脆弱性!参照) が、ValidatePathModule をインストールすれば exploit が通らなくなります (少なくとも私が試した範囲では通りませんでした)。global.asax でのサニタイズはこの問題の対策としては不十分で、対策には ValidatePathModule のインストールが必要だということです。
※なお、このサーバにはあえて ValidatePathModule はインストールしてありません。
……というようなことがちゃんとアナウンスされていないから誤解を招くのだろうなぁ。まあ、
さらに情報やリソースを公開できるようになれば、順次このページを更新する予定です。
(～中略～)
この種類のセキュリティ問題からお客様を保護するためのガイダンスの他に、マイクロソフトは、ASP.NET にセキュリティ更新プログラムを提供するための作業を行っています。その更新プログラムにより、お客様に追加の保護策が提供されます。マイクロソフトは、その更新プログラムの展開のための品質のレベルが適切なものになった後、その更新プログラムをリリースする予定です。
ということなので、これは Microsoft としてもまだ暫定情報という扱いなのでしょう。状況を整理すると、
- Microsoft はこの脆弱性情報を認知している
- 問題を緩和する要素として ValidatePathModule がリリースされている (しかしこれはパッチではない)
- パッチは準備中 (まだ出ていない)
- それはそれとして、global.asax で URL をサニタイズすることを推奨
という感じかと。
記事では ValidatePathModule をパッチとして紹介していますが、ValidatePathModule は ASP.NET 用の URL Scan のようなもので、この問題の本質を解決しているわけではありません。上記引用部からしてパッチは別途出る予定だと言っていますし、それはそれで適用する必要があるでしょう。Code Red は URL Scan で防げますが、やっぱり MS01-033 は当てないとね……ということで。
※2005-02-10 追記: 修正されました。「ASP.NET パス検証の脆弱性 MS05-004 (www.microsoft.com)」
脆弱性関連情報に関する届出状況
IPA から正式に「ソフトウエア等の脆弱性関連情報に関する届出状況2004年第3四半期 (www.ipa.go.jp)」というものが出ていますね。
私の方も対応して (?) 過去の日記で触れた脆弱性関連の話について、届出の結果を追記してみました。ただし結果が出たものだけです (処理中のものは原則として情報公開できませんので)。中には届け出る必要がなかったものや受理されなかったものもあります。
まあそれはそれとして、
このほか、16 件が、ウェブサイト運営者と連絡が取れず、取扱いができない状態（取扱い不能）となっています。
私が届け出た中にも連絡が取れないというものがありましたが、全体で 16件もあるとは。多いですね……。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ
2004年10月16日(土曜日)
「インターネットオプション」のタイトル
どうでも良いことに気づきました。
IE を起動して、[ツール] - [インターネットオプション] と選ぶと「インターネットオプション」のダイアログが出てきます。コントロールパネルの中から「インターネットオプション」を選んでも同じダイアログが出てくるのですが、その時はダイアログのタイトルが「インターネットのプロパティ」になっているのですね。内容は同じなのにタイトルだけ違うという……。
関連する話題: Microsoft / Windows / Internet Explorer
2004年10月14日(木曜日)
「フィッシング詐欺対策を強化へ」って……
Internet Watch に「イーバンク、フィッシング詐欺対策を強化へ (internet.watch.impress.co.jp)」という見出しの記事が出ていて、見た瞬間に「あら?」と思いました。何しろイーバンクのフィッシング強化という話は高木さんに激しくツッコミを入れられています (takagi-hiromitsu.jp)ので。
……が、中身を読んだら、記事はその高木さんの Bugtraq-JP への投稿の紹介だったりして。なんか見出しと内容が合っていないような気がしますが、
それまでは表示させないように設定していたWebブラウザのアドレスバーとステータスバーを表示させる設定に変更した
以上、イーバンク、フィッシング詐欺対策を強化へ より
という部分を評価して「強化へ」と言っているのかしら。強化も何も隠していたこと自体が論外で、やっと普通になっただけだと思いますが、まあ確かに従来と比較すると強化されてはいますね。
view-source: スキームが効かない
ふと気づくと、ieex (www.kohshi.org) で「リンク先のソースを表示」できなくなっていたりします。それに限らず、view-source: スキームが「無効な構文エラー」となるようです。昔は view-source:http://example.com/ のようにすると特定 URL のソースが見られたのですが……。
昨日のパッチかと思ったのですが、Windows 2000 な方や Windows XP SP1 な方に訊いてみると、昨日のパッチを適用しても view-source: は使えている模様。となると、これは XP SP2 で撃墜されるようになったのでしょうか。それとも私の環境だけ?
関連する話題: Microsoft / Windows / Internet Explorer
ASP.NET で Vary:Accept を出力する
ASP.NET では、普通に AppendHeader() で追加しようと思っても Vary:Accept は追加できないようです。
Response.Cache.VaryByHeaders.AcceptTypes = true;
とやる必要があります。
というわけで、application/xhtml+xml で応答する場合に限って Vary を出力するようにしてみました。これはこれで、text/html の方がキャッシュされると二度と application/xhtml+xml が得られない可能性がありますが……。
2004年10月13日(水曜日)
月刊 Windows Update 10月号
「IEの累積的セキュリティ修正パッチが深刻度“緊急”で公開 (internet.watch.impress.co.jp)」というわけでパッチが出ていますね。
ちなみに「画像タグのスクリプトによるファイルダウンロードの脆弱性」と「ドラッグアンドドロップの脆弱性」が修正されたわけですが、これ、ドラッグアンドドロップでファイルを保存する機能をバッサリ削除したみたいですね。このパッチを当てると、画像をドラッグしてデスクトップに保存したり、リンクをドラッグしてデスクトップにショートカットを作成したりすることができなくなるようです。いや、そんなのできなくて良いのですけれど。
※ちなみにウィンドウ左上のアイコンをドラッグしてショートカットを作成することは依然として可能な模様。
……とか思っていたのですが、「ファイルのドラッグ/ドロップ、またはコピー/貼り付け」を有効にすると依然としてドラッグできるようですね (津田ふみかさんご指摘ありがとうございます)。削除されたというのは私の勘違いだったようで。しかしこれを「ダイアログを表示する」にしてあると、ダイアログも出ずに何も起きないというのが謎ではあります。
IE 側の修正内容としては、「不正な (×印が出ている) 画像はドラッグできなくなった」ということなのかなぁ。
関連する話題: セキュリティ / Microsoft / Internet Explorer
2004年10月11日(月曜日)
RSS を配信してみるテスト
というわけで、RSS 希望という意見がちらほらあったので、RSS を配信してみます。Firefox で最近一週間ほどのえび日記にアクセスすると、ステータスバー右端に RSS アイコンが出るハズ。
※Firefox 以外の RSS リーダーはテストしていません。:-)
HTML 内の link要素の type属性は application/rss+xml にしてみました。そうしないと Firefox が RSS とみなしてくれないようですし。HTTP応答ヘッダ の Content-Type 自体は、とりあえず application/xml にしてあります。
そんなわけで、/ebi/rss あたりで RSS が拾えるようになっています。いや、テキトーに作っただけなのでいろいろダメかもしれませんが、なんかダメだったりしたら教えてください。
2004年10月9日(土曜日)
UTF-8 な出力の頭に BOM が憑いている
今更ですが、hatomaru.dll が出力する UTF-8 なリソースの頭に EF BB BF なビット列がついていることに気づきました。XmlDocuemnt.Save() メソッドで UTF-8 で保存すると、BOM つきで保存される模様。
内部的に UTF-16 で処理しているので、UTF-16 でつけた BOM が UTF-8 でもそのままついてしまうのでしょうか。
※それとも意図的につけている? つける意味が分からないですが。
まあ消す方法も良く分からないですし、特に害もないはずですので、気にしない方向で。
関連する話題: 文字
2004年10月8日(金曜日)
RSS の Content-Type
RSS の Content-Type を application/rss+xml としているのをよく見ますが、IANA | Application Media-Types (www.iana.org) には登録されていない模様。application/rdf+xml なら登録されていますが……。
何にすると RSS リーダー使いの皆さんは幸せになれるのでしょう?
ASP.NET の脆弱性!
更新: 2005年2月10日
「ASP.NET の脆弱性?」の話ですが、セキュリティホールmemo で詳細が紹介 (www.st.ryukoku.ac.jp)されていました。
これ、どうやら Basic 認証が貫通するという話のようですね。認証かけていない場合は関係ないみたいで一安心?
参考までに Basic 認証をかけた ASP.NET なページを用意してみました。http://bakera.jp/bug/auth-test.aspx に普通にアクセスすると、401 になる (パスワードを求められる) はずです。
%5c などは URL Scan で蹴られたりしますが、http://bakera.jp/%20/bug/auth-test.aspx とやるとあっさり貫通するようですね。「ASP.NET の正規化の問題をプログラムによって確認する方法 (support.microsoft.com)」に出ている対策は行ってあるのですが、それでは不十分のようです。
※……というか、global.asax の Application_BeginRequest() の中でも正規化された後の値しか受け取れていないような気がするのですが、気のせいなのかなあ。気のせいでないとすると、そもそも対策に意味がないと思うわけですが。
※追記 :「報告された Microsoft ASP.NET の脆弱性に関する情報 (www.microsoft.com)」が更新され、Microsoft ASP.NET ValidatePath Module (www.microsoft.com) というものが公開されています。ひとまずこれで回避できるようです。
※2005-02-10 追記: 修正されました。「ASP.NET パス検証の脆弱性 MS05-004 (www.microsoft.com)」
2004年10月7日(木曜日)
チャレンジ・レスポンスではパスワードが送られるか?
「腕試し！10分でできるネットワーク実力診断テスト (itpro.nikkeibp.co.jp)」の中にチャレンジ・レスポンス方式に関する問題がありました。
チャレンジ・レスポンス方式というのは、簡単に言うと、サーバから「チャレンジ」と呼ばれるその場限りのキーが送られてきて、手元のパスワードとそのキーを合わせてハッシュしたものを送るという方式です。「チャレンジ」の値は毎回異なり、生成されるハッシュ値も異なりますので、これが盗聴されても問題ないわけです。このハッシュ値はその場で生成された一度きりのパスワードと考えることもでき、従ってこれはワンタイムパスワード方式の一種であるとも言えます。
さて、そのチャレンジ・レスポンス方式について述べているものの中で正しいのはどれかという問題だったのですが、その選択肢は事実上以下の二択になっていました。
- パスワードはサーバーに送らない
- パスワードを暗号化してサーバーに送る
※ほかにも二つ選択肢がありましたが論外なので。
さあ困りました。
送られているのはパスワードとチャレンジから生成されたハッシュ値だったりするわけですが、これは「暗号化されたパスワード」なのか、それとも「パスワードではない何か」なのか。「ワンタイムパスワードを送る」とかいう選択肢があればそれで良いと思うのですが、そんな選択肢はないのです。
前者ですが、確かに生のパスワードは送っていません。しかしその場で生成したワンタイムパスワードを送っていると言えますので、パスワードを送らないというのは言い過ぎでしょう。後者ですが、チャレンジと一緒にハッシュしたものを「暗号化」と呼んで良いのかという問題になります。これは、たとえば「/etc/shadow にはパスワードが暗号化されて格納されている」などという言い方を聞きますし、そんなに間違っていないような気がします。
というわけでどちらかといえば後者かなと思って回答したのですが……正解は前者の方でした。えーっ、ワンタイムパスワード送ってるじゃん、と思ったわけですが、回答を良く見ると、なんと後者の方の選択肢が……
クライアントがパスワードを暗号化して送り、サーバーが受信データを複合する
っておいおい、問題に出てたのと選択肢の内容が違ってるし! この選択肢だったら「サーバがデータを復号する」(複合は変換ミスでしょう) 部分が明らかに誤りなので、悩まずに選択肢を絞り込めますね。
瀬戸際で修正して、しかし問題文の方を修正し忘れたのかしら……。
ASP.NET の脆弱性?
更新: 2005年2月10日
「報告された Microsoft ASP.NET の脆弱性に関する情報 (www.microsoft.com)」って良く意味が分からないのですが、「ASP.NET の正規化の問題をプログラムによって確認する方法 (support.microsoft.com)」ではまず "\" をサニタイズしているようですので、\ と / を正規化するあたりに何かあるのかも。
ASP.NET では、たとえば http://……/%5c/test.aspx なんてのをリクエストしても http://……/test.aspx が何事もなく実行されるようになっていて、Request.Path やら Request.PhysicalPath にも何事もなかったかのように /test.aspx なり c:\……\test.aspx なりが格納されています。Request.Url.ToString() も http://……/test.aspx となっていて、いずれも %5c はどこかに消え去っています。
つまり ASP.NET では URL がプログラムに渡る前の前処理として URL を正規化していて、よけいなバックスラッシュなどは消えるようになっているのです。今回の話は、このどこかに穴があってバックスラッシュが (あるいは他のヤバイ文字が) 貫通してくるという話なのでしょうか?
ともあれ続報待ちな感じですね。
※2005-02-10 追記: 修正されました。「ASP.NET パス検証の脆弱性 MS05-004 (www.microsoft.com)」
2004年10月4日(月曜日)
もりもり修正
キャッシュまわりをいっぱい修正しました。これでまともに 304 を返せるようになったと思いますが、バグっていたらごめんなさい。あと、トラックバックはできなくなっているかもしれません (後でチェックしますが)。
それから、BBS のデータを保存するところがバグっていて、
- 保存を試みる。
- 保存に失敗したらしばらく待ってリトライ (最大 10回)
- 保存に成功したら終了
となるはずのところが、
- 保存を試みる。
- 保存に失敗したらしばらく待ってリトライ (最大 10回)
- 保存に成功したら待たずにリトライ (最大 10回)
となっていたことが発覚。おいおい。
というわけでこれも修正。これで安定すると良いなぁ。
関連する話題: プログラミング / C# / えび日記 / hatomaru.dll
2004年10月1日(金曜日)
また NTLM で漏れる系
セキュリティホールmemo (www.st.ryukoku.ac.jp) でWindows XPに「勝手にパスワード情報を送信する危険性」が見つかる (itpro.nikkeibp.co.jp)という話が紹介されていましたので、「Windows 2000 / IIS 5.0 で構築した web ページに Word ドキュメントを設置」してみました。
※いちおう URL をメモしておきますが、試すとパスワードが漏れるかもしれないので注意 :
……確かに、しっかり SMB でつなぎに行ってくれますね。なんか PROPFIND しようとして URL Scan に Reject されているのがお茶目だったりしますが、なんだかなぁ。
関連する話題: セキュリティ
- 前(古い): 2004年9月のえび日記
- 次(新しい): 2004年11月のえび日記
