Coders Conquer Security:シェアして学ぶ - クロスサイトスクリプティング

2018年12月06日掲載
ジャープ・カラン・シン著
ケーススタディ

Coders Conquer Security:シェアして学ぶ - クロスサイトスクリプティング

2018年12月06日掲載
ジャープ・カラン・シン著
リソースを見る
リソースを見る

Webブラウザは、オンライン上のあらゆる素晴らしいものへの入り口となっているかもしれませんが、残念ながら、良いことばかりではありません。ウェブ・ブラウザの固有の動作が、セキュリティ脆弱性のきっかけになることがあるのです。ブラウザはまず、自分が見たマークアップを信頼し、疑うことなく実行するという特徴を持っています。

クロスサイトスクリプティング(XSS)は、ブラウザの信頼性とユーザーの無知を利用して、データを盗んだり、アカウントを乗っ取ったり、ウェブサイトを改ざんしたりするもので、あっという間にひどい状態になってしまう脆弱性です。

XSSがどのように機能するのか、どのような被害が出るのか、どうすれば防げるのかを見ていきましょう。

XSSの仕組みは?

XSSは、信頼されていない入力(多くの場合、データ)がページの出力として表示されているにもかかわらず、実行可能なコードと誤認されることで発生します。攻撃者は、入力パラメータの中に悪意のある実行コード(HTMLタグやJavaScriptなど)を置くことができ、ブラウザに返されたときに、データとして表示されるのではなく実行されてしまいます。

前述のとおり、この脆弱性は、データと実行コードを区別することが難しいブラウザの中核的な機能の動作に起因しています。Webの動作モデルは次のようになっています。

  1. ユーザーがWebページにアクセスする
  2. ページでは、どのファイルを読み込み、何を実行するかをブラウザに伝えます
  3. ブラウザは、ページに書かれていることを問答無用で実行する

この機能のおかげで、私たちがウェブで楽しんでいる最も素晴らしいインタラクティブな体験のいくつかが生まれました。

攻撃者が悪意のあるスクリプトを脆弱なサイトに追加すると、何の疑いもなく実行されてしまいます。より深い調査も、検知手段も用意されていません。

ユーザーのブラウザでカスタムjavascriptコードが実行される可能性があります。

XSSには3つのタイプがあります。

  • ストアドXSS
  • 反射型XSS
  • DOM XSS

Stored XSSは、攻撃者がアプリケーションのデータフィールド(ユーザの携帯電話番号を格納するフィールドなど)に悪意のあるスクリプトを持続的に格納できる場合に発生します。

このタイプの攻撃は、フォーラムサイトやコメントエンジンでよく見られます。攻撃者がコメントに悪意のあるスクリプトを入力すると、そのコメントを見たすべてのユーザが知らず知らずのうちにそのスクリプトを実行してしまいます。

反射型XSSは、ユーザの入力がそのままユーザのブラウザに反映されることで発生します。

ここで、検索結果を取得する際に、ユーザに「You searched for ...」と表示する検索ボックスがあったとしましょう。悪意のある攻撃者は、同じパラメータに悪意のあるスクリプトを埋め込んだリンクを被害者に送ることができますが、正直なところ、ほとんどのウェブユーザはそれに気づきません。

被害者がリンクをクリックすると、フィッシングサイトにリダイレクトされ、知らず知らずのうちにそのサイトのパスワードを入力してしまいます。

DOM XSSは、この脆弱性の中でも比較的新しいものです。

これらのテンプレートは、動的なコンテンツやリッチなUIアプリケーションを可能にします。誤った使い方をすると、XSS攻撃の実行に利用されてしまいます。

以上、XSSの範囲について説明しました。XSSの範囲を簡単にご理解いただけたと思います。それでは、XSSがどのように破壊的に使用されるのか、さらに深く掘り下げてみましょう。

なぜXSSは危険なのか?

XSSは、ユーザーを悪意のあるサイトにリダイレクトしたり、クッキーを盗んだり、セッションデータを探したりするのに使われます。基本的に、JavaScriptでできることはすべて、XSS攻撃でも可能です。

XSS攻撃の例を3つ紹介します。

  1. ヤフーのメールユーザーは、2015年にXSSを使ってセッションクッキーを盗まれました
  2. Samy ワームは、MySpace の XSS 脆弱性を利用して配布されました。わずか20時間で100万人のユーザーに影響を与えたこのワームは、今でも史上最速の拡散力を誇るマルウェアです。
  3. eBayでは、商品説明文に悪意のあるスクリプトが含まれることがありました。これにより、eBayのユーザーに対してXSS攻撃が行われていました。

XSS攻撃は、単純なようでいて非常に深刻です。XSS攻撃は、セッション、ユーザー認証情報、または機密データの盗難につながる可能性があります。評判の低下や収益の減少は、これらの攻撃の大きな落とし穴です。

しかし、XSSは、あなたのような経験豊富なセキュリティ戦士が打ち負かすことができます。修正方法は複雑ではありませんし、XSSが一般的に使用されるようになってから、業界は長い長い道のりを歩んできました。

XSSを倒すことができます。

XSSを撃退するには、コンテキストを理解することが重要です。具体的には、ユーザーの入力がどのような状況でクライアントに戻されるのか、どこで戻されるのかということです。HTMLコードの中か、JavaScriptのスニペットの中か。

ユーザー入力がブラウザに送り返される必要がなければ、それに越したことはありません。しかし、必要な場合は、多くの場合、HTMLエンコードされるべきです。出力をHTMLエンコードすることで、ブラウザはコンテンツをそのままレンダリングし、実行しないように指示します。

入力の検証も重要です。しかし、検証やホワイトリスト確実な解決策ではありません 。エンコーディングはさらに数歩進んで、ブラウザが悪意のあるスクリプトを実行するのを阻止します。

多くのフレームワークが、HTML出力を自動的にエンコードするようになっています。
AngularASP.NET MVCReact.jsは、デフォルトのHTMLエンコードが使用されるフレームワークです。

その他のほとんどのフレームワーク(DjangoSpring など)には、XSS 対策のための標準ライブラリが用意されており、簡単にコードに組み込むことができます。

最大の課題は、ユーザーの入力がシステムに入る方法をすべて分析し、それを見極めることができるようになることです。クエリ・パラメータは、ポスト・パラメータと同様に、攻撃の対象となる可能性があります。アプリケーション全体のデータの流れを追い、外部からのデータを信用しないようにしてください。

国境警備隊のように考えてください。すべてのデータを止めて検査し、悪意があると思われるものは入れないようにします。

これらの戦略を実行すれば、XSS による攻撃からユーザーを守ることができます。OWASP Cheat Sheetには、データを管理するためのさらなるヒントが掲載されていますので、ぜひご覧ください。

XSSを阻止し、セキュリティスキルをレベルアップさせる。

XSSは、OWASP Top 10 2017のWebセキュリティリスクのリストの7位に存在しています。

トレーニングは、開発者がコードを作成する際に、セキュリティを第一に考えた考え方を構築する上で非常に重要です。そして、そのトレーニングは、開発者が実際に使用している言語で、実際のアプリケーションをシミュレートすることで、常に最も効果的なものとなります。この点を踏まえて、XSSについての詳細を学ぶために、ラーニングリソースをチェックしてみてはいかがでしょうか。その後、トレーニングと実践を重ねて、マスターを目指しましょう。

XSSの脆弱性を見つけて修正する準備が今すぐできたと思いますか? 挑戦してみませんか? Secure Code Warrior プラットフォームで。

リソースを見る
リソースを見る

著者

Jaap Karan Singh

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

Coders Conquer Security:シェアして学ぶ - クロスサイトスクリプティング

2018年12月06日掲載
Jaap Karan Singh著

Webブラウザは、オンライン上のあらゆる素晴らしいものへの入り口となっているかもしれませんが、残念ながら、良いことばかりではありません。ウェブ・ブラウザの固有の動作が、セキュリティ脆弱性のきっかけになることがあるのです。ブラウザはまず、自分が見たマークアップを信頼し、疑うことなく実行するという特徴を持っています。

クロスサイトスクリプティング(XSS)は、ブラウザの信頼性とユーザーの無知を利用して、データを盗んだり、アカウントを乗っ取ったり、ウェブサイトを改ざんしたりするもので、あっという間にひどい状態になってしまう脆弱性です。

XSSがどのように機能するのか、どのような被害が出るのか、どうすれば防げるのかを見ていきましょう。

XSSの仕組みは?

XSSは、信頼されていない入力(多くの場合、データ)がページの出力として表示されているにもかかわらず、実行可能なコードと誤認されることで発生します。攻撃者は、入力パラメータの中に悪意のある実行コード(HTMLタグやJavaScriptなど)を置くことができ、ブラウザに返されたときに、データとして表示されるのではなく実行されてしまいます。

前述のとおり、この脆弱性は、データと実行コードを区別することが難しいブラウザの中核的な機能の動作に起因しています。Webの動作モデルは次のようになっています。

  1. ユーザーがWebページにアクセスする
  2. ページでは、どのファイルを読み込み、何を実行するかをブラウザに伝えます
  3. ブラウザは、ページに書かれていることを問答無用で実行する

この機能のおかげで、私たちがウェブで楽しんでいる最も素晴らしいインタラクティブな体験のいくつかが生まれました。

攻撃者が悪意のあるスクリプトを脆弱なサイトに追加すると、何の疑いもなく実行されてしまいます。より深い調査も、検知手段も用意されていません。

ユーザーのブラウザでカスタムjavascriptコードが実行される可能性があります。

XSSには3つのタイプがあります。

  • ストアドXSS
  • 反射型XSS
  • DOM XSS

Stored XSSは、攻撃者がアプリケーションのデータフィールド(ユーザの携帯電話番号を格納するフィールドなど)に悪意のあるスクリプトを持続的に格納できる場合に発生します。

このタイプの攻撃は、フォーラムサイトやコメントエンジンでよく見られます。攻撃者がコメントに悪意のあるスクリプトを入力すると、そのコメントを見たすべてのユーザが知らず知らずのうちにそのスクリプトを実行してしまいます。

反射型XSSは、ユーザの入力がそのままユーザのブラウザに反映されることで発生します。

ここで、検索結果を取得する際に、ユーザに「You searched for ...」と表示する検索ボックスがあったとしましょう。悪意のある攻撃者は、同じパラメータに悪意のあるスクリプトを埋め込んだリンクを被害者に送ることができますが、正直なところ、ほとんどのウェブユーザはそれに気づきません。

被害者がリンクをクリックすると、フィッシングサイトにリダイレクトされ、知らず知らずのうちにそのサイトのパスワードを入力してしまいます。

DOM XSSは、この脆弱性の中でも比較的新しいものです。

これらのテンプレートは、動的なコンテンツやリッチなUIアプリケーションを可能にします。誤った使い方をすると、XSS攻撃の実行に利用されてしまいます。

以上、XSSの範囲について説明しました。XSSの範囲を簡単にご理解いただけたと思います。それでは、XSSがどのように破壊的に使用されるのか、さらに深く掘り下げてみましょう。

なぜXSSは危険なのか?

XSSは、ユーザーを悪意のあるサイトにリダイレクトしたり、クッキーを盗んだり、セッションデータを探したりするのに使われます。基本的に、JavaScriptでできることはすべて、XSS攻撃でも可能です。

XSS攻撃の例を3つ紹介します。

  1. ヤフーのメールユーザーは、2015年にXSSを使ってセッションクッキーを盗まれました
  2. Samy ワームは、MySpace の XSS 脆弱性を利用して配布されました。わずか20時間で100万人のユーザーに影響を与えたこのワームは、今でも史上最速の拡散力を誇るマルウェアです。
  3. eBayでは、商品説明文に悪意のあるスクリプトが含まれることがありました。これにより、eBayのユーザーに対してXSS攻撃が行われていました。

XSS攻撃は、単純なようでいて非常に深刻です。XSS攻撃は、セッション、ユーザー認証情報、または機密データの盗難につながる可能性があります。評判の低下や収益の減少は、これらの攻撃の大きな落とし穴です。

しかし、XSSは、あなたのような経験豊富なセキュリティ戦士が打ち負かすことができます。修正方法は複雑ではありませんし、XSSが一般的に使用されるようになってから、業界は長い長い道のりを歩んできました。

XSSを倒すことができます。

XSSを撃退するには、コンテキストを理解することが重要です。具体的には、ユーザーの入力がどのような状況でクライアントに戻されるのか、どこで戻されるのかということです。HTMLコードの中か、JavaScriptのスニペットの中か。

ユーザー入力がブラウザに送り返される必要がなければ、それに越したことはありません。しかし、必要な場合は、多くの場合、HTMLエンコードされるべきです。出力をHTMLエンコードすることで、ブラウザはコンテンツをそのままレンダリングし、実行しないように指示します。

入力の検証も重要です。しかし、検証やホワイトリスト確実な解決策ではありません 。エンコーディングはさらに数歩進んで、ブラウザが悪意のあるスクリプトを実行するのを阻止します。

多くのフレームワークが、HTML出力を自動的にエンコードするようになっています。
AngularASP.NET MVCReact.jsは、デフォルトのHTMLエンコードが使用されるフレームワークです。

その他のほとんどのフレームワーク(DjangoSpring など)には、XSS 対策のための標準ライブラリが用意されており、簡単にコードに組み込むことができます。

最大の課題は、ユーザーの入力がシステムに入る方法をすべて分析し、それを見極めることができるようになることです。クエリ・パラメータは、ポスト・パラメータと同様に、攻撃の対象となる可能性があります。アプリケーション全体のデータの流れを追い、外部からのデータを信用しないようにしてください。

国境警備隊のように考えてください。すべてのデータを止めて検査し、悪意があると思われるものは入れないようにします。

これらの戦略を実行すれば、XSS による攻撃からユーザーを守ることができます。OWASP Cheat Sheetには、データを管理するためのさらなるヒントが掲載されていますので、ぜひご覧ください。

XSSを阻止し、セキュリティスキルをレベルアップさせる。

XSSは、OWASP Top 10 2017のWebセキュリティリスクのリストの7位に存在しています。

トレーニングは、開発者がコードを作成する際に、セキュリティを第一に考えた考え方を構築する上で非常に重要です。そして、そのトレーニングは、開発者が実際に使用している言語で、実際のアプリケーションをシミュレートすることで、常に最も効果的なものとなります。この点を踏まえて、XSSについての詳細を学ぶために、ラーニングリソースをチェックしてみてはいかがでしょうか。その後、トレーニングと実践を重ねて、マスターを目指しましょう。

XSSの脆弱性を見つけて修正する準備が今すぐできたと思いますか? 挑戦してみませんか? Secure Code Warrior プラットフォームで。

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

送信
フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。