＊以下はCheckmarx社によって書かれた下記URLの記事を翻訳したものです。
　https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/

Oct 09, 2017 By Sarah Vonnegut

アプリケーションの脆弱性は、いくつかに分類することができます。非常に一般的ではあるが攻撃者に悪用されても大した被害にはならないもの、極めて珍しいながらも甚大かつ長期的な影響を与える可能性のあるもの、そして一般的であり甚大な被害を及ぼすもの（クロスサイトスクリプティング）です。クロスサイトスクリプティングは、よくXSSと省略して表記され、アプリケーションで検出される最も一般的な脆弱性の1つです。有能な攻撃者は機を見て、この脆弱性を攻撃し深刻な被害をもたらします。

Facebook、 Google、PayPalなどのような人気があり、多くのユーザが利用するアプリケーションであっても、XSS脆弱性は普通に存在します。また、この脆弱性は発見されて以来、常にOWASP Top 10にその名を連ねています。XSS脆弱性の場合、攻撃者に攻撃対象サイトにおいての自由なユーザ操作、パスワードや支払い/財務情報などのユーザ情報の参照を許してしまう点で、特に危険です。これに輪をかけて問題となるのが、ユーザおよび脆弱性のあるアプリケーションの両方において、被害を受けていることに気づかない点にあります。

XSS攻撃では基本的に、アプリケーションを騙しブラウザ経由で悪意のあるスクリプトを送信させます。この時、ブラウザは信頼性のあるWebサイトからこのスクリプトを受け取っていると認識します。エンドユーザが攻撃されたWebページにアクセスするたびに、ユーザが使うブラウザはそのWebページに紛れ込んだ悪意のあるスクリプトをダウンロードして実行します。XSS攻撃の大半において、攻撃者はユーザのCookie情報やセッショントークンを窃取することで、セッションを乗っ取ったり、そこからさらにマルウェアや悪意のあるJavaScriptを拡散したりします。

XSS攻撃に利用できるベクター（経路）がほとんどのアプリケーション内に大量に存在する、その事実がXSS脆弱性対策の難易度を上げています。そのうえ、SQLインジェクションやOSコマンドインジェクションなどの他の脆弱性とは対照的に、XSSはWebサイトを使うユーザにしか影響が及ばないため、その検出と修正はさらに困難となります。また、プリペアドステートメントを用いさせすれば回避できるSQLインジェクションとは異なり、XSS攻撃には決定的な解決法となる基準や対策がありません。

XSS攻撃は、大きく2つに分けられます。1つは蓄積型（または持続型）XSS攻撃で、脆弱性のあるアプリケーションに直接悪意のあるスクリプトを埋め込みます。もう1つは反射型XSS攻撃といい、Webページのリンクなどに悪意のあるスクリプトを埋め込み、このリンクをエンドユーザにクリックさせて攻撃を仕掛けます。

XSS攻撃の詳細についてはこちらを参照してください。

XSS対策: XSS攻撃からアプリケーションを守る3つの方法

前のセクションではXSS攻撃や、この攻撃によってアプリケーションが受ける被害について簡単に説明しました。これ以降のセクションでは、同攻撃の対策として取り挙げられるベストプラクティスについて記述します。

1. エスケープ処理

アプリケーションにXSS脆弱性を作り出さないために使用すべき1つめの手法は、ユーザの入力情報に対するエスケープ処理です。データのエスケープ処理とは、アプリケーションが受け取ったデータを確実にセキュアな状態にしてからエンドユーザにレンダリングすることを意味します。ユーザの入力情報をエスケープ処理することで、Webページが取得したデータに存在する記号が間違ってプログラムコードとして解釈されないようにします。つまり、Webページが取得したデータを検査し、そのままの状態でレンダリングするとアプリケーションやユーザに被害が及ぶ可能性のある記号（特に < および >）を修正するのです。

ユーザが独自のコードをWebページに追加できない場合は、HTML、URLおよびJavaScriptエンティティすべてをエスケープ処理することが簡単な方法です。フォーラムやコメントの投稿など、ユーザがリッチテキストを追加できるWebページの場合は、エスケープ処理の方法を選ぶ必要が出てきます。エスケープ処理するHTMLエンティティと処理しないものを慎重に選り分けるか、MarkdownなどHTMLの元データに対して正規表現を使ってからHTMLすべてをエスケープ処理する方法です。

2. 入力情報の検証

Troy Hunt氏は、次のように述べています。『信頼性のないデータはすべて悪意のあるものとして捉えます。では、信頼性のないデータとは何でしょうか？これは、システムの外部で生成され自分では完全には制御できないデータで、フォームデータ、クエリ文字列、Cookie、他のリクエストヘッダ、別のシステム（例： Webサービス）から取得した情報、要するに悪意のある情報が含まれていない、と100%断言できないものすべてです』

入力情報の検証とは、必ずアプリケーションが正しいデータをレンダリングし、悪意のあるデータによってWebサイト/データベース/ユーザに被害が生じないようにすることです。ホワイトリストと入力情報の検証はSQLインジェクションの対策として広く使われていますが、XSS攻撃を回避する手法の1つとして使うこともできます。ブラックリストなどユーザの入力情報に対してあらかじめ定義された特定の文字の使用を拒否する手法は、既知の危険な文字しか排除することができませんが、これとは逆にホワイトリストでは、あらかじめ定義された安全な文字の使用だけを許可するので、他の攻撃のみならずXSS攻撃を防ぐための優れた手法といえます。

入力情報の検証ではリクエストを拒否することなく、ユーザによってフィールドに特殊文字が追加されることを防ぐことから、フォームでXSSを防ぐ際には特に便利で有効です。OWASPで主張されているとおり、入力情報の検証はXSSやSQLインジェクションなどの脆弱性における主な回避策とはなりませんが、攻撃者によってそのような脆弱性を悪用された場合には、その影響を軽減することができます。

3. 危険なコードの除去

XSS攻撃を防ぐ3つめの方法は、ユーザの入力情報における危険なコードの除去です。データから危険なコードを取り除くことは強力な防御策となりますが、これだけを用いてXSS攻撃に対処すべきではありません。よりセキュアなアプリケーションを開発するために、3つすべての回避策を使う必要性を感じることは大いに考えられます。ユーザの入力情報における危険なコードの除去は、HTMLマークアップが使えるWebサイトにおいてとりわけ有用です。この方法では、潜在的に危険なマークアップを取りの除き、不適切なユーザの入力情報を適切なフォーマットに変換することで、Webサイトが受け取ったデータによってデータベースのみならずユーザにも被害が及ばないようにします。

まとめ

上述したようなセキュリティ対策をいくつか組み合わせて実装することは、大半のXSS攻撃に対処するための優れた方法といえます。ただし、前述の回避策を用いることでほとんどのXSS攻撃ベクターに対応することはできますが、あらゆるものに対応できるわけではない点を肝に銘じることが重要です。XSSやOWASP Top 10に挙がるような他の脆弱性に対して注意深くあるためには、まずXSSのような脆弱性の回避に役立つセキュアなコーディングを実践することはもちろんのこと、開発時にはコードレビューおよび自動化された静的解析を、アプリケーションの稼働後には動的テストを併用することが大切です。

参考情報

• OWASP XSS Prevention Cheat Sheet
• OWASP XSS Filter Evasion Cheat Sheet
• Understanding XSS（Troy Hunt氏のBlog）
  
   

Sarah Vonnegut

Checkmarx社でソーシャルメディアを担当しながら、コンテンツチームで編集とライターを兼務。知名度の低いアプリケーションセキュリティの問題に光を当て、コンテンツを通し、このセキュリティリスクに溢れた世界でハッカーの常に先をゆく重要性を企業のセキュリティ担当者に訴えていく努力を続けている。