Hatena::ブログ(Diary)

ockeghem(徳丸浩)の日記 このページをアンテナに追加 RSSフィード

[PR]WAFの導入はHASHコンサルティング
 |  

2007-10-17 「いろいろ変わったXSSがありますが」を読んで

E4X連想配列プロパティ、Object.evalメソッド 12:05  E4X、連想配列とプロパティ、Object.evalメソッドを含むブックマーク

大垣さんのブログから

確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。

<script>

123[''+<_>ev</_>+<_>al</_>](''+<_>aler</_>+<_>t</_>+<_>(1)</_>);

</script>

yohgaki's blog - いろいろ変わったXSSがありますが...

このスクリプトの中には、興味深い要素がたくさん含まれていますが、説明もなく放り出されているので理解が難しいでしょうね。

E4Xについて

まず目につくのは、JavaScript(ECMAScript)のスクリプト中にXML形式でオブジェクトリテラルを記述できるE4X(ECMAScript for XML)という機能です(FireFox1.5以降で対応)。これは、例えば以下のように使います。

var order = <order> 
  <name>Webアプリケーションのセキュリティ完全対策</name> 
  <author>徳丸浩他</author>
  <price>3990</price>
  <ISBN>4822229718</ISBN>
</order>

これは、JavaScriptオブジェクト記法で記述すると以下のようになります。

var order = { 
  name : "Webアプリケーションのセキュリティ完全対策",
  author : "徳丸浩他",
  price : 3990,
  ISBN : "4822229718"
}

こっちの方が分かりやすいでよね。これでいいじゃん。

このように、JavaScriptスクリプト内にオブジェクトリテラルを記述するのであれば、JavaScriptに元々用意されている記法(これがJSONですが)で十分で、XMLを持ち出す必要はないと思います。

では、どういう場合にXML記法を使いたいかというと、Ajaxがすぐに思いつくわけですが、Ajaxで使うだけであればライブラリを用意しておけば済む話で、わざわざ言語のコアに組み込む必要はない。ということで、E4Xが本当に役に立つのは、JSONPJSONのデータを読み込むように、<SCRIPT>で直接XMLを読むことではないかと思います。

連想配列プロパティの関係

E4Xが理解できたとして、大垣さんの提示されたスクリプトを単純化すると以下のようになります。

123["eval"]("alert(1)");

この中の「123["eval"]」という部分は、数値123をオブジェクトとして使った連想配列になります。JavaScriptの場合、連想配列オブジェクトプロパティは等価ですから、上記以下のように書き直すことが出来ます(オブジェクト指向プログラム言語としてのJavaScript参照)。

123.eval("alert(1)");

これはすなわち、数値に対するevalメソッドを呼び出していることになります。数値にevalメソッドなんかあったっけ?

Object.eval メソッド

eval関数というものがあります。eval関数は文字列を引数としてとり、その文字列をJavaScriptとして実行するものです。

eval("alert('Hello')");  // Helloというダイアログが表示される

これに似たものに Object.eval メソッドがあります。ECMAScriptでは採用されていませんが、後方互換性のために残されています。Object.evalメソッドは、eval関数と似ていますが、スコープが異なります。

var a = 1;
var obj = new Object;
obj.a = 2;
obj.eval("alert(a)");	// obj.a すなわち 2 が表示される
eval("alert(a)");	// a すなわち 1 が表示される

上記の違いはともかく、「123.eval("alert(1)")」は、Objectクラスのevalが呼ばれ、「alert(1)」が実行されます。

大垣さんは何が言いたかったのか

大垣さんはのプログには以下のような記述がありますが・・

好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。

今まで説明した中でWeb開発者が知っておくべきだと思うのは、連想配列プロパティの関係くらいで、それ以外は、Firefoxでのみ使える機能(E4X)であったり、後方互換性のためにのみ残されている機能(Object.eval)なので、知っておかなくていいじゃんと思ってしまうのですね。

XSSとの関連でいえば、「'」や「"」を使わないXSSを技術できることは攻撃者にとって魅力的ですが、「'」や「"」はエスケープされるが、「<」がエスケープされていないという状況は考えにくいのです。大垣さんの書かれているのは、攻撃というよりは難読化ですね。

むしろ、奥一穂さんがKazuho@Cybozu Labs: E4X-XSS 脆弱性についてで書かれているように、<SCRIPT>で読み込まれるパターンの方が現実的な危険性を感じます。

いずれにせよ、E4Xのもたらすリスクについてはまだ議論が始まったばかりであり、Web開発者が知らなければならないのは、その議論の成果が出た後の話だと私は思います。

トラックバック - http://d.hatena.ne.jp/ockeghem/20071017

2007-10-10 サニタイズ恐るべし

でも本当にすごいのはGoogle AdSense 12:06  でも本当にすごいのはGoogle AdSenseを含むブックマーク

そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05)を表示したところ、以下のようになりました。

f:id:ockeghem:20071010120020p:image:left

入力値検証の話題から、細菌対策の広告を出すとは・・・

[セキュリティ]MS07-057によりPNG画像のXSS問題は回避されたようです 18:51  [セキュリティ]MS07-057によりPNG画像のXSS問題は回避されたようですを含むブックマーク

はせがわさん id:hasegawayosuke 経由

詳しくは、no title(追記)を参照ください。

なかむらなかむら 2007/10/11 22:35 細菌対策はやはり入力時の検証が必要ですよね?

トラックバック - http://d.hatena.ne.jp/ockeghem/20071010

2007-09-11 [ネタ][セキュリティ]メタ文字たちが騒いでいます

危険文字と言わないで 12:57  危険文字と言わないでを含むブックマーク

昨日、とあるベンダーセキュリティセミナーに行きました。

そしたら、どうです。僕らのことを「危険文字」と呼んでる人がいるじゃありませんか。

ひどすぎます。僕らは日夜、世界中で、HTMLのページを書いたり、データベースを検索したりで、Webを支えているんです。僕らが無かったら、Yahoo!だって、Amazonだって、Googleだって、tokumaru.orgだって実現できないんですよ。うそだと思ったら、「<」も「>」も「'」も「"」もなしに、Webアプリを書いてごらんなさい。

こんなことを言ったら、UTF-7なら、7bitアスキーなら「危険文字」使わないで書けるとか言う人がいるかもしれない。でも考えてみてください。UTF-7とか7bitアスキーの方こそ、よっぽど「危険」じゃないですか。それに、UTF-7は見た目が変なだけで(UTF-7怒るかな?)、結局は僕らのことを表現しているんです。当たり前じゃないですか。

だから今後は、危険文字どころか、「有用文字」と呼んでもらいたいですね。

今度僕らのことを「危険文字」なんて言ったら、その人には僕たちもう使わせてあげない。

わかりましたか?

プンプンプン

追記

 今メモ見返したら「有害文字の排除」と書いてあったよ。たしか別の講師だ。

 この業界、感謝の気持ちってモノがないのか。

 メラメラと怒りが戻ってきたよ。

 「危険」、「有害」だけでは気が済まずに「排除」ときたもんだ。そんなに排除したけりゃ、排除してみろ。後で頭下げても、使わせてやんないよ。

2007-09-03 出現予告

SKUF勉強会で講師を担当することになりました 20:11  SKUF勉強会で講師を担当することになりましたを含むブックマーク

第5回SKUF Meeting - ikepyonのお気楽な日々〜技術ネタ風味〜経由

私も講師を担当することになりましたのでよろしくお願いします。テーマは、ケータイ向けWebアプリセキュリティ問題についてです。もう一人の講師の佐名木さんは顔見知りですが、もう何年ぶりかですね。懐かしい。

今回は、ケータイセッション管理あたりを中心に話そうかと思っていますが、まだ流動的ですので、リクエストがあれば、この日記へのコメント、メール()、Twitter(http://twitter.com/ockeghem) (^O^) などでお寄せください。ただし、リクエストに応じられるとは限りません(能力、守秘義務などで)ので予めご承知置きください(_ _) ケータイの話というのは告知済みですので、JavaScriptとかは駄目だと思います:-)

日付:2007年9月29日(土)

時間:13時30分〜16時45分(受付開始:13時00分〜)

場所:新橋区民会館

no title

トラックバック - http://d.hatena.ne.jp/ockeghem/20070903

2007-08-27 早さ自慢

サニタイズ言うな」の先駆け? 23:41 「サニタイズ言うな」の先駆け?を含むブックマーク

昔の投稿記事などを整理していたら、2001年に日経オープンシステム誌(この雑誌も今はないが)に投稿したWebアプリケーションセキュリティの寄稿が目に止まった。古い記事なので、「今だったらこうは書かないよなぁ」という部分もあるし、「ずいぶんと気負いこんで書いているな」という部分もあったが、その中に「サニタイズ言うな」と関連する内容が合ったので、引用として許される範囲で紹介したい。

「危険な文字の除去」は簡単だが推奨できない

 このクラッキングの回避策としてまず思い付くのは,「危険な文字を削除する」というアプローチである。SQLの場合に「危険な文字」となるのは前述のシングル・クオートであるから,この文字さえ削除してしまえば,SQL改ざんクラッキングは不可能になる。任意の文字列からシングル・クオートを取り除くプログラムの例を図3に示した。

 一般にこの種のテクニックはインターネットでは広く利用されているが,筆者はこの種の方法は望ましくないと考えている。その理由は後述するとして,ではなぜ「危険な文字を除去する」という方法が広く行われているのであろうか。筆者は,Webアプリケーションが広まり始めたころにPerl言語によるCGI(CommonGatewayInterface)が主流だったからではないかと考えている。Perl言語を使えば,特定文字列の除去などは1行で書けるような,最も簡単な処理の一つである。図3にはシングル・クオート除去のPerl版も示したが,サブルーチンにするまでもないほど極めて簡単に記述できる。この手軽さゆえに,「危険な文字・文字列は除去してしまう」というやり方が広まったのではないだろうか。

 筆者が「危険な文字を除去」するアプローチが良くないと考える第1の理由は,まずユーザーの入力を勝手に改変して処理を継続している点である。無料掲示板なら文句も出ないかもしれないがビジネス・アプリケーションECサイトにおいて,いくらセキュリティ上の危険があるからといって,ユーザーが入力した内容を勝手に改変してよい理由はない。したがって,不適切な文字が入力に混入していたら,処理を継続するのではなくエラーを表示して再入力を促すべきである。

 第2の理由は,シングル・クオートを除去するにせよ,エラーにするにせよ,その根拠が「処理上都合が悪いから」というプログラマの論理に基づいている点である。本来,入力として適切な文字かどうかは,ビジネス・ルールから決まるものであって,プログラマの都合で勝手に変えてよいものではない。

[日経オープンシステム2001年8月号P181から]

高木氏の「サニタイズ言うなキャンペーン」とは何か (takagi-hiromitsu.jp)が2005年末の投稿ですから、早いことは早いですわなww

さらに、Perl CGIに対する言及もしっかりあったりして(^^; ただ、Perl言語が悪いと言っているわけではないことは、先入観に(どんな先入観だ)にとらわれずにお読みいただければ分かっていただけるかと。

追記(2007/08/29)

サニタイズ言うな」宗家の高木浩光氏からはてなブックマークコメントを頂戴しました。

no title

内容自体は昔からですよ。http://tinyurl.com/2cmhxp にせよ http://tinyurl.com/2dzmtq にせよ。それが、その後サニタイズという用語の広まりによって悪い方の発想が急速に広がっていったため、キャンペーンで食い止める必要が生じた

お忙しい中、丁寧なコメントを頂戴しありがとうございます(_ _)

「その後サニタイズという用語の広まりによって悪い方の発想が急速に広がっていった」ということですが、2001年の段階で「サニタイズ」という言葉はそれほど普及していなかったものの、サニタイズ的手法自体は、むしろセキュリティ対策の主流だったように記憶しています。私はそのような状況にイライラしていて、その気持ちが、「一般にこの種のテクニックはインターネットでは広く利用されているが,筆者はこの種の方法は望ましくないと考えている」だとか、「いくらセキュリティ上の危険があるからといって,ユーザーが入力した内容を勝手に改変してよい理由はない」、「プログラマの都合で勝手に変えてよいものではない」などの表現に現れています。

 私は露骨な表現を好まないために、上記のような控えめな表現(当時はこれでもかなりドキドキしながら書いたのですが)になったのですが、全然影響力はなかったですね。高木さんが大きな影響力を発揮された理由には「サニタイズ言うな」という卓抜な(日本語としてはこなれないためにかえって印象に残る)ネーミングと、ずばりとした表現もあるのでしょう。

このテーマについてはもう少し書きたいことがありますが、まずはお礼まで。ありがとうございました。

トラックバック - http://d.hatena.ne.jp/ockeghem/20070827
 |  
Google