特定の誰かを示しているのではなく、諸処で色々あったので書きます。
XSSを放置するという事がどういう事なのか説明してみます。
まずは、以下のリンク先をご覧ください。
XSSを放置するという事がどういう事なのか説明してみます。
まずは、以下のリンク先をご覧ください。
どうですか?
ちょっと気持ち悪くないですか?
新聞社のサイトで確認すると、その人の思想もある程度確認できます。
特定のニュースを読んだ事も確認できます。
詳しく書くと悪用されるので詳細は書きませんが、やろうと思えば特定のサービスのidやハンドルネームも取得できます。
色々なサービスのidやハンドルネームを結びつけることもできます。
そしてそれらの情報を別の場所に送信することもできます。
これって、JavaScriptだけでできるんですよ。
XSSは使っていませんが、JavaScriptを使うとこんな事もできるんです。
JavaScriptでできる事はこれ以外にも沢山あります。
数ある実行例の一例を示したに過ぎません。
XSSと何が関係あるのかって?
XSSはhtmlにJavaScriptを埋め込む行為ですよね。
言いかえると、XSSの脆弱性のあるサイトは、『見にきた人のブラウザ上で、第三者が自由にJavaScriptを実行できる状態』にあるってことなんです。
その上、XSSはXSS以外の脆弱性を利用するために利用できます。
これがどれだけ危険な事かとご理解いただけますか?
ちょっと気持ち悪くないですか?
新聞社のサイトで確認すると、その人の思想もある程度確認できます。
特定のニュースを読んだ事も確認できます。
詳しく書くと悪用されるので詳細は書きませんが、やろうと思えば特定のサービスのidやハンドルネームも取得できます。
色々なサービスのidやハンドルネームを結びつけることもできます。
そしてそれらの情報を別の場所に送信することもできます。
これって、JavaScriptだけでできるんですよ。
XSSは使っていませんが、JavaScriptを使うとこんな事もできるんです。
JavaScriptでできる事はこれ以外にも沢山あります。
数ある実行例の一例を示したに過ぎません。
XSSと何が関係あるのかって?
XSSはhtmlにJavaScriptを埋め込む行為ですよね。
言いかえると、XSSの脆弱性のあるサイトは、『見にきた人のブラウザ上で、第三者が自由にJavaScriptを実行できる状態』にあるってことなんです。
その上、XSSはXSS以外の脆弱性を利用するために利用できます。
これがどれだけ危険な事かとご理解いただけますか?
ウェブサービスの場合
あなたを、あなたの作ったサービスを信用して訪問してくれた人全員をこのような危険にさらしているんです。
悪質なサイトに寄りつかなくても、あなたのサイトに訪問しただけでです。
それでもXSSを放置するのですか?
それって訪問者に裏切り行為だとは思いませんか?
悪質なサイトに寄りつかなくても、あなたのサイトに訪問しただけでです。
それでもXSSを放置するのですか?
それって訪問者に裏切り行為だとは思いませんか?
業務アプリケーションの場合
社内システムだから大丈夫?
この方法はLANかどうかなんて関係ありません。
アクセス制限をかけてるから大丈夫?
全部のサイトにですか?
非現実的ですね。
ログを取っているから大丈夫?
それって抑制力になるだけですよね。
ログがあれば犯人を特定できるから大丈夫?
実行された後の対処策にしかならないですよね。
この方法はLANかどうかなんて関係ありません。
アクセス制限をかけてるから大丈夫?
全部のサイトにですか?
非現実的ですね。
ログを取っているから大丈夫?
それって抑制力になるだけですよね。
ログがあれば犯人を特定できるから大丈夫?
実行された後の対処策にしかならないですよね。
どうすれば良いのか
簡単です。
今すぐ修正してください。
バグのないシステムを作るのは不可能ですが、バグを修正することはすぐにできます。
XSSが発生した経緯や周囲の状態等関係ありません。
今すぐ対処してください。
それが、そのサービスやシステムを使う人のためであり、あなたのためであるからです。
今すぐ修正してください。
バグのないシステムを作るのは不可能ですが、バグを修正することはすぐにできます。
XSSが発生した経緯や周囲の状態等関係ありません。
今すぐ対処してください。
それが、そのサービスやシステムを使う人のためであり、あなたのためであるからです。
最後に
個人的にはXSSは『JavaScriptインジェクション』と呼称した方がいいのではと思っています。
SQLインジェクション等、他のインジェクション系不具合と対処の考え方は同じだと思うので、こう呼んだ方が統合的な対応ができるんじゃないかと...。
SQLインジェクション等、他のインジェクション系不具合と対処の考え方は同じだと思うので、こう呼んだ方が統合的な対応ができるんじゃないかと...。
2008/10/26 追記
今読み返すと、あちこちに変な日本語が混じっていますね。
訂正するのも嫌らしいのでそのままにしておきます。
はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。
このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。
そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。
このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。
これを踏まえて以下記述します。
「#」ではじまるのがはてなブックマークのコメントです。
#2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？
#2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？
申し訳ないです。実行結果を見たときの気持ち悪さを優先したため、非常にわかりにくくなってしまいました。
調査結果は日本語で書くようにしています。
一覧等の無機質な情報を表示するのではなく、得られた情報から第三者がどのように推測するかを想定していました。
ガードが堅いというのは、何も情報が得られなかった時に表示されます。
#2008年10月24日 hasegawayosuke XSSでJavaScriptが動くのはその脆弱なサイト上なので、特定サービスのidやハンドルネーム云々は関係ないぢゃん。visited調査は攻撃者が自分でサイト用意しても一緒ぢゃん。…という反論にはどう対応する?
id/ハンドルネームを取得できてしまうサービスには、「脆弱性等、本来意図していない挙動によりid/ハンドルネームが取得されてしまう」場合と、「管理者サイドではid/ハンドルネームの取得を(本当の理由がどうであれ)仕様と見なしている」場合があると思います。
今回は後者を前提としており、脆弱性のない普通のシステム/サービスにおいても、id/ハンドルネームは取得できる場合を指していました。
後半で他の脆弱性を利用するためにXSSが使われると書きましたが、先にid/ハンドルネームの話を持ってきたのはこれが理由です。
visited調査に関してですが、危険なサイトを訪問しなくてもXSSのあるサイトでも起こりえるというのが重要なので充分に反論できると思います。
#2008年10月24日 hiroyukiegami 非常にいいまとめ
非常にいいまとめではありません。
XSSを理解している人からすると非常に歯痒いエントリーだと思います。
#2008年10月24日 showyou ちょっと気になるとこあったのでエントリ書きました。http://d.hatena.ne.jp/showyou/20081024#1224846631
#2008年10月25日 Kanatoko JavaScriptインジェクションとXSSは違うのでつよ
#2008年10月26日 kicchomu3 XSSはJavascript以外でもできるでしょ。
その通りですね。XSSはJavaScriptのみではありませんでした。
a要素・img要素・iframe要素のようなhtmlもありますし、CSSでも表示を変更する事ができます。
VBScriptもありました。
object要素を含めるとなんでもありますね。
「個人的にはXSSは『JavaScriptインジェクション』と呼称した方がいいのではと思っています。」は訂正します。
そもそも『JavaScriptインジェクション』という言葉は既にあったようです。
個人的には『インジェクション』という言葉を使った方が対策が進むのではないかと思っているので、こう書いてしまいました。
意図しないような反論をまた受ける可能性を恐れずに書くと、『クライアントコードインジェクション』はどうでしょうか。
#2008年10月24日 Kenta_K 検索はGoogleしか使わないのに、Yahooって言うニュースサイトで検索してるって言われたんだけど…？
これはcheck_visited.htmlの精度の問題です。
対象は、このblogを見に来られる人やはてなを使っている人がするようなリンクを使った画面遷移ではなく、「技術に疎い人」がブックマーク(お気に入り)で画面を表示する場合を想定しています。
あと、ニュースサイト限定ではなく、『全般』の話です。
ここでは詳細を避けます。
詳しく知りたい方はコードを読んで頂くか直接ご連絡下さい。
#2008年10月24日 sippu おお怖い。こういう手法もあるのか。ってかこれってよく使う方法も良くあるよね？（お勧め表示とか）
よくあります。
ただ、道徳的に問題はないのかという話もあります。
まだこの方法の評価が固まっていないのでどうなるかはわかりませんが、道徳的に問題があるという認識になるのではないかと思っています。
#2008年10月25日 into_the_blue 悪質なサイトじゃなくても、実はやっていること。わざわざ脆弱なサイト見つけてまでこれをやるより、どーせならCookie盗んで（ｒｙとかキーロガーしかけて（ｒｙのほうがいいな（自分が攻撃者だったとしたら）
そうですね。Cookieやキーロガーの方が対効果比が非常に高いと思います。
ただ、それらを見せられるよりも今回の方法の方が『一般的な人は気持ち悪いと感じる』と考えてこのようにしています。
それに、Cookieを盗んだりをここですると私が訴えられる可能性もゼロではなくなるのでご了承下さい。
#2008年10月25日 m-_-m 勤勉なNoScriptのお陰で「訪問先確認」が真っ白ﾜﾛﾀ
NoScriptを入れられるとJavaScriptでは手も足もでません。
#2008年10月25日 fuktommy "あなたの作ったサービスを信用して訪問してくれた人"←もちろんkanasansoft.comなんぞ信用してないので無問題。
どう反応していいのか悩んだのでのですが...。
冗談なのかネガティブコメントなのか判断がつきません。
(とある人にはネガコメと断言されました。)
とりあえず、そのまま受け止めて返事しますが、当ブログ上では信用されない事はしていないつもりです。
その辺りかなり気をつけて書いていますのでこう書かれるのは非常に残念です。
特にfuktommyさんとはこれまで一度も接触がなかったために、なんとも言えない気持ちです。
(もしこれが初接触でなければごめんなさい。)
訂正するのも嫌らしいのでそのままにしておきます。
はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。
このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。
そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。
このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。
これを踏まえて以下記述します。
「#」ではじまるのがはてなブックマークのコメントです。
#2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？
#2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？
申し訳ないです。実行結果を見たときの気持ち悪さを優先したため、非常にわかりにくくなってしまいました。
調査結果は日本語で書くようにしています。
一覧等の無機質な情報を表示するのではなく、得られた情報から第三者がどのように推測するかを想定していました。
ガードが堅いというのは、何も情報が得られなかった時に表示されます。
#2008年10月24日 hasegawayosuke XSSでJavaScriptが動くのはその脆弱なサイト上なので、特定サービスのidやハンドルネーム云々は関係ないぢゃん。visited調査は攻撃者が自分でサイト用意しても一緒ぢゃん。…という反論にはどう対応する?
id/ハンドルネームを取得できてしまうサービスには、「脆弱性等、本来意図していない挙動によりid/ハンドルネームが取得されてしまう」場合と、「管理者サイドではid/ハンドルネームの取得を(本当の理由がどうであれ)仕様と見なしている」場合があると思います。
今回は後者を前提としており、脆弱性のない普通のシステム/サービスにおいても、id/ハンドルネームは取得できる場合を指していました。
後半で他の脆弱性を利用するためにXSSが使われると書きましたが、先にid/ハンドルネームの話を持ってきたのはこれが理由です。
visited調査に関してですが、危険なサイトを訪問しなくてもXSSのあるサイトでも起こりえるというのが重要なので充分に反論できると思います。
#2008年10月24日 hiroyukiegami 非常にいいまとめ
非常にいいまとめではありません。
XSSを理解している人からすると非常に歯痒いエントリーだと思います。
#2008年10月24日 showyou ちょっと気になるとこあったのでエントリ書きました。http://d.hatena.ne.jp/showyou/20081024#1224846631
#2008年10月25日 Kanatoko JavaScriptインジェクションとXSSは違うのでつよ
#2008年10月26日 kicchomu3 XSSはJavascript以外でもできるでしょ。
その通りですね。XSSはJavaScriptのみではありませんでした。
a要素・img要素・iframe要素のようなhtmlもありますし、CSSでも表示を変更する事ができます。
VBScriptもありました。
object要素を含めるとなんでもありますね。
「個人的にはXSSは『JavaScriptインジェクション』と呼称した方がいいのではと思っています。」は訂正します。
そもそも『JavaScriptインジェクション』という言葉は既にあったようです。
個人的には『インジェクション』という言葉を使った方が対策が進むのではないかと思っているので、こう書いてしまいました。
意図しないような反論をまた受ける可能性を恐れずに書くと、『クライアントコードインジェクション』はどうでしょうか。
#2008年10月24日 Kenta_K 検索はGoogleしか使わないのに、Yahooって言うニュースサイトで検索してるって言われたんだけど…？
これはcheck_visited.htmlの精度の問題です。
対象は、このblogを見に来られる人やはてなを使っている人がするようなリンクを使った画面遷移ではなく、「技術に疎い人」がブックマーク(お気に入り)で画面を表示する場合を想定しています。
あと、ニュースサイト限定ではなく、『全般』の話です。
ここでは詳細を避けます。
詳しく知りたい方はコードを読んで頂くか直接ご連絡下さい。
#2008年10月24日 sippu おお怖い。こういう手法もあるのか。ってかこれってよく使う方法も良くあるよね？（お勧め表示とか）
よくあります。
ただ、道徳的に問題はないのかという話もあります。
まだこの方法の評価が固まっていないのでどうなるかはわかりませんが、道徳的に問題があるという認識になるのではないかと思っています。
#2008年10月25日 into_the_blue 悪質なサイトじゃなくても、実はやっていること。わざわざ脆弱なサイト見つけてまでこれをやるより、どーせならCookie盗んで（ｒｙとかキーロガーしかけて（ｒｙのほうがいいな（自分が攻撃者だったとしたら）
そうですね。Cookieやキーロガーの方が対効果比が非常に高いと思います。
ただ、それらを見せられるよりも今回の方法の方が『一般的な人は気持ち悪いと感じる』と考えてこのようにしています。
それに、Cookieを盗んだりをここですると私が訴えられる可能性もゼロではなくなるのでご了承下さい。
#2008年10月25日 m-_-m 勤勉なNoScriptのお陰で「訪問先確認」が真っ白ﾜﾛﾀ
NoScriptを入れられるとJavaScriptでは手も足もでません。
#2008年10月25日 fuktommy "あなたの作ったサービスを信用して訪問してくれた人"←もちろんkanasansoft.comなんぞ信用してないので無問題。
どう反応していいのか悩んだのでのですが...。
冗談なのかネガティブコメントなのか判断がつきません。
(とある人にはネガコメと断言されました。)
とりあえず、そのまま受け止めて返事しますが、当ブログ上では信用されない事はしていないつもりです。
その辺りかなり気をつけて書いていますのでこう書かれるのは非常に残念です。
特にfuktommyさんとはこれまで一度も接触がなかったために、なんとも言えない気持ちです。
(もしこれが初接触でなければごめんなさい。)