【入門編】Trusted Types APIによるDOMベースXSSの根本的根絶 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは!セキュリティの世界へようこそ。私は普段、企業の守りを固めるエンジニアとして現場を奔走していますが、今日は皆さんと一緒に、Web開発における「永遠の課題」とも言えるXSS(クロスサイトスクリプティング)を、「Trusted Types」という最強の武器を使って根本から撲滅する方法についてお話しします。

「XSS?なんだか難しそう…」と思うかもしれませんが、大丈夫です。身近な防犯に例えながら、一歩ずつ紐解いていきましょう。

—

1. XSSは「偽造されたマスターキー」を渡す泥棒

まず、XSSの正体をイメージしてみましょう。皆さんのWebサイトを「大切なお家」、ブラウザを「玄関のドア」だと想像してください。

本来、玄関の鍵は持ち主(開発者)だけが持っているべきですよね。しかし、XSSは悪意ある攻撃者が、「この鍵を使って中に入っていいよ」と、あなたのWebサイトを通じてユーザーのブラウザに偽の鍵を渡してしまう攻撃なんです。

  • 反射型: 攻撃者が仕掛けたリンクをユーザーがクリックした瞬間、偽の鍵が渡される。
  • 格納型: Webサイトの掲示板などに偽の鍵を書き込み、それを見た全員が被害に遭う。
  • DOM型: サイト内で動くプログラムそのものが騙され、自分自身で偽の鍵を作ってしまう。

特に「DOM型」は、JavaScriptがURLのパラメータなどをそのまま画面に表示してしまうことで発生します。これが現代のWeb開発で非常に厄介な「盲点」なんです。

—

2. 危険な「シンク」という名の勝手口

JavaScriptには、文字列をHTMLとして書き込んでしまう危険な関数があります。これをセキュリティ業界では「シンク(Sink:流し台)」と呼びます。

// 危険な例:ユーザーが入力した文字を、そのままHTMLとして画面に流し込む
const userContent = new URLSearchParams(window.location.search).get(“name”);
document.getElementById(“output”).innerHTML = userContent;

このinnerHTMLというシンクは、「渡されたものは何でもHTMLとして解釈して実行しちゃう」という、非常に大雑把な性格なんです。ここに攻撃者がなんて呪文を放り込むと、ブラウザは「おっ、これは実行しなきゃ!」と騙されてしまいます。

これが、まさに「勝手口を開けっ放しにしている状態」です。

—

3. Trusted Typesで「身元保証人」を立てる

ここで登場するのが、今回の主役「Trusted Types」です。これは、シンクに対して「俺が確認した、安全な文字列しか通さんぞ!」というガードマンを配置する仕組みです。

Trusted Typesを有効にすると、ブラウザはinnerHTMLのような危険なシンクに「ただの文字列」を渡すと、「おい!身元が確認できない(型が違う)やつは通せねえ!」とエラーを吐いて止めてくれるようになります。

具体的な実装ステップ

まずは、安全なオブジェクトを作るための「ポリシー」を定義します。

// セキュリティポリシーを定義
const policy = trustedTypes.createPolicy(‘my-policy’, {
createHTML: (input) => {
// ここで危険なタグを消したり、サニタイズ(消毒)を行います
return input.replace(/

シェアする
securityintronationalをフォローする

コメント

タイトルとURLをコピーしました