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な人材」を育成することが必要なのではないかと思います。

「robustな人材」にコメントを書く

関連する話題: Web / アクセシビリティ

安全な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つの短編からなるのですが、どれも見事です。ミスリードもうまいですし、伏線の張り方、回収の仕方も素晴らしく、全てが一気に収束してぱっとパズルが完成するようなカタルシスが得られます。

表題作「傍聞き」も良かったですが、いちばん印象に残ったのは、最初の「迷走」。救急車に乗務する救急救命士の話なのですが、娘の仇と思われる人物を救急車に乗せ、病院に着く直前で何故か方向転換――という話。その理由が明らかになったところでちょっと泣きそうになってしまいました。読み直してみると、意味不明と思えた言動も実は最初から一貫した行動になっていて、ミスリードの巧みさに驚かされます。

短くて軽く読めますし、かなりオススメできる作品です。

「傍聞き」にコメントを書く