[&] Web Directions East 2009 (Douglas Crockford)

Douglas Crockford | Web Directions East

Web Directions East 2009

Ajax Security - Douglas Crockford

Douglas Crockford - Ajax Security

View more presentations from webdirections.

Ajax Security - Douglas Crockford
--------------------------------------
http://crockford.com/codecamp/ajaxsecurity.ppt

有名なセキュリティの話題。

The SAMY Saga (MySpace 2005)
JavaScript と CSSを隠した。
その結果 勝手に Friends リストに付け加えられていた。
アカウントの数が倍増していった。
名乗り出た。
その結果重罪となった。
SAMYさんは悪い人ではなかった。
サーバーからは、悪さをしていることがわからない。
制御を与えてしまう。
トランザクションの中で、ユーザーのリクエストなのか、機械からのリクエストなのかわからない。

ブラウザは上記のようなことを避けることができない。
web スタンダードは、これを避ける方法には動いていない。
これは新しいことではない
cross site scripting は 1995 年からの、基本的は問題。
セキュリティの問題、ブラウザで対応できているわけではない。
Web として必要十分というレベルにいつの日か到達することがあるのだろうか？

何か脆弱性があった場合、新しいバージョンで直していくことができる。
時間がたつにしたがって、解決していく。
ブラウザにあたらしい機能が付け加えられると、
それだけ脆弱性が付け加えられているということでもある。

新しい機能の問題。
意図した結果にならない場合がある。HTML５もそう。
前提としてブラウザのセキュリティモデルにまだ問題がある。
徐々に修正していっても、最終的に十分ということにならない。
むしろ、有害な原因をたくさんためてしまっている。
開発者としては、完全なセキュリティの知識を持たなければいけない。
現在のセキュリティのすべての理解を求めるのは無理。

Web はこのままダメになってしまうのでしょうか？
Flash も Silverlight は、オープンではない。
Web は正しい方向にどこよりも近づいていると考えている。

どこに問題があるのか？
　標準に間違いがあった。
　"We will add security in 2.0”
　バージョン 2.0 でセキュリティ機能を追加するというのは間違い。
　そういう態度が間違い。
　セキュリティこそが一番最初から考慮しておくべき。
　後付けはできない。
　後から欠点をのぞくのは難しい。
　
暗号技術やセキュリティに誤解がある。
暗号化すれば、セキュリティが向上するわけではない。
DLNA の場合、パソコンにウィルスが入った場合、家電にまで影響を及ぼすこと。
もし予防できないのであれば、自分たちでやるしかない。
暗号化技術を使って、解決するというアプローチ。本来的には正しくない。

アイデンディテイ。
　誰がソフトウェアを書いたのか、信頼できるのか？
　システムが危険なことが起きそうだと予期しているか？
　ユーザーに認証を求めても、ユーザーは理解できない。
　質問の目的もわからず、理解できない。
　
いろいろなプログラム、早く処理しなければいけない時、
二つの検疫を入れていかなければいけない。
OS側、ユーザー側
タイムシェアリングや時分割、何人もの人が同じシステムを使う。
お互いのプロセスをわけ、リソースは共有。
いい方法だが、問題としてはユーザ同士のコラボレーションができない。
メインフレームの時代が終わってパーソナルコンピュータの時代がきた。

プログラムは意図的にインストールされているもの。
使い方、動き方が変化していくもの。
Web 経由でもさまざまなものがインストールされている。
ユーザ側の検疫と、プログラム側の検疫をわけている。
ブラウザ側も混乱する。複数のサイトがあった場合。
ページの中広告や、Widget や Ajax ライブラリなどが、サイトと同じ権限をもってしまう。

Turducken 　ターキーと、ダックと、チキンがレイヤー化されていて、
何を食べているかわからない。

Web 2.0 の問題ではなく 1995 年からずっとあった問題。
根本的な問題は解決しておらず、マッシュアップが増えれば増えるほど問題になっていく。
mashup は XSSアタックになりうる。
広告があるページにあるだけで、あまり良くないこと。
JavaScript としてはセキュアな言語として使える。
新しいモデル。

Object Capabilities
http://erights.org/talk/

相互の監視によって、お互いに被害を与えないようにして情報をやりとりする。
A から B にインタフェースを提供し、インタフェースの部分でデータを送る。
リファレンスの仕方に制限を与えることによって安全なモデルができる。

By Creation.
By Construction.
By Introduction.

最終的には情報を隠すことを考えたり。
リファレンスは無かったことにはできな。ファセットを使う。

Facets

Very expressive.
Easy to construct.
Lightweight.
Power Reduction.
Revocation.
Notification.
Delegation.
The best OO patterns are also capability patterns

セキュアな用件がそろっている。
ケイパビリティが良いのが理想。
Ajax ライブラリでやっているようなこと。

W3C は逆の方向に向かっている。
HTML5 はセキュリティの問題がカバーできていない。

広告の問題。
ECMAScript の部分。Caja ライクなセキュリティ。

Q. Caja とは？
A. Google Caja, JavaScript を安全な JavaScript に書き換えるもの。
　コードをチェックし保証するもの。問題を発生するものではない。
　Yahoo! でも使っている。どんどん Caja を使うシステムが増えてくるであろう。
http://code.google.com/p/google-caja/

Q. スクリプトに署名するのでは？
A. 署名があっても機能しない。アイデンディテイの混乱を招き、
　不要の権限を与えてしまう。ユーザーに許可を聞いても意味はない。
　攻撃者にたいして攻防策にならない。
　ケイパビリティーこそが鍵になる。

Q. HTML5 は大きくなりすぎている
　　別の解決方法はあるか？
A. いろいろやっている、web sand box (Microsoft)など
　Y! はモデルに関して、かなりの経験がある。
　次のバージョンに何が必要なのかわかっている。
　初期の FORM の形にもどって、もういちど洗い出しが必要。
　考え方を変えるしかない。
　これをやることによって、Web開発者にとってはもっと安心・安全できる環境になる。
　ECMA スクリプトの方でやっている。MS,Google らと協力して作業している。
　ミーティングが始まった。
　どういうのが一番いいのかという知識を広める。実際に形にしていこうという作業。

A. JavaScript で Dojo, jQuery などライブラリがある。
　　それらのフレームワークは安全だと考えている？
Q. フレームワーク自体は現在安全では無いです。
　　Dojo はかなり安全だと考えています。
　　Dojo をそのまま使ってしまうと安全なシステムとは言えない。

Q. ECMAScript 5 でかなり難しい問題解決する。
A. Caja はゲストオブジェクトがグローバルオブジェクトにアクセスできない仕組み。
　　JavaScript ではいろいろな方法でグローバルオブジェクトにアクセスできてしまう。
　　ECMA5 でより良くなっていく。パフォーマンスの部分も良くなっていく。
　　まだ DOM でラッピングしなければいけず、パフォーマンスの問題も含む。

Q. Google オープンソーシャルは？
A. OpenSocial は Caja を使っている、非常にいい方向だと思う。