Webアプリの攻撃リスクとは — 入力・認可・セッションを防御側で確認

Webアプリのリスクを防御側から理解する

Webアプリの安全性は、ログインできるかだけでは決まりません。入力の処理、データや操作の許可、セッション、外部サービスへの依存が関係します。本ページは、開発者・情シスが原因の確認と修正へ進むための教材です。実サイトへの攻撃、ペイロード、認証回避の再現は扱いません。

OWASP Top 10:2025で主要リスクを把握し、ASVSなどで対象機能の検証要件を決めます。

• 入力・出力

  データを命令へ連結しない。出力先の文脈に合う処理を使う。

• 認可

  ログイン済みでも、データ・操作ごとの権限をサーバーで確認。

• セッション

  Cookieの属性、失効、復旧、変更時の扱いを確認。

SQLインジェクション・XSS・CSRFの違い

リスク	問題となる境界	防御側の主な確認
SQLインジェクション	入力データとDBへの命令	パラメータ化などの安全なAPI。動的な識別子は許可リスト等で別に管理
XSS	データとブラウザが解釈する内容	文脈に合う出力エンコード、安全なDOM API、必要に応じたサニタイズ
CSRF	利用者の意図と認証済みの要求	状態変更の設計、CSRFトークン、Origin確認、SameSite等を要件に合わせる
アクセス制御の不備	認証された利用者と許可された操作	サーバー側で対象・操作・役割ごとに認可を確認

「入力を消毒する」「WAFを設置する」という一つの対策で、すべてを解決できるわけではありません。例えば、パラメータ化でSQLの値を分離しても、動的に作るテーブル名の扱いや認可は別に確認します。

開発レビューのチェックリスト

• 入力の利用先を追い、データと命令が混ざっていないか確認する。
• 出力先がHTML、属性、URL、JavaScriptなどどの文脈か確認する。
• 画面でボタンを隠すだけでなく、サーバー側で認可を検証する。
• Cookie・セッションの設定、失効、権限変更時の扱いを確認する。
• エラー時に認証・認可を無条件に通さないか確認する。
• エラー画面・ログへ秘密情報を不用意に出さない。
• 依存関係、フレームワーク設定、更新状態を確認する。

CSPを追加する時は、Report-Onlyによる影響確認と強制用ポリシーを区別します。connect-srcは通信先の制限であり、APIの認可は代替しません。GraphQLではフィールド認可とクエリコスト分析を分けて検討すると、機密性と可用性の確認が整理できます。

疑わしい挙動があった時の初動

アラートだけで侵害成功と断定しません。対象機能、発生時刻、受信した要求の記録、応答、変更履歴、対象アカウントを確認します。正規の監視・管理作業との照合も必要です。

不正な閲覧や変更が疑われる場合は、責任者へ報告し、アクセス制限・機能停止・セッション失効を影響とともに判断します。証跡保全と封じ込めは並行して進めます。確認のために実データを取得したり、疑わしい要求を本番へ再送したりしません。

修正後の確認と記録

記録するのは対象機能、確認根拠、影響と未確認事項、原因、修正、担当者、承認、再確認結果です。入力内容に個人情報や秘密がある場合は、共有前に取り扱いを確認してください。

修正後は、期待した制御が働くことと、正規利用が壊れていないことの両方を確認します。検証は許可された範囲の合成データで行い、監視も続けます。

認証と認可、Burp Suiteの取得済み通信の読み方、OWASP Top 10、インシデント対応へ進めます。