事例
ある通販サイトの商品検索機能では、利用者が入力した検索語をそのままSQL文に連結して実行していた。攻撃者が検索欄に特殊な文字列を入力したところ、全顧客の個人情報が表示された。
この攻撃が成立した技術的な原因を述べよ。
模範解答を見る
利用者の入力値を検証・無害化せずにSQL文へ文字列連結しており、入力がSQL構文の一部として解釈されたため。
採点キーワード
解説
SQLインジェクション。入力とSQL構造が分離されていないことが根本原因。次設問の対策(プレースホルダ)とセットで覚える。
事例を読んで「原因・対策・対応」を記述する午後問題の練習。 模範解答と採点キーワード付き。キーワードを落とさず短くまとめる訓練をしましょう。
事例
ある通販サイトの商品検索機能では、利用者が入力した検索語をそのままSQL文に連結して実行していた。攻撃者が検索欄に特殊な文字列を入力したところ、全顧客の個人情報が表示された。
この攻撃が成立した技術的な原因を述べよ。
利用者の入力値を検証・無害化せずにSQL文へ文字列連結しており、入力がSQL構文の一部として解釈されたため。
採点キーワード
解説
SQLインジェクション。入力とSQL構造が分離されていないことが根本原因。次設問の対策(プレースホルダ)とセットで覚える。
事例
(前問と同じ通販サイト)
上記脆弱性の根本的な対策を、具体的な実装手法を挙げて述べよ。
プレースホルダ(プリペアドステートメント)を用い、SQL文の構造と入力値を分離して組み立てる。
採点キーワード
解説
エスケープやWAFは補助的対策で漏れやすい。プレースホルダはDB側で値を構造と分離するため根本対策になる。
事例
あるWebアプリは、ログイン前に発行したセッションIDをログイン後もそのまま使い続けていた。攻撃者は事前に用意したセッションIDを利用者に使わせ、利用者がログインした後にそのセッションでなりすました。
この攻撃の名称と、防ぐための対策を述べよ。
セッションフィクセーション攻撃。ログイン成功時にセッションIDを再発行することで防ぐ。
採点キーワード
解説
認証の前後で同じセッションIDを使い回すと、攻撃者が固定したIDで成りすませる。認証成功時の再生成が定石。
事例
経理担当者宛に取引先を装った請求書PDF付きメールが届き、開いた端末がマルウェアに感染、外部のC2サーバと通信を始めた。
被害拡大を防ぐために最初に取るべき対応を述べよ。
感染端末を速やかにネットワークから隔離し、C2サーバとの通信を遮断する。
採点キーワード
解説
初動は封じ込め(隔離)。その後、FW/プロキシのログでC2宛先を特定し、他端末の感染有無を確認、CSIRTへ報告。電源は安易に切らない(揮発情報保全のため)。
事例
自社ドメインを騙る詐欺メールが取引先に送られ、信用が損なわれた。
送信ドメイン認証によるなりすまし対策の仕組みを2つ挙げ、それぞれの役割を述べよ。
SPFは送信元メールサーバのIPが正規かを検証し、DKIMは電子署名でメールの完全性と発信元の正当性を検証する。
採点キーワード
解説
SPF(IP)とDKIM(署名)を、DMARCがポリシー統合し検証失敗時の扱い(隔離/拒否)と報告を定める。3点セットで覚える。
事例
公開Webサーバが内部LANと同一セグメントに設置されており、Webサーバ侵害後に内部のDBサーバへ容易に侵入された。
ネットワーク構成上の問題点と改善策を述べよ。
公開サーバを内部LANと同一セグメントに配置していた点が問題。DMZを設けて公開サーバを分離し、ファイアウォールで内部への通信を必要最小限に制限する。
採点キーワード
解説
公開サーバは侵害前提で内部から隔離する。多層防御・最小権限の通信制御で被害の横展開(ラテラルムーブメント)を抑える。
事例
不正アクセスが疑われたが、Webサーバのアクセスログの保存期間が短く、侵入経路や影響範囲を特定できなかった。
この問題への改善策を述べよ。
ログの保存期間を十分に確保し、改ざんされないよう別サーバ等で集中管理・保全する。あわせて時刻同期を行う。
採点キーワード
解説
追跡可能性(トレーサビリティ)の確保。ログは消える前提で集約し、相関分析(SIEM)できる状態にする。時刻同期がないと突合できない。
事例
あるサイトでは古いTLS設定が残っており、TLS1.0や脆弱な暗号スイートが有効になっていた。
想定されるリスクと対策を述べよ。
弱い暗号は盗聴・解読される恐れがある。TLS1.2以上のみを有効化し、脆弱な暗号スイートを無効化する。
採点キーワード
解説
古いプロトコル/暗号(SSL3,RC4,DES等)は既知の攻撃がある。サーバ設定の定期点検とSSL Labs等での検証が有効。
事例
あるWebサービスでは、URLのパラメータ(?id=)を書き換えると他人の個人情報が閲覧できた。
この脆弱性の原因と対策を述べよ。
リクエストされたリソースがログイン利用者本人の所有かを確認する認可チェックが欠けていたため。サーバ側で利用者とリソースの所有者を照合する。
採点キーワード
解説
安全でない直接オブジェクト参照(IDOR)。画面に出さないだけ(推測可能なID)では対策にならず、サーバ側の認可が必須。
事例
ランサムウェアに感染し基幹システムが暗号化された。バックアップも同じネットワーク上にあったため、同時に暗号化され復旧できなかった。
復旧可能性を高めるためのバックアップ運用上の改善策を述べよ。
バックアップをネットワークから隔離(オフライン/イミュータブル)して保管し、定期的に復旧テストを実施する。
採点キーワード
解説
オンラインのバックアップは同時に暗号化される。隔離保管に加え、実際に戻せるかの復旧訓練まで含めて初めて対策と言える。