アカウント名:
パスワード:
# ここにぶら下げてみる
原文を見る限り、別に「XSSなんて全く対策しなくてよろしい」って言っている訳じゃ無いんですよね。XSSが致命的な問題を引き起こすような場所については、ちゃんと対策はすべきだと言ってますし、そうではない場所については、それらに応じた対処の優先順序があるだろうということかと。
# 親コメントの方の言うとおり、損害と利益を天秤にかけてということになるでしょう。
嘘はいけない。
原文を見る限り、別に「XSSなんて全く対策しなくてよろしい」って言っている訳じゃ無いんですよね。 XSSが致命的な問題を引き起こすような場所については、ちゃんと対策はすべきだと言ってますし、
それどこに書いてあります？そんな文章、見あたらないのですが。
リスクを考える際には、脆弱性の存在とともに、その脆弱性の悪用難易度と発生頻度も考えなければなりません。悪用が難しく、発生頻度が低いリスクに関しては、リスクを保有するのが自然な考えではないかと思います。世の企業はセキュリティで100点満点を取るためにビジネスをやっているわけではありません。ビジネスのメリットとデメリットを考えて対策を選別するべきです。まずは掲示板、日記など、外部からデータを登録可能な内容を閲覧する機能にはXSSが存在しないようにしてください。特に「不特定多数からデータを登録可能」かつ「そのデータを不特定多数に表示する」機能については攻撃者に狙われる確率が高く、狙われた場合の被害が大きくなりますので、対策の優先順位は高くするべきです。
リスクを考える際には、脆弱性の存在とともに、その脆弱性の悪用難易度と発生頻度も考えなければなりません。悪用が難しく、発生頻度が低いリスクに関しては、リスクを保有するのが自然な考えではないかと思います。世の企業はセキュリティで100点満点を取るためにビジネスをやっているわけではありません。ビジネスのメリットとデメリットを考えて対策を選別するべきです。
まずは掲示板、日記など、外部からデータを登録可能な内容を閲覧する機能にはXSSが存在しないようにしてください。特に「不特定多数からデータを登録可能」かつ「そのデータを不特定多数に表示する」機能については攻撃者に狙われる確率が高く、狙われた場合の被害が大きくなりますので、対策の優先順位は高くするべきです。
これが該当するものかと。
まずは掲示板、日記など、外部からデータを登録可能な内容を閲覧する機能にはXSSが存在しないようにしてください。
つまり、セッションハイジャック攻撃は無視してよいというのが、LACの水準ですか。 もしかして、この著者は、Cookieが漏れることはたいしたことないという理解なの？
掲示板のXSSなんかむしろ全然問題じゃないのだけど。
その時点で考えうるあらゆる脆弱性のパターンを列挙しろと? さすがに穿った見方すぎでしょう。 かけられるコストの範囲で考えたら XSS 程度そんなに優先度を高める必要はないが、場合によっては優先順位を高める必要がある、と言っているだけでしょう。 掲示板や日記は普通の人にも分かりやすい「サーバにデータを登録するパターン」として挙げているだけにしか見えませんよ。
バランスを考えて対応しろと言っているのに、他の深刻な脆弱性はどうでもいいと判断できる意味がわかりません。
> その時点で考えうるあらゆる脆弱性のパターンを列挙しろと?セキュリティアナリストならそれが当然では？
> その時点で考えうるあらゆる脆弱性のパターンを列挙しろと?
セキュリティアナリストならそれが当然では？
それは実際に行っている業務中のレポートにあれば十分であり、こんな Web 中の記事内に想定されるあらゆる脆弱性のパターンを列挙する、なんてのはただの馬鹿です。
LACに診断を依頼した場合に、XSSが見つかったときに、 サイトがCookieの漏洩でセッションハイジャックで結果どんな被害が出るか、 その分析をしないで、一律にXSSはたいしたことないなんて言われちゃうんじゃ困りますよ。
LAC は別にサイト構築を一手に引き受けているような企業じゃありませんけど。 検証するアプリがどういった情報を取り扱い、該当アプリに脆弱性があった場合にどれだけの問題が発生するかを設計しているのは検査を依頼する側の会社がやることでしょう。
一律に XSS は大したことがないと言っているのではなく、XSS 脆弱性があるからこれは常に大問題だと考える事はプライオリティが全く理解できていないのではないかと啓蒙しているだけでしょう。
記事にした以上、どういう場合に優先順位を高める必要があるのか書くのが常識ですよね。 で、それを書いたのが掲示板っていうんじゃ、 はっきり言って、専門家として程度が低いと言わざるを得ない。
長くなりすぎる上に「普通分かるだろ……」と思ったので前コメントには書きませんでしたが、たかが掲示板であると言っても「ゲーム会社 (例えばコーエーとか) が運営する、ユーザ情報と連携した掲示板」や「mixi のコミュニティ機能」なんかは個人情報に繋がる可能性があります。 こうした「掲示板」ではそこらに転がってる掲示板スクリプト (mini BBS とかでもいいですか) 等と比較すると脆弱性があった場合の問題レベルが全く異なる事は容易に想像できます。 そういった事を全く想像できない時点で想像力が足りないのではないでしょうか。
このようなメディアでの啓発目的の解説記事で、XSSはたいしたことない（場合がある）という趣旨のことを書くからには、そうではない場合にどのような場合があるかを明記するのが当然です。そうしないと、なんでもかんでもXSSならたいしたことないという誤った理解を誘発してしまうのが明らかだからです。実際、このスラッシュドットにもそのような影響を受けたコメントが出ていますよ。
LACに診断を依頼した場合に、XSSが見つかったときに、
このようなメディアでの啓発目的の解説記事で、XSSはたいしたことない（場合がある）という趣旨のことを書くからには、そうではない場合にどのような場合があるかを明記するのが当然です。
読解力も想像力も欠如し、書かれている内容の表面だけをさらっと見てそれが全てだと思いこむような人ばかりであればそうなのでしょうね。 あらゆる場合において XSS は非常に危険で何をおいても対応しなければならないような問題であると考える必要はない、としか書いていないように思えますが。
ええ？そうなの？脆弱性診断といったらそのサイトの機能に照らして具体的な影響まで示すのが仕事だと思ってましたが、LACは違うのですか。LACってツール動かしてレポート渡すだけの会社でしたっけ？
豪快に勘違いしていませんか? 元コメントで言っているのは以下の通り。
LAC は別にサイト構築を一手に引き受けているような企業じゃありませんけど。検証するアプリがどういった情報を取り扱い、該当アプリに脆弱性があった場合にどれだけの問題が発生するかを設計しているのは検査を依頼する側の会社がやることでしょう。
LAC は別にサイト構築する段階から関わり、情報設計や影響範囲までを「設計」しているようなトコじゃない、と言っているのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
客よ、目くじら立てるなって事? (スコア:1)
コストと期待値を比較評価したと言う論拠を顧客に突きつければ説得出来そうな気がするんですが、 現実にはそんなことはなく、原理主義者とか原理主義者に煽られてその気になってる素人が多すぎる、っちゅうことでしょうか?
素人考えですが、説得は諦めて、「○○の被害が起きたら賠償金いくら」ぐらいまで契約に盛り込んでおいて、 どこまでのセキュリティー対策をやるのかを完全にベンダ側の裁量にしてしまうとか?
Re: (スコア:2, 参考になる)
# ここにぶら下げてみる
原文を見る限り、別に「XSSなんて全く対策しなくてよろしい」って言っている訳じゃ無いんですよね。
XSSが致命的な問題を引き起こすような場所については、ちゃんと対策はすべきだと言ってますし、
そうではない場所については、それらに応じた対処の優先順序があるだろうということかと。
# 親コメントの方の言うとおり、損害と利益を天秤にかけてということになるでしょう。
Re: (スコア:0)
嘘はいけない。
それどこに書いてあります？そんな文章、見あたらないのですが。
Re:客よ、目くじら立てるなって事? (スコア:1, 参考になる)
これが該当するものかと。
Re: (スコア:0)
つまり、セッションハイジャック攻撃は無視してよいというのが、LACの水準ですか。 もしかして、この著者は、Cookieが漏れることはたいしたことないという理解なの？
掲示板のXSSなんかむしろ全然問題じゃないのだけど。
Re:客よ、目くじら立てるなって事? (スコア:1)
その時点で考えうるあらゆる脆弱性のパターンを列挙しろと? さすがに穿った見方すぎでしょう。
かけられるコストの範囲で考えたら XSS 程度そんなに優先度を高める必要はないが、場合によっては優先順位を高める必要がある、と言っているだけでしょう。
掲示板や日記は普通の人にも分かりやすい「サーバにデータを登録するパターン」として挙げているだけにしか見えませんよ。
バランスを考えて対応しろと言っているのに、他の深刻な脆弱性はどうでもいいと判断できる意味がわかりません。
Re: (スコア:0)
セキュリティアナリストならそれが当然では？
LACに診断を依頼した場合に、XSSが見つかったときに、
サイトがCookieの漏洩でセッションハイジャックで結果どんな被害が出るか、
その分析をしないで、一律にXSSはたいしたことないなんて言われちゃうんじゃ困りますよ。
> 場合によっては優先順位を高める必要がある、と言っているだけでしょう。
記事にした以上、どういう場合に優先順位を高める必要があるのか書くのが常識ですよね。
で、それを書いたのが掲示板っていうんじゃ、
はっきり言って、専門家として程度が低いと言わざるを得ない。
Re:客よ、目くじら立てるなって事? (スコア:2, 興味深い)
それは実際に行っている業務中のレポートにあれば十分であり、こんな Web 中の記事内に想定されるあらゆる脆弱性のパターンを列挙する、なんてのはただの馬鹿です。
LAC は別にサイト構築を一手に引き受けているような企業じゃありませんけど。
検証するアプリがどういった情報を取り扱い、該当アプリに脆弱性があった場合にどれだけの問題が発生するかを設計しているのは検査を依頼する側の会社がやることでしょう。
一律に XSS は大したことがないと言っているのではなく、XSS 脆弱性があるからこれは常に大問題だと考える事はプライオリティが全く理解できていないのではないかと啓蒙しているだけでしょう。
長くなりすぎる上に「普通分かるだろ……」と思ったので前コメントには書きませんでしたが、たかが掲示板であると言っても「ゲーム会社 (例えばコーエーとか) が運営する、ユーザ情報と連携した掲示板」や「mixi のコミュニティ機能」なんかは個人情報に繋がる可能性があります。
こうした「掲示板」ではそこらに転がってる掲示板スクリプト (mini BBS とかでもいいですか) 等と比較すると脆弱性があった場合の問題レベルが全く異なる事は容易に想像できます。
そういった事を全く想像できない時点で想像力が足りないのではないでしょうか。
Re: (スコア:0)
このようなメディアでの啓発目的の解説記事で、XSSはたいしたことない（場合がある）という趣旨のことを書くからには、そうではない場合にどのような場合があるかを明記するのが当然です。そうしないと、なんでもかんでもXSSならたいしたことないという誤った理解を誘発してしまうのが明らかだからです。実際、このスラッシュドットにもそのような影響を受けたコメントが出ていますよ。
Re:客よ、目くじら立てるなって事? (スコア:1)
読解力も想像力も欠如し、書かれている内容の表面だけをさらっと見てそれが全てだと思いこむような人ばかりであればそうなのでしょうね。
あらゆる場合において XSS は非常に危険で何をおいても対応しなければならないような問題であると考える必要はない、としか書いていないように思えますが。
豪快に勘違いしていませんか? 元コメントで言っているのは以下の通り。
LAC は別にサイト構築する段階から関わり、情報設計や影響範囲までを「設計」しているようなトコじゃない、と言っているのですが。