2005年7月
2005年7月31日(日曜日)
2005年7月30日(土曜日)
セキュリティレベルを戻す指示は「推奨」
「警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性 (takagi-hiromitsu.jp)」というお話がありましたが、おそらくはこの話を受けて、ZoomSight の説明が更新されているようです。
ZoomSightを既にお使いの皆様へ（セキュリティレベル設定内容確認のお願い）
*ZoomSightのインストール時にパソコンの設定を変更されていない方は、引き続きZoomSightをご利用下さい。
ZoomSightのインストール時、Internet Explorerのセキュリティレベルの設定を変更された方は、下記手順に従い、設定内容をご確認ください。
以上、日立GP : ZoomSightについて より
その先を見ると、こうなっています。
下記手順に従い、[ActiveXコントロールとプラグイン]の中にある[署名済みActiveXコントロールのダウンロード]の設定内容を確認して下さい。
(～中略～)
[署名済みActiveXコントロールのダウンロード]の[ダイアログを表示する]がチェックされている場合は、引き続きZoomSightをお使い下さい。
※[署名済みActiveXコントロールのダウンロード]の[有効にする]がチェックされている場合は、[ダイアログを表示する]をチェックすることを推奨いたします。
以上、日立GP : ZoomSightについて : セキュリティレベル設定内容の確認方法(Internet Explorer 6.0の場合) より
「有効にする」にしてしまった人に対する案内は「推奨いたします」という弱い表現である上に、そのままにした場合の危険性が全く説明されていないようですね。この表現だと、別に変えなくても問題ないと思われてしまう危険があるのでは……。
関連する話題: セキュリティ
2005年7月29日(金曜日)
chkconfigど忘れ
Red Hat Linux で、システム起動時に自動的にサービス (デーモン) が起動するように or 起動しないように設定するコマンドは何だっけ……というのが全く思い出せなくてはまりました。service コマンドなどと違って、最初に設定するときに一度使ってそれきりだったりするので見事に忘れますね。
ちなみに正解は chkconfig。chkconfig named on とかやって使います。
QRコード画像を生成するツールに DoS の脆弱性
- JVN#29273468 QRcode Perl CGI & PHP scripts におけるサービス運用妨害の脆弱性 (jvn.jp)
- JVN#29273468：「QRcode Perl CGI & PHP scripts」におけるサービス運用妨害の脆弱性 (www.ipa.go.jp)
- QR画像コードを生成するPerlとPHPのスクリプトにサービスを停止させられるセキュリティ・ホール (itpro.nikkeibp.co.jp)
- QRコード作成ツールにDoS状態を引き起こす脆弱性 (internet.watch.impress.co.jp)
なんか「特定のパラメータの組み合わせ」とか言われていますが、要は出力する画像のサイズ (正確にはセルのサイズ) を任意に指定することができるようになっていて、途方もなく大きなサイズを指定するとサーバリソースを食い尽くすというお話ですね。QR コードに限らず、任意のサイズの画像を生成できるシステムには起こり得る話です。
関連する話題: セキュリティ / IPA / JPCERT/CC / JVN / 情報セキュリティ早期警戒パートナーシップ
2005年7月27日(水曜日)
office さん事件の未公開部分
スラッシュドットに「ACCS不正アクセス事件、元国立大研究員が謝罪文を公開し和解 (slashdot.jp)」というトピックがありますが……。議論のベースとなる情報量が少なすぎるというか、事件も決着したことですし、情報を少しずつ公開していった方が良い議論ができたりするのかな、と思ったりしました。
私が知っていて、おそらくは公表されていないであろうものを漠然と書くと……
- csvmail.cgi はどんなものだったのか
- ASK ACCS のセキュリティへの配慮はどの程度のものだったのか
- ACCS が公表している情報漏洩の範囲について
- 事故調査報告書の内容についての抗議
- 漏洩 PPT ファイル入手報告に対する ACCS の対応
- ACCS の「二度目の脆弱性」の公表タイミングについて
といったところかしら。って、公開してもろくな事にならないものばっかだな。
若干オフトビですが、被害者になろうとして批判を浴びたカカクコムと、
うまく被害者になりきれたACCSの両者を分けたものは
いったいなんだったのでしょうか。
久保田理事の営業力でしょう。営業力という言葉には語弊がありますが。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件
情報を公開しないのはけしからん、というコンセンサス
「「備える心」が大事――カカクコムのインシデントから得られた教訓 (www.itmedia.co.jp)」というお話。
カカクコムの場合、こうした副作用リスクの中で一番心を痛めたのが、技術系メディアによる「詳細を公開しないのはけしからん」という論調だったという。
「公開することによるメリットもあるが、公表した場合のリスクが読めないことから言わないようにしていたが……」（遠藤氏）、結果として社員への心理的なダメージは相当大きかったという。原因や詳細の公表に関して同氏は「何らかの社会的なコンセンサスがあればよかったかもしれない」とも述べた。
社会的コンセンサスがあれば……というのはまるっきり逆なのではないでしょうか。既に「少なくとも大規模な個人情報漏洩が起きたような事例では、原因や詳細を公表すべきだ」というコンセンサスが形成されていて、だからこそ「公開しないのはけしからん」と叩かれたのではないかと思うのですが。
ちなみに、情報セキュリティ早期警戒パートナーシップガイドライン (www.ipa.go.jp)にも以下のような記述があります。
脆弱性が原因で、個人情報が漏洩したなどの事案が起こったまたは起こった可能性がある場合、二次被害の防止および関連事案の予防のために、以下の項目を含むように公表してください。また、当該個人からの問い合わせに的確に回答するようにしてください。
・ 個人情報漏洩の概要
・ 漏洩したと推察される期間
・ 漏洩したと推察される件数
・ 漏洩したと推察される個人情報の種類（属性など）
・ 漏洩の原因
・ 問合せ先
ガイドラインにこのような規定があるのは、個人情報が漏れたら情報公開すべし、というコンセンサスの表れと見て良いのではないでしょうか。もっとも、ガイドラインのこの部分が守られたことは一度もないと思いますが……。
関連する話題: セキュリティ / 価格.com / 個人情報 / 情報セキュリティ早期警戒パートナーシップ
2005年7月26日(火曜日)
謝罪
「ASKACCS不正アクセス事件、民事訴訟でも元研究員と和解～謝罪文をWebに掲載 (internet.watch.impress.co.jp)」だそうで、民事の方も決着したようです。
良かったですね。少なくとも、
個人情報を上映して公表することによって、公表された個人情報保有者に精神的苦痛を与え
以上、謝罪文 より
という部分は office さんの本心から出た謝罪だろうと思います。被害者に謝りたい、けど謝れない、という状態がずっと続いていましたが、ようやくきちんと謝ることができたというところですね。
もっとも他のところ、たとえば
これらの公表によって、協会に無用の混乱を与え、その社会的信用を毀損したことについて
以上、謝罪文 より
などというところについては、そもそも謝罪する意味が分からないというか、和解の必要上仕方なく盛り込まれた文言なのかなぁ、と思ったりしてなかなか複雑な感じです。
ともあれ、事件としては一応決着したと考えて良いでしょう。これを機に、いままで公開できなかったものがいろいろ公開されたりするかしら?
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件
2005年7月25日(月曜日)
どうする? アイフル
更新: 2005年7月25日
「アイフルを全国一斉提訴 過払い利息などの支払い求める (www.asahi.com)」という記事が。そういう動きがあるというお話は小耳に挟んでいましたが、ついに動きましたか。これは興味深いですね。
何を隠そう、私、アイフルによって根抵当が打たれていた (過去形) 場所に住んでますから。
※追記 : 小規模ながら、アイフル被害対策全国会議 (www.i-less.net)というサイトがあるようです。
関連する話題: 出来事
ニフティ無料会員も退会
私は昔ニフティのユーザでしたので、CQS02437@nifty.com や CQS02437@nifty.ne.jp のメールアドレスを持っていました。しかしそれはもう退会していて、今は無料会員になっているわけです。
さて、無料会員は nifty.com ドメインのメールアドレスを持っているのでしょうか? 「@nifty ID登録:サービス詳細 (www.nifty.com)」の一覧表を見ると、有料会員は「@nifty IDメール」が使えるものの、無料会員は使えないという旨の表示になっています。「良くある質問 (www.nifty.com)」には、もっとはっきり書いてあります。
Ｑ @nifty ID登録と、@nifty会員の違いは？
(～中略～)
@nifty会員は、上記のサービスのほか以下もご利用いただけます。
(～中略～)
・ 「ID@nifty.com」形式でのメールの送受信（別名登録可能）
Ｑ @nifty IDをメールアドレスとして利用することはできますか？
＠niftyIDをメールアドレスとして利用することはできませんが、セカンドメールでメールアドレスを取得することは可能です。（200円/月(税込210円/月)）
これらをどう読んでも、無料会員が@niftyID@nifty.com 宛のメールを受け取れるようには思えません。
さて本日、「ニフティから来ちゃった」というお話を書いたら、「単にニフティのメールアドレス宛のメールが転送されているのでは?」というご指摘をいただきました。上記の経緯から、無料会員の ID 宛のメールが中継されることはあり得ないと考えていましたので、「私もうニフティのメールアドレス持ってないし」と断言しました。
ですがその後、念のため、ホント念のために試してみたら、あっさり、中継されちゃったのですよね。
平然と嘘を書いているのか、それとも意図せずして中継されている状態なのかは分かりませんが、それはもうどちらでもかまいません。
迷わず退会しました。
ニフティから来ちゃった
更新: 2005年7月25日
まだほとんど使っていないこちらのメールアドレスに、とうとう日本国内から spam が着弾。body に
「未承諾広告※」
会社名：すじ舐め事務局
なんて書いてありますが、Subject は単に「これって、なりゆき？」というもの。明らかに違法な spam です。
Received: はこんなのでした。
Received: from trans.nifty.com ([202.248.20.211]:36857)
by minazuki.com with [XMail 1.21 ESMTP Server]
id <S1A5> for <minazuki@bakera.jp> from <88wUP7wt/zdys@ejnet.ne.jp>;
Sun, 24 Jul 2005 00:16:56 +0900
Received: from mail526.nifty.com (mail526.nifty.com [202.248.37.143])
by trans.nifty.com (8.9.3p2+3.2W/3.7W000613) with ESMTP id AAA11773
for <wah59618@trans.nifty.com>; Sun, 24 Jul 2005 00:16:47 +0900 (JST)
Received: from mxg501.nifty.com (mxg501p.nifty.com [172.22.128.41])by mail526.nifty.com with ESMTP id j6NBKt3V007325
for <wah59618@trans.nifty.com>; Sat, 23 Jul 2005 20:20:55 +0900
Received: from nuru.tv (pl448.nas926.a-nagoya.nttpc.ne.jp [210.139.55.192])by mxg501.nifty.com with ESMTP id j6NBKmcT022425
for <wah59618@nifty.com>; Sat, 23 Jul 2005 20:20:49 +0900
Received: by nuru.tv (Postfix, from userid 48)
id 4728236816C; Sat, 23 Jul 2005 20:19:26 +0900 (JST)
一番上のフィールドはこのサーバの XMail がつけたものです。ちょっとだけ詳しいのが良い感じ。送信元について whois.nic.ad.jp に訊いたらこんな感じでした。
a. [IPネットワークアドレス] 202.248.20.0/24
b. [ネットワーク名] NIFTY-SERVE
f. [組織名] ニフティサーブ ネットワーク(ニフティ株式会社)
g. [Organization] NIFTY SERVE NETWORK(NIFTY Corporation)
ニフティから来ているみたいですね (あるいは第三者中継なのかもしれまんが)。韓国・台湾から着弾したものに関してはネットブロック丸ごと拒否で対応したのですが、私の知人にはニフティのユーザが結構いるので、ニフティ丸ごとはちょっと支障があるわけでして……。どうしようかなぁ。
※ニフティの無料会員でもあるのでお知らせメールも来ますが、そっちは別に届かなくても問題ありません。:-)
※追記: ニフティのメールアドレス宛のメールが転送されているのではないかというご指摘をいただきました (ありがとうございます)。どうも知らないうちにメールアドレスを持たされていたようです。速攻で退会しました。
届け出た
溜まっていたのを届け出たつもり。
発見からかなり時間が経っていたということもあり、直っていたのが 2件ありました。
また、発見の経緯が全く思い出せないものが 2件。exploit の URL だけがメモしてあったという……。とりあえず「経緯不明」とか書いて届け出てみましたが、受理されるのかどうかは分かりません。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ
2005年7月22日(金曜日)
2005年7月21日(木曜日)
グランド・セフト・オートにアダルトデータ
「米人気ゲームソフトにアダルトデータ 批判で指定変更 (www.asahi.com)」
メーカー側はＡＰ通信に「ゲームの編集作業は複雑で、実際には使われない内容がディスクに残されるのは異例ではない」と説明している。
というかほとんどのゲームにいわゆるボツデータが残っていますね。PAR (www.cybergadget.co.jp)を使わないと入手できないアイテムなんてのは良くありますし、中にはプログラマの愚痴が入っているものとか……。
しかし改造ツールで吸い出される運命であることもまた事実なので、まずいデータを無防備に入れておくことがないようにしないといけないですね。
Hiki の XSS
Hiki の XSS が修正されたようです : 「Hiki Advisory 2005-07-21 (hikiwiki.org)」。
なんか今日の日付で出ていますが既知のような気がするというか、発見者本人から直接話を聞いていたかも。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
tDiary の CSRF
「JVN#60776919 tDiary におけるクロスサイト・リクエスト・フォージェリの脆弱性 (jvn.jp)」だそうで。CSRF の問題はたぶんまだ大量にありますが、どんどん修正されていくのでしょう。
※しかし、某 ISP なんかと比べると対応が圧倒的に早いですね。
2005年7月20日(水曜日)
2005年Q2
- ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第2四半期（4月～6月）] (www.ipa.go.jp)
- SQLインジェクション・XSS・DNS……脆弱性届出、第2四半期は84件 (pcweb.mycom.co.jp)
- スタートから1年、脆弱性情報届出は1日1.4件ペース (www.itmedia.co.jp)
今期は「ppblogにおけるクロスサイトスクリプティングの脆弱性」「Movable Typeにおけるセッション管理の脆弱性」などとWeb系作成ツールの脆弱性の公表も多い。「全体の傾向として、環境や技術などを必要とするソフトウェアの脆弱性はやはり届けられにくい傾向にある」と、情報セキュリティ技術ラボラトリー長の福澤淳二氏。IPAでは、これらは1サイトの修正で脆弱性が解消されないため、ソフトウェア製品に関する脆弱性に分類している。
ウェブアプリケーションの脆弱性として届け出られたものがソフトウェアの脆弱性だった場合、別途ソフトウェアの脆弱性として届出し直すことを求められます。追加の届出をすると、それには別の ID がつけられて処理されます。そして、元の届出は元の届出、追加の届出は追加の届出で、別々に終了通知が来ます。なので、このようなケースは「ソフトウェア製品に関する脆弱性に分類」されているのではなくて、両方で処理され、両方でカウントされているのではないかと思いますが……。
2005年第2四半期の傾向として、クロスサイトスクリプティングの届出が減り、その分SQLインジェクションが増えている。
(～中略～)
「SQLインジェクションによる事件がこの期に多く報道されたことや、比較的見つけやすいクロスサイトスクリプティングは初期の段階で既に多く届けられたためだろう」と福澤氏は分析する。
あうあう、すみません、XSS の届出が減った真の理由はたぶんこんな感じです。
- 3月末～ : 判決が出て、法的な面を再検討する必要に迫られて届出を控えていた
- 4月頭～ : 自宅サーバ導入で忙しかった
- 5月いっぱい : ロマサガ (www.amazon.co.jp)
にはまっていて忙しかった (ぉぃ
- 6月中～ : ドラッグオンドラグーン2 (www.amazon.co.jp)
にはまっていた (ぉぃぉぃ
……うわー、前半はともかく後半はホント駄目人間だ……。
幸いにして「情報システム等の脆弱性情報の取扱いに関する研究会 ～運用実績を踏まえた問題点整理と今後の取組み～ (www.ipa.go.jp)」の PDF 文書の中に以下のようなくだりがあります。
3.2.3 運用に際しての法的問題
情報セキュリティ早期警戒パートナーシップの運用を通じて得た知見を踏まえ、新たな法的問題について、発見者、製品開発者、ウェブサイト運営者の観点からそれぞれ検討した。その結果、半年以上の運用を経た段階では、運用上問題となる新たな法的論点は指摘されなかった。ただし、制度の円滑な運用を維持するため、こうした観点について、今後も引き続き検討することが必要と考えられる。
ここから「少なくとも IPA は今までの届出に法的な問題があったとは考えていない」「今までの届出を続けても法的な問題はないと考えて良い」と理解して、法的な面はクリアしたことにします。
ということで来期はがんばりますので許してください。
関連する話題: セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / SQLインジェクション
2005年7月19日(火曜日)
リモートデスクトップで DoS
「WindowsのリモートデスクトップにDoSの脆弱性 (internet.watch.impress.co.jp)」。
クライアントマシンならまだしも、サーバが殺されるときついですね。Windows Server 2003 も対象なので、まったくもって他人事ではないのですが。
サニタイズの話つづき
「サニタイズ言うな?」のお話にコメントをいただきました (ありがとうございます)。私の理解したところを以下にまとめておきます。
「セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏 (pcweb.mycom.co.jp)」の記事のサニタイズの話の部分ですが、ざっと見るといろいろな論点が挙げられているように見えるものの、ポイントとなるところは意外と少ないのではないかと感じました。たとえば以下のような論点があるように見えますが、
『サニタイズ』はろくな対策をしていないことを一言で表現できる便利な言葉であり
(～中略～)
「そもそも(SQL Injection、Command Injectionなどの)インジェクション系の脆弱性が起こるということは、セキュリティ以前にきちんと(本来処理されるべき)記号のエスケープ化などを行っていないということだし、すなわち本来入力されうる文字列を処理できなくなるということでもある」「Buffer Overflowにしても、センスのあるプログラマは常にバッファ境界等に対して意識しており、あまりそのような問題は起こさない」と、適切にプログラムを記述すればサニタイズの必要性は本来ないはずだ、と主張する。
これは「サニタイズと言う必要がない」という話にはなりますが、「サニタイズと言わない方が良い」という話にはつながりません。良く読むと、該当部分で「サニタイズと言わない方が良い」理由になっている部分は、実は一カ所しかありません。以下の部分です。
「開発者にとっては綺麗にプログラムを書くことが大命題であり、セキュリティ屋が(セキュリティ関連の)問題を指摘してくると『プログラムが汚くなる』としてそれを嫌う人が多い」
ここでは「セキュリティ屋がセキュリティ関連の問題を指摘」した際に、開発者が「『プログラムが汚くなる』としてそれを嫌う」という点が問題とされています。しかし、私にはこれがぴんと来ませんでした。私には「プログラムが汚くなる」という反応を受けた経験が無かったからです。そもそも、サニタイズをしてもプログラムが汚くなるとは限らないのに、何故「プログラムが汚くなる」という反応になるのかが分かりませんでした。
しかし、これはいただいたコメントではっきりしました。
高木さんが思っているサニタイズのイメージは「本来は必要ないがセキュリティ上の問題を解決するためだけに仕方なく入れる処理」というものだと思います。というか私がそういうイメージを持っています。
この「高木さん」を「開発者の方」に置換すると、すべてをすっきりと理解することができます。
「セキュリティ屋が(セキュリティ関連の)問題を指摘」する局面で「サニタイズしてください」と言っている場合、それは「所定の機能要件を満たすための処理が、たまたまセキュリティ上の問題をも解決する」というケースも含んでいます。たとえば、SQL 文を適切にエスケープするだけで解決する場合は、それだけで十分なのです。「仕方なく」別の処理を入れる必要はありませんし、「プログラムが汚くなる」ような事もありません。しかしながら、言われた開発者がサニタイズという言葉から「仕方なく入れる処理」を連想したとすると、「プログラムが汚くなる」という反応になっても不思議はありません。
ここで起きているのは、「サニタイズ」という言葉の意味のすれ違いです。
そもそもサニタイズの発想というのは、外部入力はすべて汚染されている ("taint" である) という考え方に基づきます。「PerlのTaintモード（汚染検出モード） (www.ipa.go.jp)」などはまさにその考え方で、このモードでは、外部から入力されたすべてのデータに対して、使用する前に何らかの処理をしなければならないことになります。この「何らかの処理」こそがサニタイズです。これは「外部入力値がそのまま使われないように外部入力値をチェックする処理」として適切なものであれば何でも良く、プログラマがセキュリティを全く意識せず、単に機能要件を満たすために追加した処理であっても、その処理によって外部入力値が適切にチェックされていれば、それでサニタイズできていることになります。
しかし、単純に「サニタイズ」というキーワードだけを見ると、その言葉は無害化、消毒という意味ですから、そこから「無害化のためだけの処理」という意味を連想したとしても不思議ではありません。そして実際にそういう理解をされている方がいて、「サニタイズ」という言葉で適切に問題が伝わらないケースがあり、まさにそれが問題にされているのだと言えます。
簡単にまとめると、「サニタイズ」という言葉には広義の意味と、言葉のイメージから派生した狭義の意味とがあり、それぞれ
- 外部入力値がそのまま使われないように、外部入力値をチェックする処理。プログラマの実際の意図は問わず、そのように機能する処理すべてを含む
- 問題のある外部入力値がそのまま使われないように外部入力値をチェックするセキュリティ上の処理。プログラマがセキュリティ上の処理を意図したものだけを指し、本来の動作をさせるために入れた処理を含まない
という意味に解釈されます。高木さんが挙げたケースでは、セキュリティ屋は前者の意味で使っているのに、開発者は後者の意味に理解したために「プログラムが汚くなる」という反発を受けたのだと考えられます。そして、このようなすれ違いを避けるために、少なくとも「サニタイズと言う必要がない」場面では「サニタイズ」という言葉の使用に注意を払った方が良い、という結論が導き出されます。
2005年7月18日(月曜日)
ニフティのセキュリティ対策はまだか
ニフティの社長の blog というのがあるのですが、ずいぶん前に「セキュリティ対策（その１） (furukawa.cocolog-nifty.com)」という興味深い記事が出ました。
ニフティでお客様のために取り組んでいるセキュリティ対策には、
・迷惑メール対策
・ウイルス対策
・スパイウェア対策
・フィッシング対策
・不正侵入対策
などがある。
それぞれについて、どのようなことに注意して、どのような点に力を入れて取り組んでいるか、また、どのような課題があるか次回以降で述べてみたい。
とあったので、ニフティのセキュリティに関する対応の一端を知る者として非常に興味深く見守っていました。特に「不正侵入対策」のあたりに期待していたのですが、「セキュリティ対策（その２） (furukawa.cocolog-nifty.com)」が出たきり、一ヶ月経っても続編は出ないのですね……。
まあ相手はニフティですし、気長に待ちますか。
関連する話題: セキュリティ
MT で CSRF の話まとめ
CSRF について調べていて何気なく発見しましたが、Movable Type の CSRF 対策について、非常に良いまとめが「Movable Type における CSRF の可能性と各種対処法 (hxxk.jp)」にあるようです。というか、元記事が移動してパワーアップしているのですね。
※「MT で CSRF」の話にも移転先へのリンクを追加しておきました。
関連する話題: セキュリティ / CSRF / Movable Type
レントゲン
セキュリティホールmemo (www.st.ryukoku.ac.jp)で紹介されていたのですが、「胸部Ｘ線：健康診断で廃止検討、有効性に疑問 厚労省 (www.mainichi-msn.co.jp)」というお話があるそうで。
エックス線検査は労働安全衛生法の規則が定める職場健診の１項目。同法は７２年の施行以来、事業者に対し年１回の実施、労働者には受診を義務付けており、罰則もある。受診対象者は現在、約５９００万人に上る。
結核予防法も年１回の検査を義務付けていたが今年４月に義務は廃止された。見つかる結核患者が受診者１万人に１人未満と少なく、発見の利益よりエックス線被ばくの害が心配されるためだ。
あんまり意味なかったでしたか……。「新しい創傷治療 (www.wound-treatment.jp)」もそうですが、今までのは何だったのかという感じになりますね。
関連する話題: セキュリティ
2005年7月17日(日曜日)
埋もれてた
普通の質問のメールが凄い勢いで spam に埋もれていたのを発見。
最近は「初めまして」とか「こんにちは」とかいう Subject で出会い系の spam と思われるもの (URL も何も書いてないので想像でしかないですが……) が大量に送られてくるので、ちゃんと用件を Subject に書かないと本当に埋もれますね。
単に「質問」ではなくて、「○○についての質問」などと書いていただくと、「○○」部分が目につくので分かるのですが……。
関連する話題: spam
生体認証用のインターフェイスが
「IBM ThinkPad X41 が外部から誰でもシャットダウンできる仕様について (d.hatena.ne.jp)」というお話。生体認証用にカスタマイズされたインターフェイスがデフォルトではセキュアでない設定になっている……という理解で良いと思いますが、設定で回避できる話でもあり、脆弱性と呼べるのかどうかは微妙ですね。
そういえばこの前、オフィスのドアに電子錠をつけようかという話になったとき、むやみに「生体認証がイイ」と主張し、しかもその理由が「大根指を試したい」とかいうとんでもないものだった……というのは私なので気をつけないと。:-)
関連する話題: セキュリティ
2005年7月13日(水曜日)
spammers.tab の設定を貫通!?
Xmail の spammers.tab に
"218.187.0.0" "255.255.0.0"
などと書いてごっそり拒否していたはずなのに、218.187.44.204 からあっさりと spam が着弾。
さんざん頭をひねったあげく、Xmail のフィルタルールを貫通する送信方法があるのか!? などというとてつもない疑惑まで浮上してきましたが、よくよく見たら、件の記述が
"218.187.0.0." "255.255.0.0"
となっていて、末尾によけいな "." がついていたことが判明しました。しくしく……。
サニタイズ言うな?
「セキュアなWebアプリ実現のために本来やるべきことは? - 高木浩光氏 (pcweb.mycom.co.jp)」。
「パラメータ改ざん」というキーワードがよろしくないというお話は激しく同意。ありとあらゆるパラメータは当然改竄できるのですし、たいていは改竄されてもたいした問題は起きないので、改竄されること自体は全く問題ではないはずです。ただ、たまに改竄されると問題が起きてしまうケースがあって、「パラメータ改竄による偽価格データの送信」「パラメータ改竄によるディレクトリトラバーサル」「パラメータ改竄によるクロスサイトスクリプティング」といった事が起きますが、それらはそれぞれ価格の改竄、ディレクトリトラバーサル、クロスサイトスクリプティングの問題であって、パラメータ改竄としてひとくくりにすべきではないでしょう。脆弱性の一類型として「パラメータ改ざん」というキーワードを使うのは不適切だとずっと思っていました。
それはさておき、今ひとつ分からなかったのがサニタイズの話です。
高木氏は「既存のサイトに対して、そのセキュリティ対策として『サニタイズ』を行うというのは、セキュリティ屋の発想としては極めて自然である」と述べつつも、「そもそも(SQL Injection、Command Injectionなどの)インジェクション系の脆弱性が起こるということは、セキュリティ以前にきちんと(本来処理されるべき)記号のエスケープ化などを行っていないということだし、すなわち本来入力されうる文字列を処理できなくなるということでもある」「Buffer Overflowにしても、センスのあるプログラマは常にバッファ境界等に対して意識しており、あまりそのような問題は起こさない」と、適切にプログラムを記述すればサニタイズの必要性は本来ないはずだ、と主張する。
SQL文の発行の際には普通にエスケープ処理をしておけばそれだけで十分であり、特別に「悪意ある入力を無害化する」ということを意識しなくても良いはずだ、というお話でしょうか。確かに、セキュリティ云々を抜きにして考えても、ユーザが検索文字列に単引用符(')を含めたら SQL のエラーが出る、というのはバグでしょうし、そういうバグが起きないように書いていれば、自然と SQL インジェクションなどできない状態になっているはずです。
実は「サニタイズ」と一口に言っても、そこには全く違う 3つの方法論があるのですね。
- 問題が起きる文字列をエスケープして処理する
- 問題が起きる文字列を削除してしまう
- 問題が起きる文字列を含む入力はエラーにしてしまう
これを、たとえば単引用符(')を検索したケースに適用してみますと、それぞれ以下のような結果になるでしょう。
- 単引用符が検索され、単引用符を含む項目がヒットする
- 単引用符が削除され、空白文字列が検索されたことになる
- 単引用符を含む文字列は検索できません、というエラーが出る
どれが望ましいかは明らかです。二番目の結果はユーザの意図と異なるものが検索されてしまう不具合、三番目の結果も不具合に近いでしょう。
しかし、どれも「サニタイズしている」ことには間違いありません。「サニタイズしてください」と求めた場合、一番目ではなく二番目、三番目の処理をされたとしても文句は言えません。ですので、「サニタイズ」という万能の言い方をするよりも、具体的にどうするのかを明確にして議論した方が良いと言えるでしょう。
……というようなお話なのかな、と理解しましたが、そんな感じで良いのでしょうか。
しかし SQL や HTML の出力はそうだとしても、パス名パラメータについてはエスケープ処理で無害化することができませんし、何が有害で何が無害なのかは状況によって異なりますので、純粋に「悪意ある入力を無害化」ということを意識してサニタイズ処理を入れておく必要があるはずです。もっとも、パス名パラメータを外部入力させるような設計自体を「サニタイズ」したほうが良いような気もしますが……。
2005年7月11日(月曜日)
なにもしていないのに
特別なことは何もしていないのですが、単に「カートに入れる」を押したら、SQL っぽいエラーが。調べたら、どうも Cookie が無効だと 100% 再現するようです。チェックしようよ……。
いろいろなものが無効だと、いろいろなことを発見してしまうという悲しいサガ。今日は、画面真っ白→仕方なくソース見る→発見、というありがちなコンボもたくさん発動して、なんかいろいろあったような気がしました。
関連する話題: セキュリティ
2005年7月9日(土曜日)
パートナーシップガイドライン改訂
制度の運用開始から 1年が経つわけですが、「情報セキュリティ早期警戒パートナーシップガイドラインの改訂について (www.ipa.go.jp)」ということでガイドラインが改訂されました。毎年改訂する感じなのでしょうか。
あまり大きな変更はないようですが、ポイントとしては
- JVN の名前が入った
- ウェブアプリケーションの脆弱性として届け出られたものが実はソフトウェアの脆弱性だった場合の処理が明記された
- ウェブアプリケーション脆弱性の修正期間に 3ヶ月という目安が設けられた
といったあたりでしょうか。
最後の項目、3ヶ月という期間は長いと思うかもしれませんが、逆に言うと、現に脆弱性を 3ヶ月以上放置しているケースが多数あるということですね。
※どうでもいいけど某 ISP、放置中の 7件のうち少なくとも 2件は修正されているのではないかと思うのですが、報告無しって……。
関連する話題: セキュリティ / IPA / JPCERT/CC / JVN / 情報セキュリティ早期警戒パートナーシップ
2005年7月8日(金曜日)
立件されないのに
カカクコムからは「不正アクセスについてのご報告 (www.kakaku.com)」というものが出ていますが……。
インターネットサービスの便利さと引換えに、このような悪質な犯罪行為が急増しております。犯罪行為との自覚なしに行為に及ぶ人間も多く存在するようですが、今回のように検挙され処罰されていくことが示されることで、インターネット犯罪に対する大きな抑止力になると思います。
以上、不正アクセスについてのご報告 より
……あのー、カカクコムへのアクセスに関しては立件されないって報道されてるんですけど……。
しかも、リネージュのトロイを仕掛けたのは今回の被疑者とは別人である可能性が高いわけで、つまりは「新たに別件の不正アクセスが発覚した」のだと思うわけですが、なんかそういう認識があるように見えないのは何故なのでしょう。
2005年7月7日(木曜日)
不正アクセスではない!?
旅行会社「クラブツーリズム」のサイトへの不正侵入事件で逮捕された中国人留学生もカカクコムから会員のメールアドレス約９万件を抜き取っていたが、同庁は、この件については不正アクセス禁止法違反容疑での立件は困難と判断した。
(～中略～)
一方、中国人留学生の郁華容疑者（２７）はカカクコムが集中攻撃される前の４月中旬と５月初旬に侵入していた。だが、少なくともこの時点では同社のサーバーは、利用者を特定の人に限り、部外者の侵入を防ぐ「アクセス制御機能」が不十分だった疑いが強いことが判明。不正アクセス禁止法の要件を満たさない可能性が高いと判断したという。
以上、カカクコムのサイト攻撃、中国からも より
アクセス制御機能が不十分だったから不正アクセスにならないって……。ASKACCS のアレでさえ「アクセス制御機能があった」という判断になったのに、カカクコムは「アクセス制御機能が不十分だった」って、どう考えても納得できないのですが。
ともあれ、もう少し情報がほしいですね。
2005年7月5日(火曜日)
確定
「ACCSの不正アクセス裁判で有罪判決が確定、元京大研究員が控訴取り下げ (internet.watch.impress.co.jp)」……って、なんとも微妙な幕切れですが、執行猶予つきですから、これで良しとするという選択はありだと思います。最後まで戦い抜く、なんてのは口で言うのは簡単ですが、不安定な状態でいつまで続くか分からない戦いを続けるのは物凄い負担でしょうし。
あと気になるのは、この副作用として「ウェブアプリケーションの脆弱性」の届出がどうなるかという話ですが……。判決が確定したことを受けて「情報システム等の脆弱性情報の取扱いにおける法律面の調査 (www.ipa.go.jp)」が更新されることが期待されますので、その内容次第かなあと思ったりしています。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / 情報セキュリティ早期警戒パートナーシップ
2005年7月4日(月曜日)
二重送信防止システム
「ショッピング・サイトでの重複注文はなぜ起きる？ (itpro.nikkeibp.co.jp)」
クライアントサイドのスクリプトで二重送信を防止するのはなかなか大変なのですよね。送信後に本当にサーバからの応答が無くてしいたけを押し、もう一度送信……などという事態も想定しておかないと、本当に送信できなくなることがあります。
そういえば、送信時に「これでよろしいですか?」という確認のダイアログが出て、そこでキャンセルを押すと、その後内容を編集しようがしまいが二度と送信できなくなるというシステムを見たことがあります。二重送信防止は完璧ですが、やり過ぎです (というか完全にバグだと思いますが)。
ともあれ、サーバ側で対策するのが基本ですね。
関連する話題: Web
2005年7月3日(日曜日)
クリア
ドラッグオンドラグーン2 (www.amazon.co.jp)
……きつかったー。3周目は難易度高かったです。ボスは攻撃さえ見切れば特に問題なく倒せるのですが、厳しいのはザコ戦。いちおう、無敵コンボは見切ってガードしたりするのですが、こちらの技のモーション中に刺されたりするとどうにもなりません。特にエリスとユーリック。
※死んでもコンティニューすると経験値は残るでそんなにつらくない……と言いたいところですが、セーブできないのが問題です。電源を切ると死ぬ前に稼いだ経験値がふいになるので、不幸にして死亡→リトライ→死亡のループ中に所用ができた場合、電源つけっぱなし攻撃で対応することになります。おかげでプレイ時間が 99:59:59 でカンストすることを確認できました。
関連する話題: ゲーム / ドラッグオンドラグーン
- 前(古い): 2005年6月のえび日記
- 次(新しい): 2005年8月のえび日記
