ウェブアプリケーションセキュリティ 第2版

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

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

第10章では、ブラウザがユーザ端末上でJavaScriptコードを実行できることを利用した、 XSS攻撃について深く考察した。スクリプト実行の脆弱性は潜在的な被害の幅が広いため、XSS脆弱性は広範に存在し、多大な被害をもたらす可能性がある。

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

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

、XSS脆弱性に遭遇する確率を劇的に軽減するために開発チームに実装できる主要な規則として、「文字列を除き、ユーザが提供するデータをDOMに渡さない」というものがある。

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

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

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

図28-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.log('not string-like' ...