反射XSS — 攻めて、直して、再検証する

穴のある場所を読む

shanai-memo の検索は、vulnerable/server.mjs の /search にあります。該当部分はここです。

if (pathname === '/search') {
  const q = url.searchParams.get('q') || '';
  const hits = notes.filter((n) => n.title.includes(q) || n.body.includes(q));
  res.end(
    page(
      '検索',
      `<h1>検索</h1><p>「${q}」の検索結果: ${hits.length}件</p>` + // ← ここが穴
        ...

q(利用者が検索欄に入れた文字列)を、何の加工もせずに HTML の文字列へ連結しています。q に <img> タグを入れれば、それはタグとして解釈されます。

攻める

2つ目のターミナルで、参照エクスプロイトを走らせます。

cd sec-web-basics
node exploit/xss.mjs

[XSS] 成立: ペイロードが未エスケープで反射されました(HTMLとして解釈される)

このエクスプロイトは、次のようなペイロードを /search?q=... に送っています。

<img src=x onerror="document.title=String.fromCharCode(88,83,83)">

src=x の画像は必ず読み込みに失敗するので、onerror に書いた JavaScript が動きます。手で確かめるなら curl でも見えます。

curl -s "http://127.0.0.1:4599/search?q=%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E"

返ってきた HTML の中に、送ったタグがそのままの形で入っています。

<p>「<img src=x onerror=alert(1)>」の検索結果: 0件</p>

< が < になっていない——つまりブラウザはこれをタグとして解釈します。これが反射XSSの発火点です。実際の攻撃では、この URL を別の利用者に踏ませることで、その人のブラウザで任意のスクリプトを動かします。

直す

直し方の芯は一つ。HTMLに出す前に、エスケープする。&<>"' を実体参照(& < など)に置き換えれば、入力は「タグ」ではなく「ただの文字」として表示されます。

vulnerable/server.mjs の先頭近く(page 関数の前)に、エスケープ関数を足します。

function escapeHtml(s) {
  return String(s)
    .replace(/&/g, '&')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#39;');
}

そして /search の穴の行を、q をエスケープしてから埋め込む形に変えます。

`<h1>検索</h1><p>「${escapeHtml(q)}」の検索結果: ${hits.length}件</p>` +
'<ul>' +
hits.map((n) => `<li>${escapeHtml(n.title)}</li>`).join('') +

再検証する

サーバを止めて(1つ目のターミナルで Ctrl+C)、もう一度起動します。そして同じエクスプロイトを走らせます。

node exploit/xss.mjs

[XSS] 防御されています: ペイロードはエスケープされ、コードになりません

curl で見ると、今度は < が < になっています。

<p>「&lt;img src=x onerror=alert(1)&gt;」の検索結果: 0件</p>

同じ入力が、タグではなく文字として表示されるようになりました。「成立」が「防御されています」に変わった——これが攻撃 → 修正 → 再検証の一周です。

持ち帰る一言

入力は信じない。出す前に、出す文脈に合わせて整える。 ここではHTMLに出すのでHTMLエスケープでした。文脈がURL属性やJavaScript内なら、必要なエスケープは変わります。「どの文脈に出すか」を意識するのが、XSS対策の芯です。