2006-02-09 [長年日記]
_ 脆弱性と攻撃と対策
閲覧者の安全はほどほどに守れば十分だの方にもちょっと反応しておこう。
ブラウザの脆弱性を突いて行われる攻撃については、「その通り」と回答します。
一方、ブラウザが仕様通りの動作を行っても、サービスの設計のまずさゆえに可能となってしまう攻撃に関しては、（私の価値観においても）なるほど許容範囲外だと思いました。
念のために書いておくと、あの部分の文章はあくまでも「XSSの攻撃は、はまちやさんの仕掛けるようなすぐに攻撃の存在が発覚するそれほど実害が大きくないものなんだから、攻撃者はすぐ特定できるし、見つけたら攻撃者を排除するだけで十分なのに、なんではてなはあんなに一生懸命XSS対策をしているの？ 不要でしょ？ っつーか俺たちにJavaScriptを使わせろや！」という徳保さんのもともとの主張（だと私が読み取ったもの）全体に対して、それは徳保さんが根本的にXSSというものを理解していなかったから、そう思ったんじゃないの？と問いかけているのであって、「対策は十分だと思うか、思わないか」の答えを直接的に聞いているわけではないので。いや別に答えてもいいけど。
ここからはかなり余談。
対策するべきかどうかを考えるときに、原因となる脆弱性が「ブラウザの実装にある」のか「サービスの実装にある」のか、という二つのみを並列させて論じることには、あまり意味がない*1。攻撃は、ブラウザもしくはサーバーの何らかの脆弱性を利用するものが多いが、ブラウザもしくはサーバーの脆弱性（ここでは特にプログラムレベルでの不具合）を利用しない攻撃もある。
まず、基本的にフリーテキストを解釈して処理を行うブラウザにおいては、実装側の自由度はかなり高く、それが脆弱性なのかブラウザの仕様なのか、明確には区別できないので、何らかの怪しげな挙動があったとしても、それが脆弱性であると言い切れない*2。あまり一般的ではないけど、実はこういうこともできるんだよ、というだけの話かもしれない*3。
特にJavaScriptに関して言えば、もともとがただのプログラミング言語なわけだから、そこで実現できることの自由度は非常に大きい。単に「攻撃」というだけならば仕様の範囲内でも非常に多様なことが可能だ。いわゆるJavaScriptによるブラクラなんて少しも脆弱性とは関係ない。信頼できないActiveXコントロールをインストールしたらキーロガーが常駐した、などというのも脆弱性とは関係なく、ブラウザの仕様通りの挙動だ。
また、ブラウザの脆弱性が発見された場合、もちろんその脆弱性を修正できるのはブラウザ制作者であって、サービス提供者がブラウザを修正するなんてことはできない。できるのは、その脆弱性を利用したなんらかの攻撃に対して、対策を取ることだけだ。
そして、ブラウザの脆弱性を利用した攻撃のすべてに、サービス提供者側で対策できるものではない。脆弱性の内容によっては、サービス提供者側では対応できないものもあるだろう。たとえばCSSXSSに関しては、それを利用したいくつかの攻撃に対策することは不可能ではないが、それはあくまでも場当たり的な対処であり、本質的な対策*4は不可能であると考えているので、サービス側での対応はされなくても仕方がないと考える*5。
逆に、ブラウザの脆弱性を利用した攻撃だとしても、それへの対策はサービス側でも容易に実現でき、しかもその脅威が十分に高いのならば、サービス側はブラウザ側の対策を待たずに対応した方がいいだろう。
サービスの実装に原因がある脆弱性を利用した攻撃は、対策しなくていい理由は思いつかないなー。まあ脅威の度合いが低ければ、すぐに対策する必要はないだろうけど、必ずいつかは対策するべきだよね。
|
要するに ある攻撃の 大元の原因が ブラウザにあるか サービスにあるか よりも その攻撃の 危険性 緊急性 その攻撃への対策が 可能かどうか の方が 重要 ってこと |
このセクションに対するはてなブックマーク
_ プラグイン追加
|
tDiaryに category_to_tagと bigpresenを 追加した でも 白文字 テーマだと 文字が 読めないんで bigpresen.rbの 71行目の styleに color:blackを 追加した |
今日のメモ powered by 1470.net
-
#
2006/02/09 00:00
ishinao
livedoor knowledge - 質問と回答 コミュニティ,livedoor knowledgeのような、人に尋ねるタイプのサイトって他にもあるのでしょうか?-
URL
livedoor knowledgeのような、人に尋ねるタ - livedoor ナレッジ 知識、知恵のカタマリ
→6 links
http://knowledge.livedoor.com/180
おもしろ。
-
URL
livedoor knowledgeのような、人に尋ねるタ - livedoor ナレッジ 知識、知恵のカタマリ
→6 links
-
#
2006/02/09 00:00
ishinao
Picment.com Articles CSS Fun with forms – customized input elements-
URL
Picment.com � Articles � CSS � Fun with forms customized input elements
→2 links
http://www.picment.com/articles/css/funwithforms/
こういうことを汎用的にやるパターンを一個作っておくと便利そうだな。
-
URL
Picment.com � Articles � CSS � Fun with forms customized input elements
→2 links
*1 考慮するべき要素は、その2択では代表されない
*2 CSSXSSのようなものは、過去のWebセキュリティに対する各所の取り組みの経緯から考えて、本来そのようなことがあってはならない挙動だから、IEのセキュリティに関する不具合の一つだと言い切ることができるけど
*3 腐ったHTMLを適当に読み替えてくれたり、サーバーは画像データだと言っているのにHTMLとしてレンダリングしようとしたり
*4 CSSXSSに本質的に対策しようと考えるならば、GETアクセス可能なセキュリティで保護された領域に、セキュリティで保護されていることを前提とした情報を出力してはならない、となってしまう
*5 もちろんはてなのXSS対策自体も場当たり的と言えば言えるが、はてなのXSS対策はある程度収束した状況においての「場当たり的」であり、まったく収束していない状況に置ける「場当たり的」とは意味が異なる
pluginがRSSだとまったく読めないのでRSSには出力しないほうがいいのかも。
RSS内には必要な要素はすべて含まれているんで、そのまま表示したら動くはずなんですが、多分RSSリーダー側でJavaScriptが動かないようにしているんでしょうね。どうせ動かなくするなら、<noscript>の中身を表示してくれればいいのになー。
まあその部分が読めない以外の害ってないですよね？
そうみたいですね。RSSリーダがbloglinesなので。bloglinesで読んでいると、何も読めない《CLICK TO START》だけ何回も上がってきて、高橋メソッドpluginだけのエントリだとなにがなにやらって状態になってしまうのです。
本当だ。なんか更新していないbigpresenを含むエントリーが、Bloglinesではなんどもあがって来ちゃってますね。
というのも、Bloglines側の仕様（dc:date以外を見て勝手に更新されていると判断してあげている）っぽい気がするんですが、Bloglinesユーザーのわたし的にもこの挙動はうざいんで、回避方法がないかどうか考えてみます。
どうやら使っていたバージョンのbigpresenではランダムでIDを振っていた部分があり、そこが毎回変わるため、Bloglinesで更新されたと認識されていたみたいです。
新版では内容ごとの固定IDに変わったみたいなんで、これでBloglinesで更新されていないのにあがってくることはないと思います。
対応ありがとうございました。また、中身も読めるようになったので「なにがなにやら」状態も回避できるようになりました。素晴らしい!!