×
サイバー攻撃について

XSSを「3種類の暗記」で終わらせず、Source、Sink、コンテキスト、実行場所、保存性を組み合わせて分析することが重要です。


FAQ

Q1. 最低限覚えるべきXSSは何ですか

最初は次の3つを覚えます。

  • Reflected XSS

  • Stored XSS

  • DOM-based XSS

その後、Server/Clientの分類を重ねると理解しやすくなります。


Q2. DOM XSSはサーバーのログに残りますか

必ずしも残りません。

location.hashは通常、HTTPリクエストとしてサーバーへ送信されません。

そのため、URLフラグメントだけで成立するDOM XSSは、サーバーやWAFから見えない場合があります。


Q3. Djangoを使えばXSSは起こりませんか

起こる可能性があります。

Djangoテンプレートは多くの入力を自動エスケープしますが、次の構成には注意が必要です。

  • safe

  • mark_safe

  • autoescape off

  • 引用符のない属性

  • JavaScriptへ直接埋め込む

  • innerHTML

  • Markdown

  • 利用者アップロード

  • WebSocket

  • 管理画面でのログ表示

Django公式ドキュメントも、自動保護には限界があると説明しています。


Q4. Reactなら安全ですか

通常の文字列描画はエスケープされます。

ただし、次の処理では注意が必要です。

  • dangerouslySetInnerHTML

  • 外部URL

  • 古い依存ライブラリ

  • DOM APIの直接利用

  • MarkdownやHTMLレンダラー

  • Script Gadget

OWASPも、フレームワークの安全機能を迂回するAPIを注意点として挙げています。


Q5. XSSの修正は入力チェックだけで十分ですか

十分ではありません。

入力検証、出力エンコード、安全なDOM API、HTMLサニタイズ、CSP、Trusted Typesを組み合わせます。


Q6. CSPでXSSを完全に防げますか

完全ではありません。

設定不備、許可済みスクリプト、Script Gadget、ブラウザー差異などがあります。

CSPは根本修正の代わりではありません。


Q7. Trusted Typesを入れればServer XSSも防げますか

Trusted Typesは、主にクライアント側の危険なInjection Sinkを制御します。

W3C仕様では、サーバー生成マークアップへの注入を直接防ぐことは非目標として示されています。Server XSSには、テンプレートの自動エスケープやコンテキスト別の出力処理が必要です。


Q8. SOC画面に攻撃文字列を表示しても大丈夫ですか

未エスケープ表示は危険です。

URI、User-Agent、Referer、攻撃ペイロードは、必ずプレーンテキストとして表示してください。


参考情報


2026年7月30日追記:サイト全体のXSS監査と改善

この記事の公開前、記事機能だけでなく、サイト全体を対象にクロスサイトスクリプティング対策を再点検しました。サーバー側テンプレート、ブラウザー側DOM操作、リッチHTML、画面へ埋め込むJSON、リアルタイム通信、管理・通知系の表示経路を横断して確認しています。

今回実施した主な改善

  • リッチHTMLを扱う機能では、許可リスト型のサニタイズを保存時と表示時の両方へ適用しました。
  • HTML内へJSONを渡す処理を、script要素を安全に閉じ込める共通シリアライズ方式へ変更しました。
  • APIレスポンスからDOMを組み立てる画面では、文字列をHTMLとして連結せず、値のエスケープとURL制限を行うよう見直しました。
  • 過去に保存されたデータも、安全化してから表示されるよう互換対策を追加しました。

確認したXSSの観点

反射型、格納型、DOM型に加え、Second-order、Blind、SVG・MathML、危険なURLスキーム、イベント属性、iframe/srcdoc、CSS、JSON埋め込み、WebSocketなどの経路を確認しました。安全確認には実害のない検証用データを使用し、外部送信や認証情報取得を行うコードは使用していません。

防御は一つに依存しない

今回の改善では、出力コンテキストに応じたエスケープ、HTMLサニタイズ、安全なDOM API、セキュリティヘッダー、回帰テストを組み合わせています。CSPやWAFだけに依存せず、信頼できないデータが実行可能なSinkへ到達しない設計を優先しています。

なお、この追記では悪用可能な入力例、非公開URL、内部構成、検知回避につながる具体的手順は掲載していません。セキュリティ対策は継続作業であり、機能追加時にもSourceとSinkの追跡、依存ライブラリ更新、回帰テストを続けます。