バックエンド実装系の攻撃と対策

攻撃視点の分類 → セキュリティ脅威マップ ／ レイヤーC「クラウドとアプリ実装」

Webサービスの裏側（データベースやサーバ処理）の作りの甘さを突いて、情報をまとめて抜き取る 攻撃の総称。利用者が見ているのは画面（表側）だけだが、その裏では「入力を受け取り、データベースに問い合わせ、結果を返す」処理が動いている。この裏側の作りが甘いと、本来見えないはずの情報が一気に漏れる。利用者からは見えないところで起きるぶん、気づきにくく被害も大きい。

このページの読み方 — 🟢 は全員が知っておく基礎、🔧 はエンジニア・運用担当者向けの実装/設定。このジャンルは “作る人”の対策が中心なので、🟢でできることは少なく 🔧が主役。技術担当はここをしっかり押さえる。

1. このジャンルの攻撃とは

利用者が入力したデータ（検索ワード、ログイン情報、URLのID、ファイル名など）は、サーバの裏側でデータベースへの命令やOSへの命令に組み込まれて処理される。攻撃者はこの 「入力 → 命令に組み込む」つなぎ目の甘さ を突いて、

  • 本来見えないデータをまとめて読み出す（会員情報・パスワード・カード情報など）
  • 他人の権限になりすまして操作する（チェック漏れを利用）
  • サーバそのものを乗っ取って踏み台にする

ことを狙う。共通する原因は 「利用者の入力を信用しすぎる」「権限チェックを画面側だけで済ませる」 こと。攻撃の本体は派手なハッキングではなく、設計・実装の小さな抜け であることがほとんど。

2. 主な手口

手口 しくみ（何が起きているか）
SQLインジェクション 入力欄に細工した文字でデータベースを不正操作。検索やログインの命令文に攻撃者の文字列が混ざり、会員情報を全部読み出されたり認証を素通りされる
認証・認可の不備（IDOR） URLのID書き換えで他人のデータが見える権限チェック漏れ。?id=123 を 124 に変えるだけで他人の情報が表示される
権限昇格 一般利用者が、管理者だけが使えるはずの機能やデータに到達できてしまう（役割チェックの抜け）
SSRF サーバを踏み台に内部へアクセス。「この画像URLを取得して」等の機能を悪用し、外からは触れない社内システムやクラウドの管理情報を読み出す
コマンドインジェクション サーバに勝手に命令を実行させる。入力をOSコマンドに組み込む処理を突かれ、ファイル閲覧やサーバ乗っ取りに至る
安全でないデシリアライズ 保存・送信したデータ（オブジェクト）を復元する処理を悪用され、復元のついでに不正なコードを実行される
認証バイパス ログイン処理の作りの甘さ（推測できるトークン、チェック忘れの裏口API）で、ログインせずに中に入られる
情報漏洩（詳細すぎるエラー・ディレクトリ露出） エラー画面に内部の作り（テーブル名・パス・バージョン）が出てしまう／ファイル一覧が丸見えで、攻撃のヒントを与える
APIの認可不足・レート制限なし 画面を経由しない裏のAPIに認証・権限チェックが無い／何度でも叩けるため、データ総取りや総当たり攻撃を許す

3. 実例・典型シナリオ

  • 入力欄に細工で会員情報が全部抜ける（SQLインジェクション）: 検索やログインの入力に ' OR '1'='1 のような細工を入れると、データベースが「条件が常に成立」と解釈し、本来1件も返さないはずが 会員テーブルを丸ごと吐き出す。
  • URLのIDを変えると他人の情報が見える（IDOR）: マイページのURLが mypage?user=1001。これを 1002 に変えるだけで、他人の住所・注文履歴が表示される。画面にボタンが無くても、URLを直接叩けば見えてしまうのがポイント。
  • サーバに任意コマンドを実行される（コマンドインジェクション）: ファイル変換や ping 機能などで、利用者の入力をそのままサーバのコマンドに渡していると、; rm -rf のような追加命令を紛れ込ませてサーバを操作される。
  • 内部APIを踏み台にされる（SSRF）: 「URLを指定すると内容を取りに行く」機能に、http://169.254.169.254/...（クラウドの内部管理アドレス）を入れられ、外部からは絶対に触れないはずのアクセスキーを盗まれる。

4. 対策

🟢 基礎（全員がやること）

  1. 利用者側でできることは少ない — この領域は構造上 作る人（開発・運用）の対策が中心。利用者ができるのは「兆候に気づいて止める・伝える」こと。
  2. 不審な挙動を見たら使用を止めて報告 — 「他人の情報が表示された」「自分のIDでないデータが見えた」「エラー画面に見慣れない英語の内部情報が出た」ら、操作を続けず すぐ運営・管理者に報告。
  3. 見えてしまった情報を悪用しない・拡散しない — たまたま他人のデータが見えても、保存・共有しない。発見はバグ報告として正規の窓口へ。

🔧 応用（エンジニア・運用）

  1. プリペアドステートメント／ORM を使う（SQLインジェクション対策） — 命令文と値を分離し、入力を「値」としてしか扱わせない。文字列連結でSQLを組み立てない。これが最も確実で根本的な対策。
  2. サーバ側の認可チェックをオブジェクト単位で — 「ログイン済みか」だけでなく 「このデータをこの人が見てよいか」 を、リソース（注文・ファイル・ユーザ）ごとに毎回サーバ側で確認。画面でボタンを隠すだけは対策にならない（IDOR/権限昇格対策）。
  3. 入力検証と出力エンコード — 入力は型・長さ・形式を検証（許可リスト方式）。出力時は出力先（HTML/SQL/OSコマンド）に応じて適切にエスケープ・エンコードする。
  4. DBユーザは最小権限 — アプリが使うデータベースアカウントに、不要な削除・管理権限を与えない。万一突破されても被害範囲を限定できる。
  5. SSRF対策（宛先の許可リスト・クラウドメタデータ保護） — サーバが外向きにアクセスする宛先を 許可リストで限定し、内部アドレスやクラウドのメタデータ用アドレス（例: 169.254.169.254）へのアクセスを遮断。
  6. OSコマンド実行を避ける／無害化 — できる限りOSコマンドを呼ばず、言語標準のライブラリで処理する。やむを得ない場合は引数を配列で渡し、シェルを経由させない・入力をそのまま渡さない（コマンドインジェクション対策）。
  7. 詳細エラーを利用者に出さない — 例外の中身（テーブル名・パス・スタックトレース）は内部ログにだけ記録し、利用者には汎用メッセージを返す。ディレクトリ一覧表示も無効化する。
  8. WAF とレート制限 — Webアプリケーションファイアウォール（WAF＝攻撃的なリクエストを入口で弾く仕組み）で既知の攻撃を低減し、API・ログインにレート制限をかけて総当たり・データ総取りを抑える。あくまで根本対策（1〜7）の上乗せとして使う。
  9. APIの認証・認可徹底 — 画面を経由しない裏のAPIにも、画面と同じ強度の認証・権限チェックを必ず適用。「内部だから」「画面に出していないから」を理由に省略しない。

5. 解説動画（実在確認済み）

バックエンド実装に特化したIPA公式動画は確証が取れないため、特定動画は埋め込まず、信頼できる公式ページへのリンクのみを案内します。

※ より実務寄りに学ぶなら、下の「出典」にある OWASP Cheat Sheet Series と IPA「安全なウェブサイトの作り方」が定番。手口ごとに具体的な対策コードまで載っている。

6. チェックリスト

🟢 全員

  • 「他人のデータが見えた」など不審な挙動に気づいたら使用を止めて報告する先を知っている
  • 見えてしまった他人の情報を保存・共有・悪用しない
  • エラー画面に見慣れない内部情報が出たら運営に伝える、と理解している

🔧 エンジニア・運用

  • DBアクセスはプリペアドステートメント／ORM に統一し、SQL文字列連結を排除した
  • すべての画面・APIで、リソース単位（オブジェクト単位）の認可チェックをサーバ側で実施している
  • 入力検証（許可リスト）と出力エンコードを各出力先ごとに行っている
  • アプリ用DBユーザを最小権限に絞っている
  • SSRF対策（外向き宛先の許可リスト、クラウドメタデータ・内部アドレスの遮断）を入れている
  • OSコマンド実行を避ける／引数を無害化し、シェルを経由させていない
  • 詳細エラー・スタックトレースを利用者に出さず、ディレクトリ一覧表示を無効化している
  • WAFとレート制限（ログイン・API）を有効化している
  • 裏のAPIにも画面と同等の認証・認可を適用している

7. 関連ジャンル・出典

関連ジャンル

出典（一次情報）

  • OWASP「Top 10」 — https://owasp.org/www-project-top-ten/（Webアプリの代表的弱点）
  • OWASP「Cheat Sheet Series」 — 手口別の具体的な実装対策ガイド（SQLi/認可/SSRF/デシリアライズ など）
  • IPA「安全なウェブサイトの作り方」 — https://www.ipa.go.jp/security/vuln/websecurity.html（日本語の定番。脆弱性ごとに対策を解説）
  • MITRE ATT&CK — 攻撃手口のカタログ（応用・実務向け）

合わせて読む