最近一週間ほどのえび日記
2011年12月6日(火曜日)
マリオカート7 星ひとつ
公開: 2011年12月13日0時35分頃
マリオカート7 (www.amazon.co.jp)、150ccミラーまでの全グランプリをクリア。エンディングは既に見ていましたが、全グランプリをクリアするとエンディングの最後が少し豪華になっていて、さらにタイトル画面がランダムに変化するようになります。
50ccと100ccはオール三つ星クリアを達成していましたが、150ccには星なしのグランプリもあったりしたので、少し走り込んで全グランプリで星一つをつけました。すると、レース後の順位表示などで自分の名前に星が表示されるように。
※星がつくのはゴールした瞬間らしく、最後に星を付けたグランプリの順位表示画面で既に星がついていました。評価が発表される前に星がつくので、ちょっと違和感がありますね。
と同時に、「ゴールドタイヤ」というパーツがもらえました。すごい性能というわけでもなく、オマケっぽいですが。
この調子で、次は二つ星をつけようかなと。経験上、二つまでは簡単につくと思うのですが、その後はなかなか……。
- 「マリオカート7 星ひとつ」にコメントを書く
2011年12月5日(月曜日)
公衆無線LANによる通信傍受、改竄のリスク
更新: 2011年12月13日23時35分頃
ものすごい話が出ていますよ……「公衆無線LANのConnectFree、利用するとTwitter IDとFacebookをMACアドレスと紐づけられ、いつどこでどのサイトを閲覧したか収集されるらしい (togetter.com)」。
以前から言われていた攻撃手法として、以下のようなものがありました。
- 悪意ある攻撃者が、無線LANのアクセスポイントを公開する
- SSIDを公衆無線LANサービスと思われるようなものにしておく
- 誰かがそのアクセスポイントにアクセスすると、攻撃者は通信内容を自由に傍受・改竄して攻撃できる
そして「野良無線LAN危ないから気をつけて」「HTTPSを使おう」という話になるわけですが、今回は、こういう攻撃が実際に、しかも公衆無線LAN提供会社によって組織的に行われていたという話ですね。おそらく当人には「攻撃」という意識はないと思いますが、内容を見ると立派に傍受と改竄を成功させていますし、脅威にもなっています。これは攻撃と言われても仕方ないでしょう。
改竄の内容は以下のようなものだそうで。
- Webページの上部にツールバーのようなものが出現するようにスクリプト等を埋め込み
- Google Analyticsのタグ埋め込み
- Amazonのアフィリエイトが埋め込まれていたら、そのアフィリエイトIDを改竄 (HTMLを直接改竄しているわけではなく、改竄するようなスクリプトを埋め込み)
どれも問題ですが、あえて最も悪質なものを挙げるとすれば、アフィリエイト報酬の奪取でしょう。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年12月4日(日曜日)
ターゲティング広告を利用して属性と個人を結びつける
公開: 2011年12月11日22時55分頃
「サードパーティCookieの歴史と現状 Part3 広告における利用、トラッキング、ターゲティング広告におけるプライバシーリスク (d.hatena.ne.jp)」。サードパーティCookieやターゲティング広告の問題点についてのmalaさんのまとめ。良くまとまっていて参考になります。
特に、「パーソナライズされた広告配信によって広告出稿者がユーザーの個人情報を取得することが可能」という指摘は鋭いと思いました。ターゲティング広告では、対象者の属性を絞って広告を出すわけですから、その広告をクリックしてきた訪問者はその属性を持っている確率が極めて高いと言えます。すなわち、以下のようなことが起きると個人と属性が結びつきます。
- 属性を絞って広告を出稿する
- その広告をクリックしてランディングページにたどり着いたユーザーを追跡する
- そのユーザーが商品を購入するなどして個人情報を入力する
ポイントは、事前に個人を識別しておく必要がないという点でしょう。広告が出た時点では個人を識別できていないのですが、その時点で属性情報を収集しておけば、その後に個人が特定された時点で結びつけられます。
これはもちろん普通に起きることなので、ターゲティング広告を出稿している側は、結びつけ放題です。絞る属性の種類によっては問題ない事もあるでしょうが、機微な嗜好の情報など、結びつけて欲しくないものもあるでしょう。しかも、ある広告がターゲティング広告なのかどうか、どのような属性を指定しているのか、といったことはユーザーには分かりませんから、自衛するのも難しいわけですね。
この点、Googleは自主規制しているそうで、
ただし、人種、宗教、性的嗜好、健康、金融など、機密性の高い情報に基づくインタレスト カテゴリをブラウザや匿名 ID に関連付けたり、インタレスト ベース広告の掲載にそれらの情報を使用したりすることはありません。
このように「やりません」というポリシーを明示することが必要になってくるでしょう。
malaさんは以下のように述べられていますが、
「特定個人を識別できるかどうか」ばかりが問題になり、広告主が訪問者のユーザー属性を収集することが出来るという点があまり問題視されていない。
以上、サードパーティCookieの歴史と現状 Part3 広告における利用、トラッキング、ターゲティング広告におけるプライバシーリスク より
これはその通りだと思います。個人の識別さえされなければ何をしても良い、と言っているようにしか思えない論説はよく見ますね。
もっと言うと、その「個人を識別」という部分の理解も怪しくて、「住所や実氏名が分からなければ個人を識別したことにならないから問題ない」といったような主張をする人も多いように思います。実際には、個人情報保護法でも以下のような定義になっているのですが。
この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
以上、個人情報の保護に関する法律 より
括弧内に注目。「Cookieでは個人の識別はできない」などと平然と書いている事業者をたまに見ますが、実際にはそれで識別できる場合があるから問題なわけで、そのあたりきちんと理解してもらいたいと思います。
2011年12月2日(金曜日)
ゼルダの伝説 スカイウォードソード クリア / 辛口モード
公開: 2011年12月11日21時15分頃
「ゼルダの伝説 スカイウォードソード (www.amazon.co.jp)」、ようやくクリア!
ラスボスがメチャクチャ強かったです。隙がほとんどなく、たまにできるわずかな隙をうまく突く必要があるのですが、少しタイミングがずれるとこちらがやられてしまうという強敵。一度負けて、街に戻って薬を補給、薬を4回も使用して何とか撃破しました。
……そしてクリア後に改めてヒント映像を見たら、実は楽な倒し方があったというオチ。知らんがな……。
クリア後は「辛口モード」に突入。辛口モードでは、以下のような違いがあります。
- 敵から受けるダメージが2倍
- ハート、ハート花が出ない (ハートメダルを持っていると出るようになります)
- スカイウォードがいきなり最強
- 一部のキャラの台詞が異なる (主にチュートリアル系)
ダメージ2倍も厳しいですが、ハートが出ないのがつらいです。1周目ではあまり意味がないと思っていた回復できる椅子が神に変わります。ちなみに妖精は出るので、妖精ビンも頼りになります。
初期はハートが6つしかないのですが、最初のダンジョンでスタルフォスのスマッシュ攻撃を喰らうとハート4つ減るのでまあ何とも、という感じです。そうは言ってもプレイヤースキルが上がっているので、意外にサクサク進んで行きます。格好良く戦えるようにもなっていますし、2周目は面白くなりそうです。
2011年12月1日(木曜日)
マリオカート7
公開: 2011年12月11日14時35分頃
ニンテンドー3DSのキラーコンテンツと思われるソフトその2、ついに発売!
- マリオカート7 (www.amazon.co.jp)
まだあまりやり込んでいませんが、ひとまず50ccのグランプリをプレイ中。操作性はとても良く、DS版 (www.amazon.co.jp)をプレイしていたなら全く違和感がないと思います。「そういえばドリフトってどうやるのだっけ? まあ50ccはドリフトなくても何とかなるからぼちぼち思い出せば良いか」と思っていたのですが、実際にコーナーに突入したら、手が勝手に動いて見事にドリフトしていました。小脳がDS版のドリフトの操作をしっかり記憶していて、全く同じ感覚で曲がれたということだと思われます。
というわけで、DS版プレイ経験にモノを言わせると、50ccグランプリは初見で三つ星 (最高評価) クリアできてしまいます。……いや、スペシャルカップ (レインボーロード) だけは無理でしたが。
今作では、空を飛んだり、水中に入ったりできるようになりました。水中は操作性が悪くなるだけであまり意味がないような気もしましたが、空を飛ぶと上下左右に自由に動くことができるので、コース選択が重要になります。そもそも、今作では分かれ道が非常に多くなっていて、どの道を通るのかで勝負が分かれることが多くなりそうです。
あと、運の要素が強くなっているかも。ジャンプや飛行で谷を越えるシチュエーションが多いのですが、飛行中にトゲゾーこうらを喰らうと転落人生が待っています。DS版でもそういうことはありましたが、今回は飛行やジャンプのシーンが圧倒的に多くなったので、転落も多いです。誰かがトゲゾーこうらを取ったら必要以上に飛ばない、という戦略も必要になるのかも。
※しかしゼルダ (www.amazon.co.jp)がまだ終わっていない罠。
2011年11月30日(水曜日)
robustな人材
公開: 2011年12月11日13時55分頃
こんな話が興味深いと思いました……「平松さんの支援集会で話したこと (blog.tatsuru.com)」。たいへん長いのですが、後半の「学力とは何か」以降の話が面白いです。
印象に残ったのはこのあたり。
子供たちを競争に追いやったり、格付けしたり、「グローバル人材」に育て上げたりすることが今われわれがなすべきことではありません。世界はほんとうに激動しているんです。新しい指導的なアイディアを世界中の人が求めている。
激動しているからこそ、すぐに使える技を身につけるのではなくて、もっと根本的なものを大事にしていく必要があるという話ですね。
「大学でも社会で即戦力になる人材を育成するべきだ」という主旨の議論を目にすることがありますが、そういう時に思うのが、大学は4年あるということ。大学1年生に対して社会の即戦力としての教育をするとなると、4年後に役に立つことを教えなければなりません。4年先に社会で何が必要とされているのかを見越した教育が必要になります。小中学校での教育を考えると、見通さなければならない未来はもっと先のものになります。
ビジネスマンがビジネスマンに向けてビジネスセミナーで語るのであれば、今この瞬間に役立つことを話すことに意味があるでしょう。しかし学校教育では、今この瞬間に「役に立つだろう」と考えていることが、子どもが社会に出たときに本当に役に立つという保証はありません。逆も然りで、役に立たないと思われていたことが、役に立つようになっているかも知れません。
それだけの時間が経つと、今までなかった新しい職種が生まれることもあります。Web業界はその典型でしょう。私が小中学生の頃には、「マークアップエンジニア」という職種は、名前はもちろん、HTMLというもの自体が存在していませんでした。
※SGMLはありましたが (ISO規格化されたのが1986年)、SGMLを書く人とは性質がだいぶ違うはずなので。
逆に、当時は隆盛を極めていたのに、今は廃れてしまったものもあるでしょう。変化は避けられないので、変化するということを前提に考える必要があります。
このような考え方は、ウェブアクセシビリティの世界にもあります。WCAG2.0では、ウェブコンテンツ技術が変化するということを前提にして、HTMLという特定の技術に依存しない形でガイドラインを規定するようになりました。同時に、4つの原則のひとつに "robust" というキーワードを挙げています。
Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
以上、Web Content Accessibility Guidelines (WCAG) 2.0 W3C Recommendation 11 December 2008 より
現在のものだけでなく、将来のものも含めた、あらゆるブラウザや支援技術からアクセスできるように考える必要があるということです。小手先のギミックでアクセシビリティを担保しようとするのはよろしくない、というのはこのあたりの話ともかかわります。
"robust" は、そのまんま「ロバスト性」と訳されたりしますし、JISでは「頑健性」という訳語が採用されています。アクセシビリティもそうですが、人に関しても、「robustな人材」を育成することが必要なのではないかと思います。
安全なWebアプリを作りたければ新しいフレームワークがオススメ
公開: 2011年12月10日21時20分頃
こんな記事が……なぜPHPアプリにセキュリティホールが多いのか? 第44回 セキュリティ対策が確実に実施されない2つの理由 (gihyo.jp)
例えば，Railsの入力のセキュリティ対策はセキュアであるとは言えません。Railsのバリデーションは「データベースにデータが保存される前」に行われます。データベースにデータを保存する必要がないようなアプリケーションの場合，入力のバリデーションをフレームワークとして行う仕組みになっていません。本来入力はデータベース利用の有無に関わらず入力を受け入れた直後に行うべきです。多くのフレームワークがRailsの影響を受け同様の仕様となっています。Railsが脆弱な仕様を採用したことは不幸なことだったと思います。
……。
まず、バリデーションはセキュリティのためにする処理ではありません。たまたまセキュリティの役に立つこともありますが、役に立たないこともあります。たとえば、問い合わせフォームに本文の入力欄があり、任意のテキストが入力できて、DBにはText型 (任意の長さの任意のテキスト) として保存するとましょう。この場合、空欄だとエラー、という程度のバリデーションしか行われないはずです。長すぎるデータを蹴る場合もありえるでしょうが、いずれにしてもセキュリティの役に立つ処理ではありません。
どんなバリデーションが行われるのかは、単に仕様によります。任意のテキストを許す必要があるなら、' (単引用符) だろうとでも < (小なり) だろうと入力させなければなりませんし、エラーにしてはいけません。セキュリティの観点から勝手なバリデーションをすると、そういった文字が入力できない残念なシステムになってしまいます。
逆の言い方をすると、バリデーションを行っても、それはインジェクション系の脆弱性への対応とはならないということです。数値のみを入力させる場合などは対策にもなり得るのですが、それはたまたまですので、バリデーションとは別途に考えなくてはなりません。題名の「セキュリティ対策が確実に実施されない理由」という観点で言うなら、バリデーションをセキュリティ施策の一環だと誤解している人がいる、ということが理由のひとつではあるでしょう。
それはさておき、なぜかRailsが叩かれているので、Railsの話を少し。
RailsにはActiveRecordというものがあります。これはDBのカラム名や型を見て、自動的にモデルクラスを作ってくれるというものです。逆に言うと、DBに保存しないデータはActiveRecordでは扱えません。
ActiveRecordのバリデーションの仕組みは優れているので、DBに保存しないデータも同じようにバリデーションしたい、というニーズはあります。ただし、これはセキュリティとはあまり関係なく、単に同じように扱いたいという動機であることがほとんどでしょう。古いRailsではこれが大変で、いろいろ頑張ってActiveRecord::Baseを拡張したクラスを独自に作ったり、かなり面倒なことをしていました。
そして、おそらくそう思った人が多かったからでしょう、Rails3ではActiveModelというクラスが追加されて、お望みのことが簡単にできるようになりました。古いRailsもべつに脆弱というわけではないと思いますが、DB由来でないデータもバリデーションしたい場合はRails3をオススメします。
※もし「バリデーションのタイミングが気に入らない、入力直後に常にやるべき」という話であれば、before_filterでvalid? メソッドを呼ぶようにでもすれば良いのではないでしょうか。特に意味はないと思いますが、やりたければ。
Viewヘルパーを利用すれば安全，と考えるのは危険です。Railsアプリケーションのソースコード検査も仕事でしていますが，Railsで開発している方でもViewヘルパーがすべてのパラメータをエスケープ処理してくれないことを知りません。これはRailsだけの問題でなくすべてのWebアプリケーションフレームワーク共通の問題だと思ってください。
「Viewヘルパーがすべてのパラメータをエスケープ処理してくれない」というのは、何を言われているのか良く分かりませんでした。Viewの中で変数を出力する際にHTMLタグなどがエスケープされない、という話をされているのでしょうか?
昔のRailsでは、Viewに <%= var %> のように書くと、値はそのまま出力されていました。エスケープしたい場合は <%=h var %> のように書く必要があります。つまり、ヘルパーメソッド h() を呼ぶ必要があります。
逆に言うと、h() さえ呼べば、ほとんどの場合は問題ありません。問題が起きるのは、属性値に引用符を付けていないとか、単引用符で括ろうとしているとか、JavaScriptのコードを出力しているとか、javascript:で始まるURLが入力できるとか、そういった限定的な状況だけです。通常は単に h() を呼べば良いだけです。ただ、h() を書き忘れることはあるので、そういう意味では注意が必要ではあるでしょう。
……というのは古いRailsの話で、Rails3では h() を呼ばなくてもデフォルトでエスケープされるようになりました。エスケープせずに出力したい場合は、明示的に <%=raw var %> と書く必要があります。というわけで、Rails3の方がXSSを避けやすくなっています。
Rails以外で言うと、ASP.NET4では <%: var %> のように書くとデフォルトでエスケープされます。以前、安全なテンプレートシステムはあるのかという話で「2種類のデータがどちらも同じ string 型なのがややこしさの元」と書きましたが、.NET4にはHtmlStringという型があって区別できるようになっています。エスケープなしで出力する場合は、HtmlString型の値を渡すとそのまま出力されます。
ASP.NET MVC3で使われるRazorも同様で、デフォルトではエスケープされ、HtmlString型を渡すとそのまま出力されます (HtmlStringのコンストラクタを呼ぶかわりに、「@Html.Raw(foo)」と書くこともできます)。
そんなわけで、新しめのフレームワークでは、Viewでの変数出力はエスケープされるのがデフォルトになってきています。結論としては、安全なWebアプリケーションを作りたければ、新しめのフレームワークを使うのがオススメ、ということで。
※ただ、PHPのフレームワークがどうなっているのかは良く知らないのですが。PHPに詳しい大垣さんが「すべてのWebアプリケーションフレームワーク共通の問題」と言われているということは、PHPのフレームワークはまだ駄目なのでしょうか……?
関連する話題: Web / セキュリティ / クロスサイトスクリプティング脆弱性
傍聞き
公開: 2011年12月10日1時0分頃
読み終わったので。
傍聞き (www.amazon.co.jp)
これは面白かったです。4つの短編からなるのですが、どれも見事です。ミスリードもうまいですし、伏線の張り方、回収の仕方も素晴らしく、全てが一気に収束してぱっとパズルが完成するようなカタルシスが得られます。
表題作「傍聞き」も良かったですが、いちばん印象に残ったのは、最初の「迷走」。救急車に乗務する救急救命士の話なのですが、娘の仇と思われる人物を救急車に乗せ、病院に着く直前で何故か方向転換――という話。その理由が明らかになったところでちょっと泣きそうになってしまいました。読み直してみると、意味不明と思えた言動も実は最初から一貫した行動になっていて、ミスリードの巧みさに驚かされます。
短くて軽く読めますし、かなりオススメできる作品です。
- 前(古い): 2011年11月29日(火曜日)のえび日記