■ 位置特定につながるSSIDの割合は約17% （東海道新幹線沿線2007年8月調べ） 昨日の日記に書いた件、実際に、無線側MACアドレスを割り出されそうなSSIDがどのくらいの割合で存在しているのか気になったので、10月21日の日記の図1〜3で使用したデータを基に集計してみた。 このデータは、今年8月に東海道新幹線で名古屋から品川まで移動した際に、車中でNetwork Stumblerを稼動させてビーコン信号を検出したもので、全部で1760個のアクセスポイントがあった。 そのうち、9.7% は、ビーコン信号にSSIDを載せない、いわゆる「ステルス」設定のアクセスポイントで、これは実際にどんなSSIDが設定されているか不明であるため、次の集計から除外した。 なお、アクセスポイントをステルス設定にしていても、それに接続したことのあるWindows XPの無線LANクライアントは、そのSSID

■ デイリーポータルZ 記者の家を探しに行く 5月27日の日記「PlaceEngineのプライバシー懸念を考える」では次のように書いた。 つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス（および類似のサービス）が新たに作り出したことになる。 「MACアドレスは個人を特定するものではない」と言えるだろうか？もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。 PlaceEngineなどのサービスが存在する現

■ EZwebサイトでSession Fixation被害発生か？ au booksでの事故 意図的な攻撃でなく偶発的な事故なのかもしれないが、auの公式サービス「au books」のEZwebサイトで、Webアプリケーションの脆弱性が原因の情報漏洩事故が起きたようだ。 顧客情報漏えい：書籍販売サイト「ａｕ　Ｂｏｏｋｓ」で, 毎日新聞, 2007年6月26日 ゲーム攻略本（１冊１８９０円）の紹介サイトからアクセスし、その攻略本を買おうとすると、他の顧客の氏名、住所、電話番号、生年月日、会員パスワードが表示された。そのまま購入手続きをとると、他の顧客が購入したことになってしまうという。 au携帯電話におけるオンライン書籍販売サイト「au Books」におけるお客様情報の誤表示について, KDDI, 2007年6月26日 1. 発生事象 本年6月22日20時37分から23日18時45分までの間

■ 公務員研修で体験させておくべき演習 「蛍光ペンで墨塗り」の巻 隠したはずの個人情報丸見え 千葉市教委のホームページ, 朝日新聞, 2006年8月1日朝刊 ＨＰ墨塗り情報、丸見え 千葉市教委が謝罪, 朝日新聞, 2006年8月2日朝刊千葉版 同市は０２年末、システムからの情報漏洩（ろう・えい）などを防ぐため「情報セキュリティポリシー」を作り、対策を進めてきた。（略）市のＨＰを担当する情報政策課の（略）課長補佐は「（今回の問題を）３１日夜に聞いたときは正直驚いた。さらなる注意を職員に呼びかけていくしかない」とショックを隠さなかった。 という報道が出ている。この種の事故については2003年7月29日の日記にも書いていた。そのときは「フォントの背景色を黒にした」？と書いていたが、Microsoft Wordの「蛍光ペン」機能を黒色で使ったのではないかと予想した。当たりだった。 千葉市教委ＨＰ「

先月、朝日新聞社「論座」のインタビューを受けたものが記事となり、今月5日発売号に掲載されている。 ウィニー騒動の本質 あまりにも情報流出のリスクが大きい, 論座 2006年5月号 ここで確認しておきたい論旨は次の点である。 情報流出はウィニーだけの問題ではないとの声もある。だが、ウィニーの登場で情報漏洩による被害は格段に深刻なものとなった。ウィニーから流出した情報は、ほとんど自動的に無制限に広がっていく。回収する手段は皆無と言っていい。その深刻さは、今年3月に注目された新種のコンピューターウイルス「山田オルタナティブ」と比較すれば一目瞭然だ。「山田」に感染すると、パソコン内のデータが全部、外部から直接閲覧できてしまう。しかし、感染に気づいてパソコンをインターネットから切断すれば1次流出はそこで止まり、積極的に2次流出させる第三者がいない限り、それ以上は拡散しない。他人の個人情報を2次流出さ

水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更

■ 適切な脆弱性修正告知の習慣はなんとか広まらないものか 2日の日記の件について、伊藤直也さんからトラックバックを頂いた。話は2つに分ける必要がある。1つ目は、一般にソフトウェア開発者・配布者が、配布しているソフトウェアに脆弱性が見つかって修正版をリリースしたときに、ユーザに伝えるべきことは何か、また、どのような方法で伝えるべきかという話。2つ目は、JVN側の改善の余地の話。 1つ目の話 はてなは以前から、Webアプリに脆弱性の指摘があって修正した場合、それを「はてな○○日記」で事実関係を公表してきた*1。これは、他のWebサイトの大半がそうした公表をしていない*2のと比べて、先進的な対応であると言える。 しかし、今回のはてなツールバーの脆弱性は、Webアプリの脆弱性ではなく、「ソフトウェア製品の脆弱性」である*3。一般に、Webサイトの脆弱性は、修正した時点でその危険性は解消するという性

■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

■ CSRF対策は進んでいるか 7月3日の日記で「クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか」というのを書いたが、 ようするに、CSRF攻撃によってどんな被害が起きるのかが、各サイトの各ペー ジごとに異なり、その差が大きいため、一律に対策が必要ということは誰にも 言い出せなかったためと思われる。日記で、 たとえば、4月19日の「水無月ばけらのえび日記」などにも書かれているように、パスワード変更機能で旧パスワードの同時入力がないと、CSRFによってパスワードを強制的に任意の文字列に変更されてしまうという脅威があることになる。変更したパスワードで不正アクセスされれば、それによって起きる被害は、ユーザに降りかかってくる。 他にも、ログイン中のWeb操作で変更が可能な設定項目によって、公開か非公開かを変更できるようなシステムの場合、非公開にしていたはずのコン

■ ITmediaが利用規約から無断リンク禁止条項を撤廃 Webメディア御三家、つまり、INTERNET Watch、ITmedia（旧ZDNet JAPAN）、 日経IT Proと言えば、日本のWeb文化をリードしてきた新時代のマスメディアだ。 旧態新聞会社達が決して扱うことのなかった話題を、いつも期待を裏切ること なく報道してくれた頼れるメディアだ。たとえばこんな報道があったのも Webメディアならではと言えよう。 文化庁、「ディープリンクを拒否するつもりはない」, ITmediaニュース, 2002年7月10日 旧態マスメディアの主要な何社かが、記事ページへの無断リンク*1を禁止すると定めているところ、 そのナンセンスさはこれまでにも幾度となく議論されてきた。 しかし、実はITmediaが利用規約で無断リンクを禁止しているというのは、 知る人ぞ知る事実であったものの、あまり積極的に語

■ 「セキュリティ屋」がセキュリティを駄目にした 先日のスパイウェア感染を招く指示が警察庁サイトなどに書かれていた話や それに類似の事案を多数見るにつけ、 いったいどうしてこんなことになってしまったんだと、 崩れおらずにはいられない。 そもそも、ActiveXコントロールを使うにあたってセキュリティ設定は変える 必要がない。初期設定のままで普通に動くからだ。 たとえばIBMの「らくらくWeb散策」の説明ページを見ても、次のように書かれ ている。 らくらくウェブ散策の動作環境 JavaScript、CSS(Cascading Style Sheets)、署名済みActiveXコントロールを 利用できるようになっている必要があります。(通常は既に利用でき るようになっています。) お客様の安全に関わることといったら、事業者達にとって発言に慎重にならざ るを得ないはずだ。先日、東急ハンズにワイヤ

■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状

■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追