2010年4月
2010年4月30日(金曜日)
それ町7
公開: 2010年5月1日16時20分頃
7巻が出ていたので購入。
- それでも町は廻っている 7 (www.amazon.co.jp)
目次が伊勢崎さんで、おおっと思ったら、その後全く出てこなかったですね……。
野球のルール説明のところが面白かったです。あと、おかめ怖っ。しかし、真田にこういう理由付けをされてしまうのは悲しいなぁ。
- 「それ町7」にコメントを書く
2010年4月27日(火曜日)
届出状況2010Q1
公開: 2010年1月29日23時15分頃
2010年Q1の届出状況が公開されました: 「ソフトウェア等の脆弱性関連情報に関する届出状況 [2010年第1四半期（1月～3月）]」。 (www.ipa.go.jp)
ウェブサイトの届出が5000件を突破だそうで。昔はごく少数の人だけが利用していたような印象がありましたが、けっこう定着してきた感じがしますね。
携帯サイトに関しては、以下のように注意を喚起しています。
(1) 2009 年度に届出られた携帯サイトの脆弱性の1/3 以上が「なりすましの危険性あり」
IPA には、パソコン向けのウェブサイトの脆弱性だけでなく、携帯電話向けのウェブサイト（以降、携帯サイト）に関する脆弱性も届出られています。届出られた脆弱性に関して携帯サイトの脆弱性には、「セッション管理の不備」や「認証に関する不備」といった、他人になりすますことが可能となる脆弱性が多いという特徴があります。2009 年度に届出られた脆弱性のうち、そのような脆弱性の占める割合は、ウェブサイト（携帯サイトを含む届出全体）の場合が4%であるのに対し、携帯サイトの場合は37%を占めています。
このように、携帯サイトに関しても深刻な脆弱性があることから、その運用にあたってはパソコン向けウェブサイトと同様に十分な脆弱性対策が求められます。
携帯サイトはPCサイトよりもセッション、認証まわりの脆弱性の比率が多いというお話。携帯サイトの認証まわりのひどさについては、最近話題になっていますね。携帯サイトはPCからアクセスできないことが多く、XSS検査文字列を入れるのが面倒なので、XSSが発見されにくいという事情もあるのでしょう。
※「携帯サイトの1/3以上が……」ではなく「携帯サイトの脆弱性の1/3以上が……」であることにも注意。
今後、携帯サイトに関しては根本的な部分が問題になってくるものと思います。携帯サイトの運営者は、いろいろ準備しておいた方が良さそうですね。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ
2010年4月24日(土曜日)
サナギさん5,6
公開: 2010年4月27日23時40分頃
4巻に引き続き。
「フユちゃんのコトを英語で言ったよ 聞き取れた?」というサナギさんが可愛い!
しかし最後まで勢いが衰えないですね。6巻の「ゼッケン昔話」、そして「アロエ侍」が一番面白かったです。6巻で終わってしまうのは寂しいなぁ。
咲 -saki- 7
公開: 2010年4月25日22時50分頃
7巻が出たので購入。
- 咲 -saki- 7 (www.amazon.co.jp)
オーラス決着。咲の得意技である
しかし、7巻は麻雀の勝負が極端に少ないですね。決勝のオーラス一局以外だと、「みっつずつみっつずつ」の妹尾佳織が
※この時もきっと本人は
2010年4月23日(金曜日)
サナギさん4
公開: 2010年4月25日22時25分頃
3巻に引き続き。
- サナギさん 4 (www.amazon.co.jp)
フユちゃんとのメールのやりとりが面白かったですね。あと、王子様が暴漢をやっつけるところ、「やっぱり」という感じですが笑ってしまいました。
フユちゃんは頭のいい子なんだろうなぁ。
2010年4月22日(木曜日)
サナギさん2,3
公開: 2010年4月25日20時40分頃
1巻が面白かったので引き続き。
2巻は爆笑してしまいました。冒頭の「刺身ブラウン」も良かったですが、最強だと思ったのはカレンダーの話。「五月病」が……。
3巻だと「いぬ」あたりが。
なんか読んでいるとサナギさんがどんどん可愛く思えてきますね。
2010年4月21日(水曜日)
ポチの告白
公開: 2010年4月25日19時40分頃
少し前にGIGAZINEで紹介されていて (gigazine.net)、面白そうだったので購入。
- ポチの告白 (www.amazon.co.jp)
いやぁ、これは怖いですね。
真面目で実直な人物が、上司や周囲の指示で「染まって行く」様が非常に恐ろしいです。警察・検察・裁判所がグルだから警察官は捕まらない。本来はマスメディアがチェック機能となるべきところ、日本ではそれも機能しないので歯止めが利かない。その中でどんどんエスカレートして行く犯罪……。公私の別がなく上司に逆らえないところも怖いですね。喫煙させられる、子どもの名前をつけられる。逃れられない。
一番恐ろしかったのは、トイレにカッターナイフが置かれているシーンですね。誰も何も言わないけれど、ただ置いてあるという……。
2010年4月20日(火曜日)
USBキーボードからの感染
公開: 2010年4月25日1時55分頃
これは目から鱗ですね……「自動起動を無効にしても防げないUSB攻撃、ほとんどのOSが該当 (journal.mycom.co.jp)」。
USBメモリを挿したら自動起動でマルウェアが動作して感染、というパターンは良くありますが、OS側で自動起動を無効にすれば対策できます。が、USBメモリではなくキーボードを挿した場合、自動起動が無効になっていても関係なく、キーボードとして認識されるわけですね。そして、キーを打てばコマンドを実行することができます。
というわけで、悪意あるコマンドを実行するようなキー操作を自動的に送るキーボードデバイスを用意し、それを挿せば感染活動ができるわけですね。しかも、見た目がキーボードである必要はありません。USBメモリのように見えるがキーボードとして認識されるものを作れば良いわけです。
もっとも、専用の物理デバイスが必要になりますので、この仕組みで2次感染、3次感染と拡大して行くのは難しそうではありますね。標的を絞った攻撃には十分使えそうですが。
関連する話題: セキュリティ / コンピュータウィルス
2010年4月19日(月曜日)
TLDにAレコードが設定される
公開: 2010年4月24日22時55分頃
「http://to./が開けるしくみ (d.hatena.ne.jp)」。
http://to./ にアクセスを試みると、アクセスできてしまうというお話。なんと、TLD(トップレベルドメイン)そのものにAレコードが設定されているのですね。
※http://to/ ではイントラネットのホスト名とみなされてしまいますが、http://to./ としてやればFQDNとして扱われます。ちなみに上記では問題なく解決できるように書かれていますが、実はMicrosoftのDNSキャッシュサーバではこの名前を解決できないようで、SERVFAILが返ってきてしまいます。
こうなってくると、やはり気になるのはCookie Monsterの問題です。domain=.to のCookieが発行できると、.toドメインのサイト全てに影響が出てくる可能性があります。
なんだかいろいろな意味で心配になってきますが、大丈夫なのでしょうか。
サナギさん
公開: 2010年4月24日15時45分頃
面白そうだったので購入。
- サナギさん 1 (www.amazon.co.jp)
表紙の絵がなんか見えそうな感じなのが……この絵柄で見えたとしても何もないと思うのですが、それでも気になるという。
「毒舌系ほのぼの4コマ」と称しているようですが、考えさせられるネタも多いです。しょっぱのな「守ろうよ わたしの好きな 街だから」へのツッコミからして面白かったですね。
絵は幼い感じですし、ダジャレも多いですが、所々に知性を感じるネタが光ります。
※サナギさんは佐名木さんなのかと思いきや、下の名前なんですね。
2010年4月18日(日曜日)
Opera mini for iPhoneではオレオレ警告が出ない
公開: 2010年4月24日0時55分頃
Opera mini for iPhoneではオレオレ証明書が警告されない (d.hatena.ne.jp)。https://bakera.jpが役に立ったようで何よりです。
話としては、こういうことですね。
- Opera mini ではオレオレ証明書のサイトにアクセスしようとしても警告が出ず、何事もなかったようにアクセスできてしまう。
- オレオレ証明書のサイトでは鍵マークが出ないという挙動になるのだが、鍵の存在が分かりにくい (しかも、ちゃんとした証明書を使っているサイトでも鍵が出ない事があるというバグがあるのでなおさら分かりにくい)。
なお、そもそもの話として……。
そもそもこの鍵マークにどの程度の意味があるのか謎です。Opera miniは表示の高速化の為に専用サーバがコンテンツを変換して返すようになっています。変換する為には一度平文に戻さなければならない為、SSL通信はOpera miniの専用サーバで終わります。専用サーバからOpera miniまでの通信がどうなっているのか分かりませんが*1、少なくとも通常のSSL通信とは異なる状態になっていることは確かです。たとえ鍵マークが表示されていたとしてもOpera miinの専用サーバは通信の内容を知りえる状態になっているということを認識しておく必要があります。
……と、中間者攻撃みたいな状態になっているわけですね。まあ、アプリを入れている時点でOperaを信用している前提になるはずですので、Operaのサーバを信用する前提自体は問題ないのでしょうけれど。
ただ、見ていると、どうもサーバ証明書の内容を確認する機能も無さそうなのですが、困らないのでしょうか。特にSubjectの組織名などは確認したい時もあると思うのですが……。Operaのサーバは証明書を確認しているはずなので、理論上はいちおう出来そうな気もするのですが、どうなのでしょうね。
2010年4月15日(木曜日)
ハッカージャパン2010年05月号
公開: 2010年4月24日0時55分頃
ハッカージャパン2010年05月号 (www.amazon.co.jp)
読みたいとつぶやいたら、「bakeraさんなら読む必要ないすね。 (twitter.com)」と言われたのでどうしようかなぁと思いつつ、近所の本屋に置いてあったのでちょっとめくってみました。
内容としては、情報セキュリティ早期警戒パートナーシップの簡単な紹介、IPAのインタビュー、届出の流れの説明、といったところですね。インタビューの内容の大部分はパートナーシップガイドラインに書かれている事だったりするのがちょっと残念でした。
※その後にも何かちょっと書いてありますが、良く分かりませんでした。脆弱性ではないものが何故か受理されてしまったという話のようにも思えますが、良く分かりません。
関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ / Twitter
ハッシュタグが追えなくて
公開: 2010年4月19日16時15分頃
Twitterをテーマにした(?)「素直になれなくて」というドラマが放送されたそうで、#sunanare (twitter.com)を追っていたのですが……あまりにも流量が多くて、読んでいくとすぐに「スクリプトが応答していません」みたいなことを言われてしまうという。
単にTwitterのWeb UIが微妙という話なのだと思いますが、Twitterクライアントでハッシュタグを追えるものってあるのでしょうか。みなさん、流量の多いハッシュタグを追いたいときはどうされているのでしょうね。
2010年4月14日(水曜日)
XSS攻撃の実例
公開: 2010年4月17日23時5分頃
「Apache狙いの攻撃発生、パスワード流出の恐れも (www.itmedia.co.jp)」。
Apacheによれば、攻撃には短縮URLサービスのTinyURLを使ってクロスサイトスクリプティング（XSS）攻撃コードを仕込んだURLへリダイレクトする手口が使われたという。Apacheの管理者数人がこのリンクをクリックしてしまい、JIRA管理権限を含むセッションに侵入された。
XSS脆弱性によるセッションハイジャックですね。その危険性はずっと昔から指摘されていましたが、実際に攻撃された例はほとんど知られていませんでした。
実例が出てきたことで、これからこの手の攻撃が一般化してくるのでしょうか。
ホスティングサービスで設定ファイルが読まれる話
公開: 2010年4月17日15時30分頃
「WordPressのブログに大量のハッキング被害、不正サイトへ誘導も (www.itmedia.co.jp)」。
セキュリティ企業のSucuri Securityは、ブログでこの事件の原因について、WordPressではデータベースの管理情報がプレーンテキストの状態で保存されるという問題を指摘している。悪意を持つNetwork Solutionsのユーザーが、問題のある設定ファイルを見つけ出すスクリプトを作成してデータベースの管理情報を入手し、ブログのデータベースを改ざんしていたことが分かった。
Network Solutionsでは問題の根本原因を解決したと説明するが、WordPressのユーザーは念のため、管理パスワードの変更を促している。
最初読んだときはWordPressに問題があるという話のように読めて、よく意味が分からなかったのですが……。
良く読むとNetwork Solutions側で問題を解決したとありますから、ホスティングサービス側の問題だったわけですね。同じホスティングサービスを使用している別のユーザーから設定ファイルが読めた、という話のようです。
そういう話であれば、Movable Typeもmt-config.cgiにDBのユーザーとパスワードがそのまんま書いてあるわけですから、全く同じ事が起きます。WordPress特有の問題というわけでも無さそうですね。
専用環境と言うけれど
公開: 2010年4月17日14時50分頃
「三輪信雄氏に聞く、Gumblar騒動と本当のセキュリティ (ascii.jp)」。
今回のGumblarで言えば、Webサイトにコンテンツをアップロードするためだけの環境を用意して、それ以外の用途ではいっさい使わない。これなら、その環境がウイルスに感染する危険性は低いですし、Webサイトに不正なスクリプトが埋め込まれることもないわけです。1つの環境で何でもやろうとするからウイルスに感染して、Webサイトに不正なスクリプトが埋め込まれてしまうわけです。
Webコンテンツを処理するための専用環境を用意。……ってえらく簡単な感じに言われていますが、具体的な作業フローが浮かんでこないのですよね。
その環境にどうやってファイルを持って行くのでしょうか。その環境はWebブラウズもしなければメール受信もしない想定でしょう。となると、ZIPして固めてUSBメモリか何かに入れて持って行くことになるのでしょうか。そうなると、「担当者にZIPファイルを送ってアップロードしてもらう」というのと同じ手間だと思うのですが。
FTPに限定しない一般論として言われているのであれば、エンタープライズCMSのワークフローなどはどう考えるべきなのでしょうか。承認者全員に専用環境を用意する必要がありそうですが。
いくら考えても、Web製作の現場で受け入れられそうなやり方が思いつきません……。orz
2010年4月12日(月曜日)
週刊ダイヤモンドの表紙が大変だ
公開: 2010年4月12日23時0分頃
会社で書架の前を通り過ぎようとしたとき、そこにあってはならないものを見たような気がして、思わず二度見してしまいました。そこにあるはずなのは週刊ダイヤモンドだったはずなのですが……。
- 週刊 ダイヤモンド 2010年 4/17号 (www.amazon.co.jp)
いや、たしかに週刊ダイヤモンドでした。なんと、もしドラ (www.amazon.co.jp)
※誌面には3人並んだ立ち絵のイラストが出ていますが、これ本編にないですよね。書き下ろしなのでしょうか。
2010年4月9日(金曜日)
WEBインベンターがCookieを使うようになった
公開: 2010年4月11日21時50分頃
「URLを知られたらアウトな管理画面」の話ですが、「管理プログラムのセキュリティーの向上 (mag.wb-i.net)」というアナウンスが出ていますね。
ＷＥＢインベンターのご利用に心から感謝いたします。ショッピングカートの管理プログラムのセキュリティーを一層向上させましたのでお知らせいたします。
追加された機能は、次の４つです。
（１）クッキーによるログイン方式。
（２）指定したＩＰアドレスからのみ管理プログラムにアクセスできる。
（３）パスワードの暗号化。
（４）メールフォームのスパム対策など。
以上、管理プログラムのセキュリティーの向上 より
パスワードをURLにつけて引き回すのをやめて、Cookieを使うようにした模様です。下の方にサンプルへのリンクがあるので、早速確認してみると……。
- サンプルのログイン画面にアクセス: http://wb-i.kir.jp/sample/SPF910/setup.cgi (wb-i.kir.jp)
- パスワードに「1234」を入力して「認証」を押す。
- Cookieが使われるようになったらしいので、ブラウザのアドレスバーに javascript:document.cookie と入力してCookieの値を表示。
すると、こうなります。
KanShaDa=1234
……。
ちなみに、表側の方もCookieを使うようになったようです。
- サンプルの会員登録画面にアクセス: http://wb-i.kir.jp/sample/SPF910/entry.cgi?mode=add0&order= (wb-i.kir.jp)
- 適当な値 (たとえば名前=お名前、パスワード=PASSWORD) を入力して「会員登録[確認]」を押す。
- ブラウザのアドレスバーに javascript:document.cookie と入力してCookieの値を表示。
すると、こうなります。
KanShaDa=1234; ENTRY_DATA=%3C%3EPASSWORD%3C%3E%82%A8%96%BC%91O%3C%3E%3C%3E%3C%3E%93s%93%B9%95%7B%8C%A7%3C%3E%3C%3E%3C%3E%3C%3E%3C%3E%8Cg%91%D1%93d%98b%3C%3E%3C%3E%3C%3E%3C%3E%3C%3E%3C%3E%3C%3E%3C%3E
※"%82%A8%96%BC%91O" は、Shift_JISの「お名前」。
ユーザが会員登録時に入力したパスワードや、名前などの個人情報のデータなども、全てそのままCookieに格納しているようですね。Cookieを使うようになったというのは間違いではないようですが、ちょっと普通はしない使い方ではあります。
これだけで直ちに脆弱性と言えるかは微妙なところです。ただ、万が一、どこかにXSS脆弱性があったりすると、生のパスワードや個人情報などがそのまんま漏れてしまうことになります。そうなると、通常のXSS脆弱性よりも被害が大きくはなりますね。
※2011-01-12追記: そして、実際にXSS脆弱性があってパスワードが漏れる状態でした。いちおう修正されたようです……WEBインベンター、XSSを修正か。
2010年4月7日(水曜日)
企業のリンクポリシーが無茶な要求をする理由
公開: 2010年4月7日20時5分頃
「日経新聞電子版始動、しかし個別記事へのリンクを禁止、違反者に損害賠償請求も示唆 (slashdot.jp)」。
またまた出ました。無断リンク禁止。このような主張は、古い企業にありがちなものですね。
- リンクを張る場合は連絡してください。
- リンクはトップページへお願いします。個別記事へのリンクはお断りします。
個別記事にリンクさせないのはナンセンスだ、リンクするたびに連絡しなければならないなんて手間がかかりすぎる。どうしてこんな無茶な要求をするのか全く理解できない。……そう思われる方が多いと思います。
しかし、実はこの要求には理由があります。仕事柄、大企業のWeb担当の方や法務の方と議論させていただく機会もあるのですが、「なぜこんなポリシーを作ったのか」という問いに対する答えは、おおむね以下のようなものでした。
- リンク元のサイトとの関係性を誤解されたくない。
- CI (Corporate Identity, ロゴやシンボルマークなど) を勝手に使わないでほしい。
※あと、フレーム内リンクに関する訴訟の話を聞いたので (Total Newsの訴訟) フレーム内リンク禁止の規定を追加した、とか他にも色々ありますが、ここでは割愛。
前者の話はまだ分かるとしても、後者のCIの話については、ぴんと来ない方もいらっしゃるでしょう。
そもそも、企業サイトへのリンクとはどんなものでしょうか?
そう問われると、多くの方は、「ブログで製品を紹介しつつ、その製品ページへリンクする」とか、「ブログでコンテンツを引用しつつ批評し、引用元にリンクする」とか、そういったものを想像するのではないかと思います。
しかし考えてみてください。そもそも、20世紀には「ブログ」というものが存在していませんでした。トップページにはアクセスカウンターが付いていて、URLには /~ が含まれていて、ベッコアメが全盛だった、そんな時代です。そして、必ずと言って良いほどあったのが、「リンク集」というコンテンツ。どのサイトに行っても「リンク集」というページがあって、バナー画像が並んでいたものです。項目は多いほど良いと思われていたのか、関連サイトはもちろん、Yahoo! Japanや作者お気に入りのサイトなど、何でもかんでも列挙されていました。
これは、企業としては警戒するべきポイントになります。
ブログ記事での紹介と違って、リンク集には脈絡が無い場合がほとんどです。コメントがつけられていたとしても、「いつもお世話になっています」というような曖昧なものだったりすると、取引関係があると誤解されるおそれがあります。また、他の企業と並べて掲載されることもあり、そうすると前後の企業との関係性を誤解される可能性もあります。
また、リンク集にはバナーがつきもので、中にはロゴを勝手に使うような人もいました。会社と無関係な個人に、勝手にロゴを使われるのは困ります。子会社や販社のサイトであればロゴを使っても良いのですが、その場合、ロゴがCI規定に従って正しく使われているかどうかチェックする必要があります。
こういう状況で策定されたのが、無断リンク禁止のポリシーです。このポリシーによって、企業は以下のようなことを要求しました。
- リンク集での紹介のされ方、ロゴの使われ方などをチェックしたいので、リンク集に掲載するときには事前に連絡して欲しい。
- リンク集に掲載するときは、配下のページではなく、トップページにリンクするようにして欲しい。
こうして見ると、それほど無茶な要求でもないと思いませんか。リンク集に掲載するのは1回だけでしょうから、連絡もそのときの1回だけで良いわけですし、リンク集からリンクするときは、普通トップページにリンクするでしょう。当時はこれでちゃんと目的が果たせたのです。
しかし今や、そんな「リンク集」はほとんどみかけなくなりました。「リンク」という言葉からは、「ブログ等で何かを紹介したり批評したりする目的で、企業の個別ページを紹介するもの」が連想されるようになりました。
改めてまとめると、こういうことです。
- 企業は、個人サイトの「リンク集」を想定してリンクポリシーを策定した。ここで言う「リンク」とは、「リンク集に掲載する、企業のトップページへのリンク」を想定したものだった。
- しかし現在、個人サイトの「リンク集」はほとんど消滅。「リンク」の意味合いは異なるものになっている。
無断リンク禁止のポリシーは、今や完全に時代遅れのものとなりました。そのようなポリシーは、ただちに見直すべきです。実際、リンクポリシーを見直した企業もたくさんあります。
しかし残念なことに、時代遅れのポリシーを掲載し続けてしまっている企業があることも事実です。それは、ポリシーが適切だと思っているというよりも、見直しの機会がなかったとか、今まで問題が起きていないからとか、そういった消極的な理由であることが多いようです。
さらに残念なのは、その時代遅れのポリシーをコピーして増殖させる人がいることで……。
中には、「どうせ読まれないからこのままで良いのだ」と思われている方もいるようですが、企業サイトの一部として掲載する以上、そこに掲載された文言は企業コミュニケーションの一部になります。リンクポリシーを制定した当時の意図を理解した上で、積極的に見直しをしていっていただきたいと切に願います。
関連する話題: Web
2010年4月6日(火曜日)
子ども手当のあれこれ
更新: 2010年4月8日1時45分頃
子ども手当に関して、いろいろなデマ情報が飛び交っているようですね。見た瞬間に「これはありえない」と思えるようなものもリツイートされてくるのですが、笑い話としてリツイートしているのか、本気で信じているのか、判断に苦しみます……。
とりあえず、厚生労働省のサイトに「厚生労働省：子ども手当について (www.mhlw.go.jp)」というコンテンツがあります。受給の要件なども書かれているので、「そんなアホな!?」と思ったら、リツイートする前に一読してみると良いのではないかと思います。
そんなあれこれに対応するためなのか、新たに「子ども手当について 一問一答」というドキュメントが追加されたようです。たとえば、以下のような項目について回答されています。
- 児童養護施設に入所している子どもにも子ども手当は支給されますか。
- 子ども手当は在日外国人の子どもが海外に居住する場合にも支給されるのですか。
- なぜ、平成２２年度の子ども手当から子どもの日本国内居住要件を設けないのですか。
さらに読んでいくと、こんなピンポイントな質問も。
母国で５０人の孤児と養子縁組を行った外国人にも子ども手当は支給されますか。
A. 母国で５０人の孤児と養子縁組を行った外国人については、支給要件を満たしませんので、子ども手当は支給されません。
以上、子ども手当について 一問一答 より
というわけで内容はまともなのですが、しかし……何なのでしょうね、このフォントは。同じところに掲載されている他のPDFは普通にゴシックや明朝体が使われているのですが、この一問一答だけは何故かポップ体のフォントが使われています。それも見出しだけならともかく、本文も全てポップ体の太字なので、読みにくいこと読みにくいこと。
いったい、どういう意図でポップ体を選択したのか。その意味は私には一つしか考えられませんでした。すなわち、これは……ちよちゃんの台詞だということです! つまり我々は、この文章をちよちゃんの台詞とみなして読めば良いわけですね。
※初期のあずまんが大王 (www.amazon.co.jp)
まあ、それ以前に、PDF形式になっていること自体どうなのかという疑問もありますけれども。もう少し読みやすくならないものでしょうかね……。
※2010-04-08追記: HTML版も用意されたようです……「子ども手当について 一問一答 (www.mhlw.go.jp)」(Argrathさん情報ありがとうございます)。元のPDFよりだいぶ読みやすくなっていると思います。
2010年4月3日(土曜日)
URLを知られたらアウトな管理画面
更新: 2010年4月3日23時20分頃
メッセサンオー (www.messe-sanoh.co.jp)で個人情報が流出したというお話が。
- 秋葉原ゲームショップの顧客情報が閲覧可能に - アダルトソフト購入履歴なども流出 (www.security-next.com)
- ＰＣゲーム通販大手の顧客名簿が流出 (www.yomiuri.co.jp)
- メッセサンオー、PCゲーム通販の顧客情報がネットで流出 (internet.watch.impress.co.jp)
Internet Watch の記事には追記がありますね。
なお、メッセサンオーが通販サイトで導入していたショッピングカートを提供するWEBインベンターは、Googleにインデックスされないように対策した最新の管理プログラムを公開し、利用者に対して適用を呼びかけている。
ほう、最新版を使用していなかったのが悪い……ということなのでしょうか?
その「WEBインベンター」のサイトを見ると、ショッピングカートCGIの紹介ページ (wb-i.net)があり、サンプルが公開されています。たとえば、Contents-Mall (148,000円) のサンプルは以下のURLで見られます。
- http://wb-i.kir.jp/sample/Contents_Mall/ (wb-i.kir.jp)
左メニューの下の方に「管理者用」という項目があり、クリックするとログイン画面にたどり着きます。
これはサンプルなので、誰でもログインできるようにログイン画面にパスワードが書いてあります。パスワードは「1234」なので、パスワードを入力して「認証」ボタンを押します。すると管理用のメニューが出るので、適当に「会員管理」あたりを選んで右クリックし、別ウィンドウ (あるいは別タブ) で表示してみます。アドレスバーのURLはこうなります。
URLの末尾に燦然と輝くpass=1234の文字。その後、適当に会員の情報を見て行くとURLは次々変わりますが、末尾には常に pass=1234 がついてまわります。また、pass=1234の部分を削ってアクセスしてみると、パスワード入力を求められる画面になります。
つまり、URLにパスワードをつけて引き回しているわけです。何らかの事情でどこかのURLを知られると、それだけで管理画面の全ての機能にアクセスされてしまいます。……これ、パスワードによる認証というより、秘密のURLによる管理に近いですね。
通常、URLは秘密情報としては扱われません。ブラウザはURLにパスワードが含まれているなんてことは知らないわけですから、普段どおりにRefererを送りますし、履歴にも残します。行動履歴を取るようなツールバーを入れていれば、パスワード入りのURLが外部に送出されることにもなります。利用者にしても同じです。「この管理画面を使うときには、絶対にURLを漏らしてはならない」と言い渡されているのならともかく、そうでなければURLを慎重に取り扱うようなことはしないでしょう。ブックマークするかもしれませんし、メールで誰かに送るかもしれません。
「どうして漏れたのか?」という疑問の答えは、ほとんど明白だと思います。
そして、ベンダー(?)のWEBインベンターは、この事件を受けてこんな文書を出しています。
さて、当社のカートを利用しているお店で個人情報流出の事故が発生しました。それは、管理プログラムがGoogleにインデックスされてしまったことによるものです。原因は調査中ですが、しかし、そのような場合でも検索エンジンに拾われないような対策を施してありますので、お知らせいたします。（問題のプログラムは2004年ごろのプログラムのようです。）
(～中略～)
可能なら、最新のプログラムに差し替えることをお勧めいたします。少なくとも管理用のプログラムに下記のMETAタグを挿入すると良いと思います。
print "<meta name='robots' content='noindex,nofollow,noarchive'>\n";
えっ、meta要素の追加? そこですか? そこなんですか?
確かに、上記のようなmeta要素を入れれば、行儀の良い検索エンジンはインデックスしないようにしてくれるでしょう。ただ、それは検索エンジンにそういう動作が期待されるというだけです。行儀の悪い検索エンジンもあるかもしれませんし、そもそも、人間はmetaになんか従ってくれませんから、URLが人に知られれば管理画面にアクセスされてしまいます。
検索エンジンにインデックスされるということは、問題の本質ではないでしょう。問題は「URLが漏れると管理画面の全ての機能にアクセスされてしまう」という点です。ここを解決しない限り、安心して使うことは難しいのではないかと思うのですが……。
※ここから追記:
それから、読売の記事で言及されているCSVファイルなのですが、現在は魚拓からも削除されているようです。そのURLは、"http://www.messe-sanoh.co.jp/cgi/shopweb/csv_lock/order_user.csv"というものだったようで。パスワードすら含まれていないうえに、他の秘密情報も含まれておらず、かなり推測しやすそうですね……。
※ここまで追記
悩ましいのは、このアプリケーションを採用している企業がメッセサンオーだけではないという点です。利用者が指示どおりの対応をしたとして、それで大丈夫なのかというと……。この辺、どうアクションすれば良いのでしょうかね。
2010年4月2日(金曜日)
次期Firefoxでは:visited疑似クラスのスタイルが制限される
公開: 2010年4月3日16時50分頃
「visited疑似クラスのビーコンを拾うサービスが登場」という話がありましたが、Firefoxでの対応方針が決まったようで……「CSS によるブラウザ履歴の漏えいを防ぐ取り組み - Mozilla Developer Street (modest) (dev.mozilla.jp)」。
具体的には、訪問済みリンクは、文字、背景、アウトライン、ボーダー、SVG の線と塗りといった、配色のみ変えられるようにします。
(～中略～)
次に、Gecko レンダリングエンジンの実装にいくつかの変更を加え、訪問済みと未訪問リンクの表示にかかる時間の違いを最小限にするため、処理プロセスを均一化します。
(～中略～)
Web ページがリンク (とその子孫要素) の算出スタイルを取得しようとすると、Firefox は未訪問リンクのスタイル定義を返すようになります。
というわけで、:visited の挙動が色の変更のみに制限されるようですね。
セキュリティ的には歓迎なのですが、影響は結構ありそうです。background-image を使ってリンクにアロー (三角画像) を表示しているスタイルは多くのサイトで見かけます (このサイトも例外ではありません) が、:visited のときにアローの色が変わらなくなります。まあ、アローの場合は色が変わらなくてもさほど問題ないと言えば問題ないと思いますが……。
※たとえばPanasonicのサイト (panasonic.co.jp)のように、そもそもアローの色は変えていないサイトもあります。これはこれで、それほど違和感ないと思います。
ただ、本当に背景画像を敷いているような場合、テキストの色が変わったのに背景画像が変わらないと、読めなくなるケースもありそうですね。
- 前(古い): 2010年3月のえび日記
- 次(新しい): 2010年5月のえび日記
