XSSとは｜エスケープしたのに javascript: が残っていた

XSSでは何が起きているのか

起きているのは、書き込まれた文字がHTMLの一部として読まれることです。文字を表示する欄が、そのまま部品を追加できる欄になってしまいます。

XSSは、利用者が書いた内容を画面に出すときに、それが文字ではなくHTMLとして解釈されることで起きます。コメント欄や名前の表示など、入力をそのまま出す場所が対象になります。

普通のコメントでは何も起きない

「こんにちは」と書き込まれた場合、画面にはその文字が出るだけです。ここまでは意図した動きで、問題はありません。

タグを書かれると、部品として組み込まれる

ところが <img src=x onerror=alert(1)> のような文字列を書き込まれると、ブラウザはこれを画像の指定として読みます。画像の読み込みは失敗しますが、失敗したときに動く処理の部分が実行されます。

この例では警告を出すだけですが、同じ場所で他の処理も書けます。ログイン状態を保つ情報を盗む、勝手に操作を実行する、といったことが他の利用者のブラウザ上で起こります。

OWASPは、変数をHTMLの中に安全に入れるには、その変数にHTMLの実体参照への変換を行うよう示しています。つまり< を < のような別の表記に置き換えて、タグとして読まれないようにします。

エスケープしたのに、javascript: が残っていた

同じ入力を本文・属性・URLの3か所に埋めて試しました。本文と属性は変換で無害になりましたが、URLだけは通り抜けます。

XSSの対策は「エスケープすれば終わり」と説明されがちですが、実際に3か所へ埋めて出力を見比べました。

下のコードは読み飛ばして大丈夫です。やっていることは、同じ変換関数を3か所に使っただけです。

const escapeHtml = (s) =>
  String(s).replace(/[&<>"']/g, (c) => ({
    '&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#39;'
  })[c]);

const renderSafe     = (v) => `<div class="comment">${escapeHtml(v)}</div>`;
const renderAttrSafe = (v) => `<img src="/avatar.png" alt="${escapeHtml(v)}">`;
const renderHrefEscaped = (v) => `<a href="${escapeHtml(v)}">プロフィール</a>`;

// URLはスキームを確かめる。変換では javascript: を止められない
const renderHrefSafe = (v) =>
  /^https?:\/\//i.test(v) ? `<a href="${escapeHtml(v)}">プロフィール</a>`
                          : '<a href="#">（不正なURL）</a>';

--- 入力をHTML本文に埋める ---
  対策なし: <div class="comment"><img src=x onerror=alert(1)></div>
  エスケープあり: <div class="comment">&lt;img src=x onerror=alert(1)&gt;</div>
--- 同じ入力を属性値に埋める ---
  エスケープあり: <img src="/avatar.png" alt="&lt;img src=x onerror=alert(1)&gt;">
--- URLとして javascript: を渡す ---
  エスケープのみ: <a href="javascript:alert(1)">プロフィール</a>
  スキームも確認: <a href="#">（不正なURL）</a>

残りました。href の中身が javascript:alert(1) のままです。エスケープ関数は通っているのに、変換すべき文字が1つも含まれていないので、何も変わらずに出てきました。

なぜURLだけ通り抜けるのか

変換が守っているのは「文字がタグとして読まれること」だけだからです。javascript:alert(1) には山括弧も引用符も入っていません。文字としては完全に無害で、危険なのは行き先そのものです。

つまりURLについては、文字を無害にする処理ではなく、行き先が許されるものかを確かめる処理が要ります。上のコードでは、先頭が http:// か https:// であることだけを条件にしています。

場所ごとに考える

OWASPのチートシートも、信頼できないデータをさまざまな場所で安全に描画する方法として、場所ごとに分けて示しています。1つの変換関数で全部を守る、という発想にならないよう作られています。

1. HTML本文: 実体参照への変換を行う。多くのフレームワークは自動で行う
2. 属性値: 変換に加えて、値を必ず引用符で囲む。囲まないと属性を足される
3. リンク先URL: 先頭が http:// か https:// かを確認する。変換だけでは不十分
4. HTMLをそのまま挿入する箇所: 専用の除去ライブラリを使う。自作しない

自分のアプリのどこを確認すればいいのか

確認は2種類です。コメント欄にタグを入れて表示が崩れないか。URL欄に javascript: を入れて弾かれるか。この2つで大半が見つかります。

XSSの確認に特別な道具は要りません。実際に入力してみるのが確実です。ただし入れる値と見る場所を分けて考える必要があります。

確認1: 本文にタグを入れる

1. コメント欄や名前の欄に <img src=x onerror=alert(1)> を入れて保存する
2. 表示された画面で、文字としてそのまま見えるかを確かめる
3. 壊れた画像の枠が出たり、警告が出たりしたら、その時点で穴がある

確認2: URL欄に javascript: を入れる

1. プロフィールのURL欄など、リンクになる入力欄を探す
2. javascript:alert(1) を入れて保存する
3. 保存できてしまい、そのリンクを押して警告が出たら穴がある

この2つ目が、前の節で通り抜けたパターンです。本文の対策だけ済ませて安心している場合に見つかります。

防御ツールに任せきりにしない

通信を監視して攻撃を弾くしくみ（WAF）もありますが、OWASPはXSSの防止にWAFは勧められないと明記しています。特に、ブラウザ内だけで完結する種類のXSSには効きません。

入力を信用しないという点ではSQLインジェクションの記事と同じ構図です。あちらは入力がSQLの命令として読まれる問題で、こちらは入力がHTMLとして読まれる問題です。