Web アプリケーションセキュリティ

第22章. XSS攻撃からの防御

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

パートIIでは、 ユーザ・デバイス上でJavaScriptコードを実行するブラウザの機能を利用したXSS攻撃について深く考察した。XSSの脆弱性は、スクリプト実行の脆弱性が潜在的な被害の幅を持つように、広範囲に広がっており、大きな被害をもたらす可能性がある。

幸いなことに、XSSはウェブに頻繁に現れるが、セキュアコーディングのベストプラクティスとXSS特有の緩和テクニックによって、完全に緩和したり防いだりすることは非常に簡単だ。この章では、あなたのコードベースをXSSから守るためのすべてを紹介する。

アンチXSSコーディングのベストプラクティス

XSS脆弱性に遭遇する確率を劇的に軽減するために、開発チームに実装できる主要な規則がひとつある：「文字列を除き、ユーザから与えられたデータをDOMに渡さないこと」だ。

多くのアプリケーションは、ユーザからDOMへのデータ転送を組み込む機能を持っているため、このような規則はすべてのアプリケーションに適用できるわけではない。この場合、この規則をより具体的にすることができる。"ユーザから提供されたデータがサニタイズされていない状態でDOMに渡されることを決して許してはならない"。

ユーザが提供するデータをDOMに入力できるようにすることは、最初の選択肢ではなく、予備的な、最後の選択肢であるべきだ。そのような関数は、誤ってXSS脆弱性につながるので、他のオプションが利用可能な場合は、それを最初に選択すべきである。

ユーザから提供されたデータをDOMに渡さなければならない場合、可能であれば文字列として渡すべきである。つまり、HTML/DOMが要求されず、ユーザが提供したデータがテキストとして表示されるためにDOMに渡される場合は、ユーザが提供したデータがDOMではなくテキストとして解釈されるようにしなければならない（図22-1参照）。

図22-1. ほとんどのXSSは（すべてではないが）、ユーザが提供したテキストが不適切にDOMに注入された結果として発生する。

クライアント、サーバの両方で、さまざまな方法でこれらのチェックを行うことができる。

まず、文字列の検出はJavaScriptではとても簡単だ：

const isString = function(x) {
  if (typeof x === 'string' || x instanceof String) {
    return true;
  }
  return false;
};

残念ながら、このチェックは数値のチェックでは失敗する。数値はDOMへのインジェクションでも安全なので、このエッジケースを扱うのは厄介だ。

文字列と数値を「文字列のような」オブジェクトに分類することができる。文字列のような」オブジェクトは、JSON.parse() の比較的知られていない副作用を使って評価することができる：

const isStringLike = function(x) {
  try {
     return JSON.stringify(JSON.parse(x)) === x;
  } catch (e) {
    console ...