モバイルマルウェア、VoIPの危険性、無線ホットスポットへの懸念、規制遵守、スーパーワーム――これがGartnerが指摘した誇大宣伝されているセキュリティ問題トップ5だ。（IDG）
確かに誇張されているかもしれない、と思えるケースもあります。セキュリティ製品を販売するベンダーが今すぐ対応しなければならないリスクであると顧客が思えるようなマーケティングを行うのは当然と思います。ベンダーの宣伝を鵜呑みにするのは良くないと思います。
しかし、セキュリティリスクは誇張されている程度がちょうど良いのかも知れません。特に古くから知られているセキュリティホールに対するリスクは過小評価されている傾向があると思います。バッファーオーバーフロー、クロスサイトスクリプティング、SQLインジェクションのリスクは過小評価されているのではないでしょうか?
追記：
書き忘れてはいけない古くから知られているセキュリティリスクを書き忘れてました。Webブラウザ、IRC、IMなどのネットワーククライアントのリスクはどう考えても過小評価されているとしか思えないです。
まず断っておきますが私は法律に関して素人です。
最近、米国での顧客情報紛失事件が多くなっています。
なぜ最近このような報道が多いのか気になっていたのですが、急に紛失事故やクラックに遭うケースが増えたはずがありません。
数日前になりますがBSデジタルでやっていた米国のABCニュースを見ていて理由が分かりました。カリフォルニア州で顧客情報等を紛失した場合、顧客に通知しなければならない法律が施行された事が最近の顧客情報紛失・盗難事件報道につながっているそうです。
# 購読しているセキュリティ系MLでも記述してあったとは思いますが
# 読み飛ばしてますね。
どのような法律か調べていませんが、違反するとかなりの罰金が科せられるのではないかと推測しています。
ところで、日本では食品の原産地や種別などを正確表示しないと罰金を科すJIS法が施行されました。施行前は最高1億円の罰金（1億以上の利益を得ていた場合はやり得!?）が話題になっていましたが不正表示犯罪の報道はあまり見かけません。昨日、キハダマグロをホンマグロと偽って販売し、少なくとも7000万円の不正な利益を得ていた会社が摘発されたと報道されていました。しかし、一般消費者の感覚として摘発されているケースが少なすぎるように思えます。
BSE問題では食のセキュリティに非常にうるさい日本ですが、遺伝子組み換え食品・原産地の適正表示など食のセキュリティに関係するJAS法は無いよりましですが役立っていないような気がします。
調査に必要となった費用は全て違反者から回収すればよいです。仮に罰金を払ったら会社が倒産する場合でも支払わせればよいと思います。泥棒に被害を弁償させたら破産するから弁償させない、という論理は通用してはならないと思います。しかし、JAS法の運用ではこの非常識な論理がまかり通っているような気がします。
# 私の勘違い?
# ちなみに昨日スーパーで「ししゃも」ではない魚が「ししゃも」と
# 表示されて販売されていました。
話は元に戻ります。もし日本で個人情報を紛失した場合、個人情報の持ち主に連絡しなければならない、という法律ができたとして米国並に紛失事件が明るみならないような気がします…
「まるごとPHP Vol.1」で共同執筆させていただいた岡田さんの記事です。
幸か不幸か、該当したところではたして真剣な対処をするのだろうか。無論、そうあって欲しいが、実のところ、これまで何年にもわたり、ウェブサイトにかかわるセキュリティ脆弱性と対応策が公表され、正しいプログラミング方法について公表されたとしても、それに対応することを怠っているサイトは非常に多いのだ。その点で、きちんと対処してきたサイトは、特定のサイトが被害にあうというニュースを聞くころには、すでに対処し終わっているのではないかと思う。
きっちりしている所とそうでない所の差はどんどん拡大してきていると思います。「デジタルディバイド」が問題になっていましたが、今後は「セキュリティディバイド」が問題になってくると思います。
このブログでもSQLインジェクションでUNIONクエリを使った攻撃が可能だったのか公表すべき、と書きました。しかし、UNIONクエリを使った攻撃が可能か公表の有無に関わらず対処を済ませるユーザは情報の開示を待たずに、パスワードの変更など、必要な対処を済ませているでしょうね。
ところで、リスク管理にはリスク自体を無くすという考え方も必要と思います。例えば、昨日の時点でもNSAのサイトにXSS問題が残っていました。しかし、NSAとしては盗まれるクッキーは無いのでリスク無し、と判断しているのかも知れません。不必要に守るべき物（情報）を作り過ぎないのもリスク管理には必要ですね。
# 不必要かつ不用意に個人情報を収集しすぎるWebサイトは多すぎですね。
預金者を保護する法案の与党内での調整が完了したようです。新聞の報道内容からすると、この内容は銀行にとってかなり不利な条件に思えました。
暗証番号をキャッシュカードに書き込むと言った重大な過失を銀行側で証明できる場合は預金は保障されない、というのは当たり前ですが軽い過失の定義が大問題です。
生年月日や電話番号などを暗証番号に使用し、カードと同じ場所に保管している場合が軽微な過失、だそうです。そして預金額の75%を銀行が保障しなければならない法案になっているようです。
暗証番号に家族の生年月日を含む生年月日、家族や会社の電話番号を含む電話番号、住所に関連する番号、自家用車の車ナンバーなど番号等を暗証番号にするのは「軽微」な過失ではありません。契約条件の禁止事項として明記されている場合、重大な過失とみなすべきです。
このような法案は、損害保険等で適切な予防措置を取っていない場合でも保険会社に保険金を支払え、と言うのと同じではないでしょうか?
このような甘えた法案が成立するようなら日本人のセキュリティに対する意識はいつまで経っても向上するはずがありません。過保護が子供をダメにするのと同じでは無いでしょうか?
今までは銀行と預金者の契約は、預金者にとって不当な契約関係にあったとは思います。しかし、それを理由に新しい法案で預金者を過保護にしてよい訳はありません。
国の出先機関などの仕事をする際にセキュリティ確保が難しいとは思っていたのですが、アメリカの安全保障に関わる機関も
米国土安全保障省（DHS）は同省に課されたサイバーセキュリティに関する責任を果たせず、緊急事態に対しても全くの「無防備状態」である可能性がある。連邦会計監査官らは米国時間26日に発表した報告書の中でDHSをこう酷評した。
という状況らしい。
日本の場合、民も官ももっとおおらか（？）なので良いターゲットにされないように気を付けないとならないですね…
価格.comもですが、OZMall（オズモール）もSQLインジェクションに脆弱だったようです。
私は両方のサイトの登録ユーザでは無いため直接の影響はありませんが、もし仮にユーザだったとしたらSQLインジェクションに対して脆弱な場合、UNIONクエリが可能な脆弱性だったかが気になります。
少しWebセキュリティに詳しい方ならご存知とは思いますが、UNIONクエリが可能な場合、SQLインジェクションを直接行えるテーブル以外のテーブルの情報を自由にアクセスできます。システムカタログへのアクセスも可能な場合は最悪の事態です。
価格.com、OZMallともに登録ユーザには案内しているのかも知れませんが、どの程度の問題だったか正確の公表しないとならないと思います。
既に価格.comは詳細を公表しないと発表していますが、盗まれたメールアドレスを利用したフィッシング詐欺などがあった場合はどうするのでしょうか? 価格.comはメールを通じてユーザに連絡するつもりなのでしょうか? メールは送信元が判りづらいため、この様なケースの場合、メールを利用した連絡はフィッシング・ファーミングを誘発する原因になりかねません。
もし私が両サイトのユーザであれば、パスワードの変更と共用したいたパスワードを全て変更します。
# Webサイトのパスワードは覚えない主義ですから、私の場合は他のサイト
# のパスワードを変更する必要はないですが。
前にこの関数の仕様はちょっと… と書いたのですがPHP 5.1から普通の関数になります。
# セッションデータも削除できるようになります。
– Added an optional remove old session parameter to session_regenerate_id()
不正アクセスの手口は「判明している」（穐田社長）としながらも「類似犯罪のヒントとなる情報は出したくない」
別に価格.comから情報を出すまでも無く、不正アクセスの方法はいくらでも出回っています。問題を公開すると具体的な不具合の数やその他の情報を公開しないとならなくなる為非公開にしている、と思われても仕方ありません。
例えば、SQLインジェクションに対して脆弱であった場合「SQLインジェクションでメールアドレスのみではなく、ユーザが使用していたパスワードが盗まれた可能性はあるのか?」と言った質問に答えなければならないからでしょう。
パスワードはコピーする！を読んで頂ければ分かりますが、Webサイトのパスワードがメールアドレスとセットで盗まれて困るユーザは多いのではないでしょうか?
# 私は困りませんが :)
メモしたパスワードを誰でも見れる場所にポストイットで貼り付けて置くことは悪いことですが、パスワードをメモする事は悪いことではありません。
機会があるときにはこの話をするのですが、私は更パスワードをメモすることも止めています。Webサイトのサービスなどは自分でもとうてい覚える事が不可能なパスワードを設定して忘れてしまいます。Webブラウザに記憶させ、Webブラウザのマスターパスワード＋OSのファイルシステム暗号化機能を使う事にしています。
全てのWebサイトのサービスに同じパスワードを使っていると万が一パスワードが漏洩した場合、私に成りすまして他のサイトで悪事を働く、という事は十分考えられます。しかもパスワードはセキュリティを考えないWebサイトではSQLインジェクションで漏れたり、盗聴で漏れたり、内部の犯行でデータが持ち出されたり、と危険性を考えるといくらでも思いつきます。
パスワードが必要になったらどうするか? は通常Webサイトからメール送信でリセットできるようになっています。これを利用します。
突き詰めて考えると、パスワードのリセットがメールでできる事にも十分リスクがあります。しかし、どちらにしてもユーザはこの機能を無効にすることができないのでこのリスクは受け入れるしか無いでしょう。
# この機能が無効にできるWebサイトってあります?
Xbox 360サイトにクロスサイトスクリプティング問題があったようです。
ところで、SQLインジェクションに比べて、クロスサイトスクリプティングを使ったクレジットカード情報の取得やユーザの成りすましは「技術的に」難しいと考える人もいるかも知れません。しかし、悪用には技術スキルは必要ありません。クロスサイトスクリプティングの仕組みや現在のインターネット環境を考えると脆弱性の悪用は非常に簡単です。
Step1 盗み出したクッキーを保存するサーバを設置（探せば乗っ取れるサーバは直ぐ見つかります）
Step2 ユーザを攻撃対象に誘導するWebサイトまたはメールを送信
Step3 Step1で盗み出したクッキーを使ってユーザに成りすまして悪事を働く
という簡単な手順で脆弱性を悪用できます。
本気のクラッカーならこの程度の事は簡単に実行できてしまいます。
このMYCOMの記事、当たり前と言えば当たり前です。メモとして。
今回の報告書では、内部関係者によって事件が起こる前に、サイバー攻撃を未然に防ぐことができなかったのかを主眼に調査が実施された様子もうかがわれ、約 4割のケースが、事前に発生を察知できる状況にあったとの分析も出されている。62%の事件は周到な準備の下に起きたとされ、実際の会話やEメールで周囲に不満を漏らしつつ、復讐心からサイバー攻撃に及ぶことを示唆していたケースも少なくなかったようだ。犯行に至った人の57%は、社内で日頃から何かと不平不満ばかりこぼす人と見られていたようで、逮捕暦のあった人も全体の3割を超えていたという。
不満をこぼすと目を付けられるかも!?
アメリカだと会社に対する不満は誰でも普通に言っていると思うのでレッテル貼りは禁物と思います。
逮捕歴があっても犯罪者とは限らないので3割という数字をどう見るか?は詳細な報告書を見ないと分からないですね。
報告書は次のURLからたどれるので後で読むことにします。
http://www.cert.org/insider_threat/insidercross.html
セキュリティーホールmemoによると複数のWikiに脆弱性がある、記載されていました。以下が対象のWiki
PukiWiki
Wiki もどき
AsWiki
Hiki
私がWikiに使っているPukiwiki 1.4.5_1も含まれていますが、設定の関係上、指摘されている脆弱性の影響は無いと思われます。念のためにPukiwikiサイトのerrataの回避策も実施しました。
http://pukiwiki.org/index.php?%3AErrata#qf91cd08
予防措置: 「第三者によるファイル添付」を禁止する (下記のいずれか、ないし複数を実施する)
* (1) 1.4.5_rc1 以降のみ: pukiwiki.ini.php の先頭にある 定数 PKWK_READONLY の値を 1 にする
o ※この方法には副作用があります: PukiWiki全体がリードオンリーモードになるため、閲覧以外の多くの行為が同時に禁止されます。最も素早く実施/復旧する事が可能ですから、下記にある他の対応を行う前の準備段階に利用する事もできます。この機能の詳細はdev:BugTrack/744にあります
* (2) attachプラグイン(plugin/attach.inc.php)の先頭にある設定を変更し、管理者だけが添付ファイルをアップロードできるようにする
o 1.4.5_alpha以降: 定数 PLUGIN_ATTACH_UPLOAD_ADMIN_ONLY の値を TRUE にする
o それ以前: 定数 ATTACH_UPLOAD_ADMIN_ONLY の値を TRUE にする
* (3) attachディレクトリへの書き込み権限を取り除く (chmod a-w attach)
* (4) attachプラグイン(plugin/attach.inc.php)を削除する対応後、本当ににアップロードの動作が禁止されているかどうかを確認して下さい。
デフォルト設定でPukiwikiをご利用の方は早急に回避策の実施をお勧めします。
もちろん他のWikiをご利用の方も対策が必要です。脆弱性がないWikiでもデフォルト設定やインストールマニュアル手順通りにインストールしていない場合は影響がある場合も考えられます。自身が無い場合はIPAの情報公開を待ち、安全であるか確認した方が良いと思います。
【速報】価格.comがハッキングで閉鎖、閲覧者にウイルス感染の可能性もと
カカクコム、23日めどに再開への続き
日経BPのITProのカカクコムがサイト閉鎖の経緯を説明，「当初は対策ソフトの多くが未対応，ウイルスを確認できず」によるとアンチウイルスソフトが対応していなかった為、ウィルスに関する情報が提供できなかったとしています。11日～14日までの3～4日間もの時間があった割には当初カカクコムのトップページに表示されていた情報はお粗末であったとと言われても仕方ないと思います。
同社では，不正アクセスを許した原因などについては「警察が調査中であり，今後の自社のセキュリティにも影響するので控えたい」（穐田誉輝代表取締役社長兼CEO）として，詳細を明らかにしていない。しかしながら，今回改ざんされたのは，動的にWebページを生成するプログラムだと考えられる。そのようなプログラムが改ざんされたために，閲覧するだけで，ウイルスを勝手にダウンロードさせられるWebページが，同社サイト上に置かれていたと考えられる。
カカクコムのルータはパケットを盗聴可能であった時期があったらしく、その時に盗まれたIDが利用された可能性も考えられます。それにしても、最近このように重大なセキュリティ問題があった会社にしてはセキュリティ対策が不十分すぎるように思えます。
「今後の自社のセキュリティにも影響するので控えたい」としていますが、セキュリティ対策が完了しているのであれば公表しても差し支えないはずです。OSS系のサイトではクラッカーの進入を許してしまった場合、その時の状況や悪用されたセキュリティホールを出来る限り詳しく公表しています。失った信用を回復するには何が問題であったかと隠し、一時しのぎをするのではなく、何が問題であったか全て明らかにする事が重要と思います。カカクコムの利用者はコンピュータに詳しい利用者が多いはずであり、なお更詳しい情報開示が利用者の信用の回復につながる事は明らかです。
詳しく書きません。タイトルの通りです。
http://www.kakaku.com/
追記：
どうも新手のウィルスだったらしいです。この為にNODというマイナーなアンチウィルスソフトを紹介しているようです。
http://slashdot.jp/article.pl?sid=05/05/15/1644207
http://musyoku-waste.hp.infoseek.co.jp/test/index.htm
国や地方自治体の情報公開は進まない上、短すぎる保存期間で役に立たなかったり、「うっかり廃棄」で期限前になくなったり、といろいろ問題があるのですが情報公開が進んでいる分野があります。それは住民基本台帳情報の公開です。
閲覧利用の約７割は生徒募集や商品購入を呼びかけるダイレクトメール用だ。市町村や特別区が住民の届け出義務と職権で蓄積した個人情報を、一部の業者が営業に利用することが、消費者の理解を得られるとは思えない。
約7割がダイレクトメール用という事ですが、お子さんをお持ちの家庭はお分かりですよね? 子供の年齢まで知った上でのDMやセールスがやってきます。
この「原則公開」という仕組み、「システムや人から情報が漏れてもシステムやそれに関わる人物が原因である事が判らないようにするため」と思われても仕方ありませんよね… 情報を公開することによりセキュリティ問題を無くす究極のノーガード戦法ですよね…