説明ページ
Windows 10 Insider Previewの、特権不要でのシンボリックリンク作成に対応。

SeCreateSymbolicLinkPrivilegeが定義されているが有効にしなくても作成可能な状況など想定していなかったので、特権の有効化に失敗すると作成をあきらめていたが、エラーを無視して作成を試みるように変更した。

公式には特権不要でのシンボリックリンク作成はBuild 14972から対応したことになっているが、これはSYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATEを初めてサポートしたビルドのようで、それ以前のビルドでも開発者モードにすれば作成可能(しかも特別なフラグも不要)だった模様。少なくともBuild 14931ではすでに対応していたことを確認(それ以前のビルドは手元に残っていないので不明)。

HTML 4

文字参照で使える符号位置(厳密には符号位置ではないのですがここでは深入りしません)の範囲はSGML宣言で定められています。

55296   2048    UNUSED  -- SURROGATES --

このように、55296(十六進数で表すとD800)からの2048個(DFFFまで)の数字は未使用となっています。

XML

文字参照の文法は以下の生成規則により規定されています。

[66]       CharRef       ::=       '&#' [0-9]+ ';'
            | '&#x' [0-9a-fA-F]+ ';'    [WFC: Legal Character]

[WFC: Legal Characeter]の定義を参照すると、文字参照により参照される文字はCharの生成規則に合致しなければならないと書かれています。

Charの生成規則は以下のように定義されています。

[2]       Char       ::=       #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]    /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

このように、XMLにおいて(たとえ文字参照であっても)D800..DFFFのコードポイントを使うと整形式制約に違反します。定義に書かれているように、整形式制約違反はfatal errorです。fatal errorが発生した場合、XMLプロセッサは通常処理を続行してはならないとも明記されています。もっともRSSリーダーにはXMLパーサーすら使わないようなきわめていい加減な実装のものが数多くあるので、通ってしまうこともあるようです。

HTML5

XMLの仕様書と比べると実際に手続き型のプログラミング言語が行う処理を追いかけるような形で書かれていて、非常に読みやすいです。文字参照の処理は、最新の編集者草案では以下のように定義されています。

Otherwise, if the number is in the range 0xD800 to 0xDFFF or is greater than 0x10FFFF, then this is a parse error. Return a U+FFFD REPLACEMENT CHARACTER.

このように、文字参照のD800..DFFFはU+FFFDに置き換えなければならないと明記されています。今のところ仕様に忠実なのは、「HTML5対応」を謳う主要ブラウザの中ではFirefoxだけのようです。もっとも2009年8月25日時点の草案では

Otherwise, if the number is greater than 0x10FFFF, then this is a parse error. Return a U+FFFD REPLACEMENT CHARACTER.

Otherwise, return a character token for the Unicode character whose code point is that number.

だったので無理もないかもしれません。どうでもいいですがパーサーの規定のこんな基本的な部分がコロコロ変わるような状態でどうしてブラウザが「HTML5対応」を名乗れるのか不思議でなりません。仕様が固まるまでMicrosoftが対応を尻込みするのも当然でしょう。

これらの規定は、HTML/XMLにおいてUTF-16のサロゲートペアが使えないという意味ではないことに注意してください。文字参照はUTF-16ではないというだけです。符号位置(code position)/コードポイント(code point)と符号単位(code unit)を混同してはいけません。

BMP外の文字を文字参照で表記するときは、U+10000以上のコードポイントを直接表記するのが正しいやり方ですが、スラッシュドット・ジャパンの日記システムはこの表記をまともに処理してくれません。BMP外の文字を受け付けるように改修するのが大変なら、まともなRSSリーダーには読めないRSSやまともなブラウザが文字化けを起こすHTMLを吐く点(あるいはそういうものの出力につながる入力を受け付ける点)だけでも早く修正していただきたいところです。

もちろん安岡先生はこの程度のことは当然知っていて、BMP外の文字を受け付けないスラッシュドット・ジャパンの日記システムへの抗議のためにわざとやっているのでしょう。

• 岡山県警察と栃木県警察、「無断リンクは禁止とします」
• サルの見守り電波IDタグ、田畑への接近をメールで配信
• フィッシング容疑で続々立件、14歳少年を書類送検、別の詐欺団8人を逮捕
• ターゲットごとにカスタマイズした文面のフィッシングメールが増加中
• 堺市の小学校が電波タグを全児童に 公立校で初
• 「リンクした場合は電話で連絡せよ」と最高裁が要求、しかし理由がない
• 「Winnyの欠陥直させないのが問題」と毎日新聞が社説
• 「見守り」電波タグ続々登場、今度は中学生に
• UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意
• SunのJava実行環境に致命的レベルの脆弱性
• 北九州市と仙台市が小中学校に無断リンク禁止の明示を義務付け
• ネット銀行から不正送金、Winny媒介トロイが原因か

• 見出し無断配信裁判、知財高裁で賠償命令、著作権は認めず
• 小学六年生による不正アクセス事犯で補導
• 右クリックとHTMLソース閲覧の禁止を提供するソフトが登場
• みたけ台小学校のICタグ実験で父兄の賛否分かれる
• EZwebのサブスクライバIDが今日から非通知設定可能に
• 米国のICパスポートは暗号化なしの無線読取り
• 「どうすればFirefoxを信じられる？」の件がやっと対処
• 認証用RFIDタグの暗号が破られ、なりすましの危険性が実証
• Acrobatの脆弱性修正パッチがリリース、ご両親は大丈夫？
• IEにWindowsの環境変数を漏らしかねない機能
• 携帯電話のJava VMにBytecode検証の脆弱性

• 未対策・未発表な多数の国内産脆弱性情報が暴露
• 電波タグによる幼稚園児追尾撮影システムが実用開始
• 電波タグで売上げ倍増、消費者はタグに好意的
• 画像製の偽アドレスバーを使った新手のPhishing詐欺
• カード決済で電話番号の記入不要と消費生活センターが注意
• RFID業界の自主ガイドラインに対抗するプライバシー専門家声明
• 電波タグで児童生徒の登下校情報をメールで配信
• 愛知万博が個人サイトからのリンクを「固くお断り」
• IEに多数の未パッチのセキュリティ欠陥が新たに発覚
• Google「キャッシュ」で鳥取県個人情報流出の2次被害
• EdMax, WeMail32 など複数のメーラにセキュリティホール
• ブラクラ状態の後にダウンロードプログラムを強制実行するIE 6
• Netscape/Mozillaに偽のURL表示が可能な脆弱性
• SafariなどにSSLの証明書検証が働かないバグ
• Operaに再び簡単なセキュリティホールが発覚
• Netscape 7.02以前にcookie漏洩などの脆弱性
• Becky!の独自拡張機能に重大なセキュリティ欠陥
• 高島屋の無線POSも平文だったが1週間で対処、そして顧客へ告知
• プライバシーポリシーには何を書いて欲しい？
• 西武百貨店、無線POSの平文通信を知りながら即時回避策とらず
• Opera 6.05にバッファオーバーフローの穴
• Opera 7に多数のセキュリティホール

タレコミページの記録に、

2004-04-17 20:06:11 電波タグで売上げ倍増、消費者はタグに好意的 (articles,privacy) (却下)

と出ていた。ユーザページでは採用として記録されているのに、「却下」とはこれ如何に？

まあ、間違って記録されても気にしないのだけれど、こういうことも起きるんだなと。一旦却下になった後で拾われたとかかなあ。

採用されたタレコミが24件になったので、この次からは消えていってしまう。自分用にメモしておく。ちなみにタイトルはタレコミ時のもの。

• Cookieをオフにするなら「UserDataの常設」もオフに
• 各社のJava VMに砂場の枠が外れる脆弱性
• Netscape Mailのゴミ箱は空にしても消えない
• IEのXSSバグで任意サイトのCookieが漏洩
• NRAが今年のセキュリティ10大ニュースを発表
• Slashcodeが一部ユーザのパスワードを漏らす
• Excelユーザをリスクにさらす環境省環境安全課
• WindowsとLinuxのセキュリティ: 噂の真相とは？
• iPlanet Web Serverにもバッファオーバーフロー穴
• リンク自由としながら報告を求める日本の府省
• au携帯電話にReferer誤送出欠陥 KDDIは回収せず
• 文化庁がトップページ以外へのリンクを機械的に拒否
• IE まだ開いたままの穴は14個
• IEのFTPフォルダビューにXSS脆弱性で任意コマンド起動の危険
• 岩手県が氏名を「非表示」にしただけでWebで公開
• Operaの一部バージョンに勝手にファイルをアップロードする穴
• Opera 6.01以前にcookie/file/cache漏洩の脆弱性
• Netscape/Mozillaにローカルファイル読みとりの脆弱性
• IEの「戻る」ボタンは危険
• IEとOEに任意コマンド起動の欠陥
• Netscape/MozillaにCookie漏洩のセキュリティホール
• Mac OS版IEに指定パスのアプリを起動できる欠陥
• 今度はニセの証明書に騙される穴
• またまたまたもやIEにセキュリティホール

このところ忙しくてBUGTRAQを700通あまり読み残していたのだが、一気に読み漁ったところ、今まで気づいてなかったネタがいくつか見つかった。いちおう公平にと思い、Netscapeネタ、IEネタ、Javaネタを連続してタレこんだ。

2003-01-18 18:54:29 Netscape Mailのゴミ箱は空にしても消えない
2003-01-18 21:12:02 IEのXSSバグで任意サイトのCookieが漏洩
2003-01-19 01:59:16 各社のJava VMに砂場の枠が外れる脆弱性
2003-01-19 03:55:16 Cookieをオフにするなら「UserDataの常設」もオフに

IEネタの採用は早いなあ(^_^;)。13分。はや。たまたまなんだろうけどね。Netscapeネタは小ネタでしたか。

帰ってきてみると、採用されていたIEネタのストーリーがずいぶんと荒れている。脆弱性ネタをここにタレこむのは一昨年の暮れから始めた。一時期はBUGTRAQをウォッチするとともにできるだけ早くタレこむようにしていた。当初からずっと同じ方針で、BUGTRAQで既に公開されてしまった攻撃方法を日本語で伝えるようにしてきた。日本の技術者には言語の壁があって、この種の情報に疎くなっていると以前から思っていたからだ。以前はあんな反応はなかったのだけどなあ。

slashcodeのメンテナのひとりであるJamie McCarthy氏が、9月18日にBUGTRAQに流した記事によると、

• 最初の報告者とこの件に関心を持った何人かの人々とメールをやりとりし、彼らから提供されたreferer_logに記録された事例を確かめたところ、その全てが、無効なパスワードとなっていた。
• この方法でログインしたとき、ログインに成功した場合には、自動的に問題のないURL（ユーザ名やパスワードを含まない）にリダイレクトしているので、それらが漏れることはない。これは少なくともversion 1.0.0（2000年3月）からこのようにしてきている。
• それに対して、ログインに失敗した場合、つまり、パスワードを変更していて、ブックマークしたときのものではログインできない場合には、リダイレクトがなされない。

のだという。

つまり、ユーザ名とパスワードを含むURLが漏れたのは、ログインに失敗したときなのだろうというわけだ。

この状況について同氏は、ユーザが次のようにしている場合には問題となっているだろうとしている。

• 他のサイトで同じユーザ名を使用していて、
• 他のサイトで同じパスワードを使用していて、
• 辞書攻撃されるようなパスワードを使用していて、
• 「全く安全ではない」リンクをブックマークしていて、
• 後にそのパスワードを変更していて、
• そのブックマークを使い続けている（もうログインできないのに）場合

ほとんど滅多にそんな場合はないという感じだが、同氏が挙げなかった次のシナリオも考えられるのではないだろうか。

• 「全く安全ではない」リンクをブックマークしていて、
• 後にパスワードを変更していて、
• その後にそのブックマークを使ったことがあり（ログインはできなかったはず）、
• さらにその後にパスワードを元のものに戻して、現在もそれを使っている場合

こちらは、それなりに該当者がいそうな気がするので、注意が必要だと思う。

同氏は、slashcodeを次のように変更すると述べている。

• ログインに失敗した場合でも、問題のないURLにリダイレクトするようにする。
• この"totally insecure"オプションをユーザに提供するには、変数のセットが必要となるようにする。これはデフォルトでオフにする。

今現在、slashdot.jpで試してみると、ログインに失敗したときもリダイレクトされるようになっているようだ。既に対策されたバージョンに置き換えられているのだろうか。

タレコミでは紙面の都合上簡潔に書かざるを得なかったので、ここではもう少し具体的に説明をしてみる。

まずは、スラッシュドットにログインした状態でパスワードの変更の画面に行ってみてほしい。「jbeef (1278)のパスワード変更」のタイトルの下に以下のメッセージがあるはずだ。

このリンク をクリックすると，自動的にログインすることができます．クリックした先のページをブックマークしてください．全く安全ではないですが，とても便利です．

「リンク」の部分のリンク先は以下のようなURLとなっているはずだ。

http://srad.jp/index.pl?op=userlogin&upasswd=05a671c66aefea124cc08b76ea6d30bb&unickname=jbeef

「upasswd=」の右側はパスワードのハッシュ値(MD5)となっている。上の例はデモとしてパスワードを仮に「testtest」とした場合の値で、もちろん今は別のパスワードにしている。 このURLには、ユーザ名とパスワード（のハッシュ値）が両方含まれているので、このURLにアクセスするだけでログインができる。これをブックマークとして登録しておけば、メニューからそれを選ぶだけでログインできるので「とても便利です」というわけだ。

説明には「クリックした先のページをブックマークして」とあるが、実際にやってみると、クリックした先のページは、

http://srad.jp/index.pl

となることが観察されることと思う。これは、ログイン手続きが完了した後に、このURLにリダイレクト（自動ジャンプ）しているためだ。「クリックした先のページをブックマークして」（本家の原文では「You can automatically log in by clicking This Link and Bookmarking the resulting page」）という指示に単純に従うと、

http://srad.jp/index.pl

をブックマーク登録することになるので、この説明は正しくない。 正しくない説明となっているのはなぜだろうか。考えられるのは、古いバージョンのslashcodeではリダイレクトされなかった可能性だ。説明文だけ元のまま残ったものなのかもしれない。

何が問題かというと、表示中のページのURLは容易に第三者に漏れてしまうものであり、URLにパスワードやユーザ名を含めることは危険だという点である。具体的には、上の方法でログインした直後に、トップページにあるストーリーのリンクをクリックして、リンク先にジャンプすると、リンク先のサーバに対して、リンク元のURL、すわなち、

http://srad.jp/index.pl?op=userlogin&upasswd=...

が、リンク先のサーバに送信されてしまう。これは、Webブラウザの機能であり、アクセスのリクエストデータの中に

Referer: http://srad.jp/index.pl?op=userlogin&upasswd=...

という形式で挿入されて送信される。これは、サーバ側では、（サーバがApacheの場合）「referer_log」ないし「access_log」に記録されるようになっていることが多い。

先に述べたように、ログイン後のURLは

http://srad.jp/index.pl

にリダイレクトされるのだから、Refererでユーザ名やパスワードが漏れることはないはずである。ところが、私のサーバのアクセスログを調べてみたところ、昨年11月のログに、1件だけだが

http://srad.jp/index.pl?op=userlogin&upasswd=...

の形式で、あるユーザのログイン用URLが記録されているのが見つかった。なぜ漏れてきたのだろうか？また、なぜ1件だけと少ないのか？

この疑問には、18日のJamie McCarthy氏の報告で、ある程度納得することができる。これについては次のエントリで。