XSSに対する対策として、入力パラメータに対するサニタイズ処理を行うのは一般的です。例えば、入力文字列をに含まれる＆を＆amp;に、ダブルクォートは＆quot;に、<は＆lt;、>は＆gt;に変換するといった処理を行うことによって、HTMLの一部として扱われる文字列を無害な文字に変換します。但し、ある条件によってはサニタイズされていたとしても悪用される恐れのある場合があります。
例えば、以下のようにイベントハンドラーのparam部分にGET/POSTのパラメータが挿入される場合、入力文字列がサニタイズされていれば大丈夫でしょうか？
| <input VALUE=”実行” onclick="escape(‘param’)" type="button" /> |
文字列として「’),alert(document.cookie);//」を挿入すると、シングルクォーテーションがサニタイズされて＆＃３９；となり、以下のように表示されるはずです。サニタイズしてるからJavascriptは動かないはず・・・でも、ボタンを押すとJavascriptが実行されてポップアップが上がってきます。
| <input VALUE=”実行” onclick="escape(‘param'),alert(document.cookie);//’)" type="button" /> |
シングルクォーテーションをマニュアル通りにサニタイズしているのであれば、上記のようなイベントハンドラーに埋め込まれたXSSの問題を回避することができません。場合によって様々なサニタイズパターン(上記の場合はシングルクォーテーションを全角に変換するとか)を作ることも対策としては有効ですが、複雑になってしまい逆に対策漏れが生じてしまう危険性がある為、パラメータにシングルクォーテーション等の不正な文字列が挿入された場合はエラー画面を表示する等の対策が一番無難な対策になります。
他にもいろいろとパターンがあるかもしれませんが、エラー画面を表示することによって大体対策できるように思います。みなさんのWebアプリケーションはいかがでしょう？
少し前になりますが、XSS(クロスサイトスクリプティング)の危険性に関する記事を見ました。内容は、XSSの問題について過敏に反応しすぎなのでは？という内容ですが、いままでにない見解で非常に面白く拝見させて頂いたことを記憶してます。
理由としては、以下のような内容が述べられていました。
世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？| 「XSSなんてバグなんだから存在してはならない」 |
たしかに、SQLインジェクションと比較すると、XSSが事件となった事例は比較にならないくらい少ないんですよね(ないということではありません・・)。実際に問題の存在するサイトの数としては、SQLインジェクションの存在するサイトよりもXSSの存在するサイトの方が多く、XSSを使って攻撃することは容易だと思いますが、なぜ大きな事件にならないのでしょうか？
これは個人的な推測ですが、XSSによる攻撃を受けた場合、その痕跡の残らない可能性が高いという点があります。例えば、GETのパラメータとしてXSSを悪用する文字列が送信された場合はWebサーバのログに残りますが、POSTで送信された場合はログにすら残りません。また、XSSの問題が悪用されたことを後から追跡することも(ログが存在しない場合は)困難な為、もし情報が漏洩していたとしてもXSSを悪用されたことが発覚することはありません。
SQLインジェクションの問題についてもそうですが、セキュリティインシデントというのは発覚しなければ事件にはなりません。私もいろんなサイトにメールアドレスを登録してますが、いつしかスパムメールがいろんなところから届くようになりました。どこかでメールアドレスが漏洩してるはずなんですが、過去に登録したサイトで情報が漏洩したなんてニュースを見た記憶(あったけど見てないだけかもしれませんが)はありません。きっと、管理者の知らないうちに脆弱性を利用して情報を盗んでいる攻撃者がいるはずで、事件となって取り上げられている事例は氷山の一角にすぎないはずです。
攻撃者の視点からXSSの問題をどう悪用しようか考えた場合、まず一番に考えられるのは罠を仕掛けて不特定多数の人を罠に誘導することによって行う攻撃です。ただし、記事にもありましたが、不特定多数を対象とし、罠を仕掛けて誘導するのであればクライアントアプリケーションの脆弱性を利用してボットを仕込む方が効率的です。
では、どういった場合にXSSを悪用するのかと考えた場合、スピア方攻撃によるXSSの悪用が挙げられます。企業のシステムや端末では、OSのパッチ適用やアンチウィルスのインストールがポリシーとして定められており、既知の脆弱性については早期に対策されていることもあります。その場合はボットを仕込むことは難しくなりますが、XSSであればアプリケーション側で対策しない限り悪用することができます。さらに、社内で使われているメールアドレスを偽装してXSSの罠に誘導することはそれ程難しいことではありません(管理部から、次のURLを参照してインフルエンザ対策を実施するようにといった内容のメールが届くとみんなURLを開いてしまうかもしれません)。
つまり、XSSは悪用することができないのではなく、また効率的ではないので悪用されないのでもなく、場合によっては攻撃手段として非常に有効な脆弱性であり、攻撃者もその点は理解しているはずです。不特定多数を対象とした攻撃としては効率的ではない為、数は多く検出されないだけなのかもしれません。
XSSの対策をとる為には、Webアプリケーションに対するセキュリティ検査や改修費用等、かなりコストがかかるのが一般的です。前述の記事では、XSSによるリスクを以下のように分析していました。つまり、このようなリスクに対して対策が必要だと感じる場合は対策した方が良いとの考え方です。でも、以下の内容はネット上でビジネスを展開しているほとんどの企業が該当するように思います。うちはまったく問題ないぞ～なんて企業あるんでしょうか？
|
対策としては、Webアプリケーションを開発するたびにセキュリティ検査の実施や改修を行うのではコストがかかるため、WAF(Wab Application Firewall)を導入することを検討するという手もあると思います。コストはかかりますが、セキュリティ検査と改修費用を考えると、同じくらいか、もしくは安くすむのではないでしょうか。また、WebサーバとしてApacheの利用が一般的であるように、mod_security等の無料のWAFも使って当たり前という考え方があればWebアプリケーションの脆弱性も少なくなるはずです。なかなかシステムを動かす為に必須ではない為、そこまでやってる開発会社は少ないのが現状です。
やはり一般的な対策としてはセキュリティ検査会社に頼んで問題箇所を特定し、開発会社に改修を依頼するのが一般的ですが、うちにWeb開発を依頼すればWAFも導入しますよ！なんて開発会社があれば今後は注目されるのかもしれません。
