Cross-site scripting-XSSと呼ばれるアプリケーション脆弱性は、アプリケーションやWebサイトに大打撃を与える可能性があるものである。 XSS は、Open Web Application Security Project (OWASP) のトップ 10 脆弱性リストに含まれ続けているほど、横行し、潜在的に有害なものです。
実際、クロスサイトスクリプティングは2014年以降に発見された最も一般的な脆弱性で、2019年も、報告された脆弱性のトップ3に登場し続けています。
Cross-Site Scripting (XSS) とは？
場合によっては、ブラウザ側のスクリプトもこの脆弱性をもたらし、攻撃者はターゲット ユーザーが Web アプリケーションにリクエストを行わなくてもこの脆弱性を悪用することが可能になります。 このスクリプトは、多くの場合、Web アプリケーションのレスポンスのコンテンツに含まれているため、実行されると、そのスクリプトが正当であるかのように同じアクセス権を持ちます。 セッション・トークンやクッキー、さらにはブラウザがそのサイト上でアクセスできる機密情報や重要情報へのアクセスが許可され、HTMLページのコンテンツさえも書き換えられてしまう可能性があります。
XSS 攻撃からの保護
クラウド ネイティブ アプリケーションの構築に使用されるオープン ソースの依存関係の脆弱性を自動的に検出し、優先順位を付けて修正する
クロスサイト スクリプトはどのようにして機能するか
XSS 攻撃の種類は？
反射型 XSS 攻撃
反射型 XSS 攻撃では、悪意のあるスクリプトが HTTP リクエストに注入されます (通常はユーザーに提供される、特に細工したリンクによって)。 最も単純なタイプとして、これは、有害なスクリプト コンテンツを含むように簡単に操作できる HTTP リクエストの入力パラメータを使用します。
この場合、サーバーに実際に悪意のあるデータを保存することなく、保存型 XSS のように動作します。
Reflected XSS 攻撃の例を次に示します。 リクエストの URL は次のようになります。 https://example.com/profile?user=Tammy. この入力に基づき、ウェブアプリケーションはこのようにページの一番上に「Hi Tammy」と応答します。 もし、パラメータが期待されるデータのみを含むように検証されなかった場合、攻撃者は、ユーザーに次のような悪意のあるバージョンのURLを訪問させることができます。 https://example.com/profile?user<script>some_malicious_code</script>.
レスポンスがブラウザに送信されると、その中には悪意のあるスクリプトが含まれており、ユーザが気づかないうちにブラウザで実行されてしまう可能性が高いのです。 これは、悪意のあるコードがリクエストを行ったユーザーに直ちに「反映」されるため、反射型 XSS 攻撃の例です。
Stored XSS Attacks
Stored または Persistent XSS 攻撃として知られているものでは、ユーザーが Web ページを読み込む際に、サーバーの応答とともに悪意のあるコンテンツを直接配信します。 したがって、コンテンツはすでに Web サイトのデータベースに保存されています (そのため、このような攻撃の名前が付けられています)。 ユーザーは、ハッキングされた Web ページに入るだけで、このような攻撃の犠牲になります。
このように侵害された Web サイトを開いたすべてのユーザーは、個人データを盗まれる危険にさらされるため、これは最も危険なタイプの XSS 攻撃と考えられます。 ほとんどの場合、ユーザー入力が適切に検証およびサニタイズされていない、保護されていない Web ページのフォームから侵入します。 ハッカーが入力したデータが、クライアント側とサーバー側の両方で検証されていない場合、データベースに保存されてしまうのです。 たとえば、そのような入力には、コメント テキスト エリア、投稿テキスト エディタ、個人データ エディタ、またはその他のフォームがあります。
攻撃者がサーバーに不正なコンテンツを送信してそのコンテンツが Web ページにフィルターなしで現れると、すべてのユーザーが犠牲者となる可能性が出てきます。 サニタイズには、データの検証、特殊文字のエスケープ、またはそれらの完全なフィルタリングの組み合わせが含まれ、Web および JavaScript セキュリティの一般的なベスト プラクティスです。
DOMベースのXSS攻撃
Document Object Model (DOM) は、アプリケーションが Web ページの構造、コンテンツ、スタイルを読み込んで操作できるようにするためのインターフェイスです。 DOM ベースの XSS 攻撃では、脆弱性はブラウザ側のスクリプト コードにあり、サーバーとまったくやりとりせずに悪用され、疑うことを知らない犠牲者のブラウザの環境を変更します。
DOM ベースの XSS 攻撃が反射型攻撃と似ていることが時々あります。 上記の反射型 XSS 攻撃の例は、この場合、1 つの仮定で適用することができます。 ウェブ アプリケーションがクエリ文字列から直接データを読み取る。
アプリケーションが、ページの残りの部分の読み込みを待つ間にユーザーの名前を画面に即座に表示するために、クエリ パラメータ「name」を使用したとします。 適切な検証を行わないと、ハッカーが犠牲者に疑わしいリンクを開かせることに成功した場合、反射型攻撃と同じ結果になる可能性があります。
Stored XSS と同様に、反射型攻撃および DOM ベース攻撃を防ぐために、開発者はデータ検証を実装し、サーバーとの通信の有無にかかわらず、生のユーザー入力を表示するのを避ける必要があります。
- <script> タグ。 script タグは、外部の JavaScript コードを参照するために使用することができ、これは最も簡単な XSS ポイントです。 攻撃者は、script タグ内に悪意のあるコードを埋め込むこともできます。
- JavaScript イベント。 攻撃者が使用するもうひとつの一般的なXSSベクトルであるイベント属性は、さまざまなタグで適用することができます。 onerror” や “onload” といった属性がその例です。
- <body> タグ。 イベント属性は、”body” タグを通して提供される場合、スクリプトのソースになることもある。
- <iframe>タグ：使用しているブラウザによっては、この属性はJavaScriptコードを実行するために攻撃者に役立つ場合がある。 特にフィッシング攻撃に有効で、このベクトルにより、XSS攻撃は現在のページに別のHTMLページを埋め込むことができます。
- <input>タグ。 一部のブラウザでは、このベクトルによる操作を許可しており、スクリプトを埋め込むのに使用できる。
- <link> タグを使用。 このタグは、外部スタイルシートへのリンクという通常の使用の代わりに、スクリプトを含むことができる。
- <table>タグ。
- <div>タグ：通常background属性が画像を参照するところ、これは問題のあるスクリプトを参照するように変更される可能性があります。 このタグも背景の参照を含み、<table>と同じ方法でスクリプトを参照するために使用することができる。
XSS攻撃者が情報を盗み、ウェブサイトを危険にさらすために使用する他のベクトルがある一方で、これらは最も一般的に使用される方法のいくつかである。 開発者は、このような攻撃から保護するために、適切なエスケープとサニタイズの実践を順守しなければなりません。
XSS 脆弱性の影響とは？
XSS はアプリケーションと Web サイトに大混乱をもたらす可能性を秘めています。 XSS がすべての OWASP トップ 10 リストに存在しているという事実は、この脆弱性から Web アプリケーションを保護する必要性を示しています。
攻撃者とその悪意に応じて、XSS 攻撃は以下のようなさまざまな影響をもたらします。
- ユーザー セッションを乗っ取り、認証情報を利用して他のサイトにアクセスしたり、意図しない Web サイトにリダイレクトする、
- Web ページを変更したり Web ページにセクションを挿入する、
- Cookie またはデータベースから機密情報を抽出するスクリプトを実行する、
- 被害者に管理権限があれば、攻撃がサーバー側にも及び、さらなる損害を与えるか追加の機密情報を取得する、などです。
How to test Cross-site Scripting?
重要な Web アプリケーションの XSS 脆弱性のテストにおける重要なステップには、
- コード スキャン ツールを使用して脆弱性を検出し、開発プロセス中にコードの修正を可能にすること、
- 自動テスト機能を実装し潜在する脆弱性を徹底的にかつ迅速に明らかにすること、が含まれます。
Test your code for XSS vulnerabilities
Automatically find, prioritize and fix vulnerabilities in the open source dependencies used to build your cloud native applications
What is the Cross-site Scripting example?
クロスサイト スクリプティングは、Web アプリケーションがユーザーの要求に対する応答を作成するために、ブラウザから提供されたデータを使用するときに悪用される可能性があります。 非常に単純な例としては、Web アプリケーションが URL のパラメータを使用して、カスタマイズされたレスポンスをユーザーに提供するような場合があります。
exmple.com/profile に name パラメーターが含まれているとします。 リクエストの URL は https://example.com/profile?user=Tammy のようになります。 Web アプリケーションは、この入力に基づいて、ページの一番上に「Hi Tammy」と応答します。
ユーザー パラメーターが期待されるデータのみを含むように検証されない場合、攻撃者は、ユーザーに次のような悪意のあるバージョンの URL を表示させることができます。 これは、リフレクテッド XSS 攻撃の一例です。 悪意のあるコードは、リクエストを行ったユーザーに即座に「反映」されます。
クロスサイトスクリプティングを防ぐには？ すべての開発者、Webサイトのデザイナー、QAチームが、ハッカーが脆弱性を悪用するために使用する方法を認識し、コーディングのガイドラインとベストプラクティスを提供することを確認します。 これには、アプリケーション環境（JavaScript、HTMLなど）に対する適切なエスケープ/エンコード技術も含まれます。 内部の Web ページであれ、公開の Web サイトであれ、ユーザーの入力データの妥当性を決して信用しないでください。 特に、HTML出力として含まれる場合は、あらゆるデータフィールドをスクリーニングし、検証する。 ベストプラクティスが守られていることを確認し、XSSやその他のOWASPにリストアップされた脆弱性からの露出を最小限に抑えるために、クロスサイトスクリプティングなど、コードの脆弱性をスキャンするソフトウェアを実装します。 コンテンツセキュリティポリシー（CSP）を使用して、Webサイトができることを定義し、これによってXSS攻撃のリスクを低減します。 CSP を使用することにより、XSS は完全にブロックされるか (すべてのインライン スクリプトをブロックすることにより)、はるかに低いリスクに低減されます。
OWASP では、XSS 脆弱性を防ぐ方法に関する追加のガイダンスとして、総合チートシート (cheat sheet) を提供しています。