情報処理安全確保支援士試験、特に午後問題の合否を分けるのが、アプリケーション、Web、データベースのセキュリティ知識です。セキュア開発プロセスやテストに関する理解も問われるこの分野は、単なる知識の暗記だけでは対応が難しく、「Webシステムの設計・運用」といった実務シナリオで応用力が試されます。しかし、多くの受験者が専門用語の多さや攻撃手法の複雑さにつまずきがちです。
そこでこの記事では、頻出テーマである「アプリ／Web／DB／開発／テスト」の各分野を、豊富な図解や身近な具体例を交えながら、一問一答形式をベースに体系的に整理します。難解な専門用語をかみ砕き、攻撃の流れや対策の仕組みを直感的に理解できるようサポート。「なぜその対策が必要なのか？」という根本から解説することで、知識を確実に定着させ、午後問題で問われる応用力を着実に養うことを目指します。
目次
- 1 XSS・SQLインジェクション対策の基本│Webアプリ脆弱性の仕組みを午後試験向けに解説
- 2 【図解】セッションハイジャック対策とクリックジャッキングの仕組み│情報処理安全確保支援士 午後問題
- 3 DBセキュリティ対策の基本│権限管理・監査ログ・分離レベルを午後試験向けに解説
- 4 【午後問題の鍵】セキュア開発プロセス攻略│SDL・OWASP Top 10・要件定義のポイント
- 5 脆弱性を見つけ出す手法│午後試験で問われる5つのセキュリティテストを解説
XSS・SQLインジェクション対策の基本│Webアプリ脆弱性の仕組みを午後試験向けに解説
情報処理安全確保支援士の午後試験で頻出のWebアプリケーション脆弱性。中でも特に重要なのが「クロスサイトスクリプティング（XSS）」「クロスサイトリクエストフォージェリ（CSRF）」「SQLインジェクション」の3つです。それぞれの攻撃がどのように行われ、なぜ危険なのか、具体例と図解で仕組みから理解していきましょう。
Q. XSS（クロスサイトスクリプティング）とは？
A. 攻撃者が悪意あるスクリプトをWebページに罠として仕掛け、訪問した利用者のブラウザ上でそのスクリプトを不正に実行させる攻撃です。
【身近な例え：危険なメッセージが貼られた伝言板】
XSSは、多くの人が見る「伝言板」に、悪意のある人が「見た人を操る魔法の言葉（スクリプト）」を書き込むようなものです。他の人がその書き込みを見ると、魔法にかかってしまい、意図しない行動（個人情報の送信など）を取らされてしまいます。Webサイトが伝言板、書き込みが罠のスクリプトと考えると分かりやすいでしょう。
【攻撃の具体例と流れ】
ECサイトの商品レビュー欄が悪用されるケースを考えてみましょう。
- 罠の設置：攻撃者が、ECサイトの商品レビュー欄に「この商品は最高！ <script>/* Cookie情報を攻撃者のサーバーへ送信するコード */</script>」のような、悪意あるスクリプトを含んだレビューを投稿します。
- 罠の発動：別のユーザーが、その商品レビューページを閲覧します。
- 被害発生：ユーザーのブラウザは、レビューを表示する際に、そこに埋め込まれたスクリプトをWebサイトからの正規の命令だと勘違いして実行してしまいます。結果として、ユーザーのCookie情報（ログイン状態を保持する情報など）が盗まれ、攻撃者になりすまされてしまう可能性があります。
【図解：XSS攻撃の流れ】 ┌──────┐ ┌──────────┐ ┌────────┐ │ 攻撃者 │─── 1. 罠を仕掛ける ──→│ Webサーバー(ECサイト) │←── 2. ページ閲覧 ── │ 被害者 │ └──────┘ (スクリプト投稿) └──────────┘ └────────┘ │ │ │ │ │ 3. 罠を含んだページを送信 ↓ │ └───────────────→ ブラウザでスクリプト実行 │ │ └────────── 4. Cookie情報などが漏洩 ───────────────┘
Q. XSSの主な対策は？
A. 入力値のエスケープ（無害化）、CookieへのHTTPOnly属性の設定、Content Security Policy (CSP) の導入が有効です。
- エスケープ：
<や>といった、スクリプトとして特別な意味を持つ文字を、単なる文字列（例：<,>）に変換し、スクリプトとして実行されないようにします。 - HTTPOnly属性：Cookieにこの属性をつけると、JavaScriptからのアクセスが禁止されます。万が一XSS攻撃が成功しても、Cookieを盗まれにくくなります。
- Content Security Policy (CSP)：信頼できるドメインのスクリプトのみ実行を許可するようブラウザに指示する仕組みです。
Q. CSRF（クロスサイトリクエストフォージェリ）とは？
A. ログイン状態の利用者が、意図しないリクエスト（書き込みや購入など）を、攻撃者が用意した罠サイト経由で強制的に送信させられてしまう攻撃です。
【身近な例え：偽の署名用紙にサインさせる】
CSRFは、あなたが「本人であることの証明書（ログイン状態）」を持っているときに、悪意のある人が「これはアンケートです」と偽って、実は「高額な商品を買います」という契約書（意図しないリクエスト）にサイン（リクエスト送信）をさせるようなものです。本人はアンケートに答えているつもりでも、裏では勝手に契約が進んでしまいます。
【攻撃の具体例と流れ】
ユーザーがネットバンキングにログインしたまま、別のWebサイトを閲覧するケースです。
- 準備：被害者は、正規のネットバンキングにログイン済みです。ブラウザはログイン状態を保持しています。
- 罠サイトへ誘導：攻撃者は、「面白い動画はこちら」などのリンクで、被害者を自身が作った罠サイトに誘導します。
- 罠の発動：被害者が罠サイトを閲覧した瞬間、そのページに埋め込まれたスクリプトが、被害者の意図とは無関係に「他人の口座へ10万円送金する」というリクエストをネットバンキングのサーバーへ自動的に送信します。
- 被害発生：ネットバンキングのサーバーは、ログイン済みの正規ユーザーからのリクエストだと誤認し、送金処理を実行してしまいます。
Q. CSRFの対策は？
A. トークン方式（CSRFトークン）の実装、Refererヘッダのチェック、CookieへのSameSite属性の利用が有効です。
- トークン方式：サーバーが、正規のページにのみ秘密の文字列（トークン）を埋め込みます。リクエスト時にこのトークンが一緒に送られてこなければ、正規のページからのリクエストではないと判断して処理を拒否します。
- Refererチェック：リクエストの送信元（Refererヘッダ）が、正規のドメインであるかを確認します。
- SameSite属性：Cookieが、外部サイトからのリクエストと一緒に送信されるのを制限する仕組みです。
Q. SQLインジェクションとは？
A. Webアプリケーションが想定していないSQL文を攻撃者が入力フォームなどに注入（インジェクション）し、データベースを不正に操作する攻撃です。
【身近な例え：命令書を書き換えて金庫を開ける】
データベースが「命令書（SQL文）」に書かれた通りに動く厳格な金庫番だとします。SQLインジェクションは、金庫番に渡す命令書（ログインフォームの入力など）に、不正な追記をして「IDとパスワードが一致しなくても金庫を開けろ」という命令に書き換えてしまうような攻撃です。
【攻撃の具体例と流れ】
IDとパスワードを入力してログインするWebサイトが標的です。
- 不正な入力：攻撃者は、ID入力欄に「
admin'--」、パスワード入力欄に任意の文字列を入力します。 - 不正なSQL文の生成：Webアプリケーション側で、入力値を使って
SELECT * FROM users WHERE user_id = 'admin'--' AND password = '...';というSQL文が作られます。 - 認証回避：データベースでは、
--以降はコメントとして扱われます。そのため、実行されるのはSELECT * FROM users WHERE user_id = 'admin'の部分だけになり、パスワードチェックが無効化されます。 - 被害発生：結果として、
adminユーザーのパスワードが一致しなくてもログインが成功してしまい、管理者権限を乗っ取られます。
Q. SQLインジェクションの対策は？
A. プレースホルダを用いた静的クエリ（バインド機構）の利用が最も確実な対策です。入力値のエスケープも有効な場合があります。
- プレースホルダ：SQL文の骨格を先に確定させ（例：
SELECT * FROM users WHERE user_id = ? AND password = ?）、後から入力値を「データ」として流し込む仕組みです。入力値がSQL文の一部として解釈されることがないため、攻撃が成立しません。
【3大脆弱性の比較まとめ表】
| 脆弱性名 | 攻撃のイメージ | 主な被害 | 有効な対策 |
|---|---|---|---|
| XSS | サイトに罠を仕掛け、訪問者を操る | Cookie情報の窃取、なりすまし | 入力値のエスケープ、HTTPOnly属性 |
| CSRF | ログイン中のユーザーに意図しない操作をさせる | 不正な送金、意図しない商品購入 | CSRFトークン、SameSite属性 |
| SQLインジェクション | DBへの命令文を書き換え、不正操作する | データベース情報の漏洩・改ざん、認証回避 | プレースホルダ（バインド機構） |
【図解】セッションハイジャック対策とクリックジャッキングの仕組み│情報処理安全確保支援士 午後問題
Webアプリケーションの安全性を脅かすのは、前述した3大脆弱性だけではありません。ユーザーの利用状態（セッション）を乗っ取ったり、巧みにクリック操作を騙したりする攻撃も頻出です。ここでは、セッションハイジャックとクリックジャッキングの仕組みと対策を、図解と共に掘り下げていきましょう。
Q. セッションハイジャックとは？
A. 攻撃者が何らかの方法で正規ユーザーのセッションIDを盗み出し、そのセッションIDを使って本人になりすまし、不正にサービスを利用する攻撃です。
【身近な例え：会員制施設の会員証を奪う】
セッションハイジャックは、会員制施設の「一時利用カード（セッションID）」を盗み見たり、奪い取ったりする行為に似ています。攻撃者はそのカードを使って本人になりすまし、施設内のサービス（Webサイト上の個人情報閲覧や商品購入など）を不正に利用してしまうのです。
【攻撃の具体例と流れ】
暗号化されていない公衆Wi-Fiの利用中に、セッションIDが盗聴されるケースです。
- 準備：被害者は、カフェなどの公衆Wi-Fiを使い、ECサイトにログインします。
- 盗聴：同じWi-Fiに接続していた攻撃者が、ネットワークを流れる通信を盗聴し、被害者の通信に含まれるセッションID（Cookieに保存されている）を窃取します。
- なりすまし：攻撃者は、窃取したセッションIDを自身のブラウザに設定し、ECサイトにアクセスします。
- 被害発生：ECサイトのサーバーは、正規のセッションIDが送られてきたため、攻撃者をログイン中の被害者本人だと誤認します。攻撃者はアカウントを乗っ取り、登録済みのクレジットカードで勝手に商品を購入したり、個人情報を閲覧したりします。
【図解：セッションハイジャック（盗聴）の流れ】 ┌────────┐ 1. ログインし、セッションID発行 │ 被害者 ├───────────────────┐┌──────────┐ └────────┘ 2. セッションIDを含む通信 ││ Webサーバー(ECサイト) │ │ (暗号化されていないWi-Fi) ├──┤ │ │ │ │└──────────┘ ┌──────┐ ↓ 盗聴 │ │ 攻撃者 ├──── 3. セッションIDを窃取 │ └──────┘ │ │ │ └─ 4. 盗んだIDでアクセス（なりすまし成功） ───┘
Q. セッション管理の代表的な対策は？
A. セッションIDを推測困難なものにすること、CookieにSecure属性やHttpOnly属性を付与すること、そして適切なタイムアウト値を設定することです。
- 推測困難なセッションID：セッションIDが単純な連番だと、他人のIDを推測されてしまいます。暗号論的擬似乱数生成器を用いて、十分に長く複雑なIDを生成することが重要です。
- Secure属性：Cookieにこの属性をつけると、HTTPSの暗号化された通信でしかCookieが送信されなくなります。これにより、公衆Wi-Fiなどでの盗聴を防ぎます。
- HttpOnly属性：XSS対策でも有効で、JavaScriptからのアクセスを禁止し、スクリプトによるセッションIDの窃取を防ぎます。
- タイムアウト設定：ログイン後、一定時間操作がなかった場合にセッションを無効（ログアウト）にします。これにより、万が一セッションIDが盗まれても、悪用される時間を短縮できます。
Q. クリックジャッキングとは？
A. Webサイトの上に透明な別のWebページを重ねて配置し、利用者を視覚的に騙すことで、意図しない操作（ボタンのクリックや入力）をさせる攻撃です。
【身近な例え：透明な契約書を重ねてサインさせる】
これは、あなたが「懸賞に応募する」ボタンを押そうとしているとします。しかし、そのボタンの上には、あなたには見えないように「全財産を譲渡します」と書かれた透明な契約書の署名欄がぴったりと重ねられています。あなたが応募ボタンをクリックしたその場所は、実は契約書の署名欄であり、意図せず危険な契約にサインしてしまう、という巧妙な罠です。
【攻撃の具体例と流れ】
SNSの退会確認ページが悪用されるケースです。
- 罠サイトの構築：攻撃者は、自身のWebサイト（罠サイト）を作成します。そのページには「景品が当たる！クリック！」といった魅力的なボタンが配置されています。
- 透明ページの埋め込み：攻撃者は、罠サイトのボタンの真上に、
iframeというHTMLタグを使ってSNSの「退会する」ボタンが表示されるページを埋め込み、CSSで透明（opacity: 0）に設定します。利用者の目には、下の「景品が当たる！」ボタンしか見えません。 - 罠サイトへ誘導：被害者は、SNSにログインした状態で、罠サイトへ誘導されます。
- 被害発生：被害者が「景品が当たる！」ボタンをクリックすると、実際にはその上にある透明な「退会する」ボタンをクリックしたことになり、意図せずSNSを退会させられてしまいます。
【図解：クリックジャッキングの構造】 【ユーザーの視点】 ┌────────────────────────┐ │ │ │ ┌──────────┐ │ │ │ 景品が当たる！ │ ← これをクリックしたつもりが… │ └──────────┘ │ │ │ └────────────────────────┘ 【実際のページの構造】 ┌────────────────────────┐ │【透明なiframe：SNSの退会ページ】 │ │ ┌──────────┐ │ │ │ 退会する │ ← 実はこれをクリックさせられている │ └──────────┘ │ └┰───────────────────────┰┘ ┌┸───────────────────────┸┐ │【背景のページ：罠サイト】 │ │ ┌──────────┐ │ │ │ 景品が当たる！ │ │ │ └──────────┘ │ └────────────────────────┘
Q. クリックジャッキングの対策は？
A. X-Frame-Options HTTPレスポンスヘッダや、Content-Security-Policy (CSP) の frame-ancestors ディレクティブで、外部サイトからの iframe による読み込みを制御します。
X-Frame-Optionsヘッダ：ブラウザに対して、自サイトのページがiframe内で表示されることを許可するかどうかを指示します。DENY：すべてのiframeでの表示を拒否。SAMEORIGIN：同一オリジン（同じサイト）からのiframeでの表示のみ許可。
Content-Security-Policy(CSP) のframe-ancestorsディレクティブ：より柔軟な制御が可能です。例えば、特定のドメインからのiframeでの読み込みのみを許可するといった設定ができます。X-Frame-Optionsよりも新しい仕様で、こちらが推奨されています。
DBセキュリティ対策の基本│権限管理・監査ログ・分離レベルを午後試験向けに解説
アプリケーションの入り口を固めても、その先にあるデータの保管庫、つまりデータベース自体の守りが甘ければ意味がありません。ここでは、データベースを安全に保つための根幹となる「権限の最小化」「ビューの利用」「監査ログ」「トランザクション分離レベル」という4つの重要概念を解説します。
Q. 権限の最小化とは？
A. ユーザーやアプリケーションに付与するデータベース操作権限を、業務や機能の遂行に本当に必要な最小限に限定するという、セキュリティの基本原則です。
【身近な例え：必要な部屋の鍵だけを渡す】
「権限の最小化」は、大きなオフィスビルで働く従業員に、全ての部屋に入れるマスターキーを渡すのではなく、「自分の部署」と「トイレ」の鍵だけを渡すようなものです。万が一、従業員が鍵を紛失しても、被害は最小限に食い止められます。データベースでも同様に、Webアプリにはデータの参照・追加・更新権限（SELECT, INSERT, UPDATE）だけを与え、テーブル構造の変更（ALTER）や削除（DROP）といった強力な権限は与えないのが鉄則です。
【実務での適用例】
- Webアプリケーション用ユーザー：商品テーブルの参照（SELECT）と注文テーブルへの書き込み（INSERT）のみ許可する。
- バッチ処理用ユーザー：夜間集計に必要なテーブルの参照（SELECT）と集計結果テーブルへの書き込み（INSERT）のみ許可する。
- データベース管理者：すべての権限を持つが、日常業務では権限の低い一般ユーザーを利用し、必要なときだけ管理者ユーザーに切り替える。
Q. DBのビューの利用目的は？
A. 元となるテーブル（ベーステーブル）から、特定の列や行だけを抜き出して、あたかも別のテーブルのように見せる仮想的なテーブルです。不要な情報へのアクセスを制限する目的で使われます。
【身近な例え：風景を見せるための特別な窓】
データベースのテーブルが、個人情報や給与情報など様々な情報が詰まった「部屋」だとします。「ビュー」は、その部屋に取り付けられた“特別な窓”です。一般社員向けの窓からは「社員名簿（氏名と部署のみ）」が見え、経理部向けの窓からは「給与台帳（氏名と給与額）」が見えるように、見る人に合わせて公開する情報を制限できます。元の部屋のすべての情報（ベーステーブル）を直接見せる必要がないため、安全性が高まります。
【図解：ビューの仕組み】
┌─────────────────────────────────┐
│ 【ベーステーブル：従業員マスタ】 │
│ ┏━━━━━━┳━━━━━━┳━━━━━━┳━━━━━┓ │
│ ┃ 社員番号 ┃ 氏名 ┃ 部署 ┃ 給与 ┃ │
│ ┠──────╫──────╫──────╫─────┨ │
│ ┃ 1001 ┃ 田中太郎 ┃ 営業部 ┃ 300,000 ┃ │
│ ┠──────╫──────╫──────╫─────┨ │
│ ┃ 1002 ┃ 鈴木花子 ┃ 経理部 ┃ 350,000 ┃ │
│ ┗━━━━━━┻━━━━━━┻━━━━━━┻━━━━━┛ │
└─────────────────────────────────┘
▲ ▲
│ │
┌─────────────────┐ ┌─────────────────┐
│ 【ビューA：一般公開用】 │ │ 【ビューB：経理部用】 │
│ ┏━━━━━━┳━━━━━━┓ │ │ ┏━━━━━━┳━━━━━┓ │
│ ┃ 氏名 ┃ 部署 ┃ │ │ ┃ 氏名 ┃ 給与 ┃ │
│ ┠──────╫──────┨ │ │ ┠──────╫─────┨ │
│ ┃ 田中太郎 ┃ 営業部 ┃ │ │ ┃ 鈴木花子 ┃ 350,000 ┃ │
│ ┠──────╫──────┨ │ │ ┗━━━━━━┻━━━━━┛ │
│ ┃ 鈴木花子 ┃ 経理部 ┃ │ └─────────────────┘
│ ┗━━━━━━┻━━━━━━┛ │
└─────────────────┘
Q. データベース監査ログの役割は？
A. 「いつ」「誰が」「どのデータに」「何をしたか」といったデータベースへのアクセスや操作の履歴を記録することです。不正アクセスや不審な操作の検知、そしてインシデント発生時の原因追跡に不可欠な役割を果たします。
【身近な例え：データベースの防犯カメラ】
監査ログは、データベース世界の「防犯カメラ」や「入退室記録」に相当します。平常時は意識されませんが、ひとたび「個人情報が漏洩したかもしれない」「データが不正に書き換えられた」といった事件が起きると、この記録を再生（解析）することで、犯人や原因を特定する極めて重要な手がかりとなります。
Q. トランザクション分離レベルの目的は？
A. 複数の処理（トランザクション）が同時にデータベースにアクセスした際に、データの不整合（例：ダーティリードなど）が起きるのを防ぐための設定です。処理の独立性をどの程度保証するかを定義します。
【実務での適用例：在庫引き当て処理】
ECサイトで、在庫が1個しかない商品を、ユーザーAとユーザーBが同時に注文しようとするケースを考えます。
- ユーザーAが在庫数を参照（在庫=1）。
- ほぼ同時にユーザーBも在庫数を参照（在庫=1）。
- ユーザーAが注文を確定し、在庫を0に更新。
- ユーザーBも注文を確定しようとするが、在庫が0になっている。
もし分離レベルが適切でないと、ユーザーBが更新前の在庫数（1）を見てしまい、在庫がないのに注文が通ってしまう「ダーティリード」などの不整合が発生する可能性があります。適切な分離レベル（例：READ COMMITTED や REPEATABLE READ）を設定することで、Aの処理が完了（コミット）するまでBは待たされるか、あるいは更新後のデータを読み込むようになり、整合性が保たれます。
【午後問題の鍵】セキュア開発プロセス攻略│SDL・OWASP Top 10・要件定義のポイント
これまでのセクションで見てきた脆弱性は、多くの場合、開発プロセスにセキュリティの視点が欠けていたことが原因で生まれます。現代のシステム開発では、完成後に問題を探す「後付け」のセキュリティではなく、企画・設計といった初期段階からセキュリティを組み込む「シフトレフト」のアプローチが不可欠です。ここでは、その中核となるセキュア開発の考え方を学びます。
Q. セキュア開発ライフサイクル（SDL）とは？
A. ソフトウェア開発の全工程（要件定義、設計、実装、テスト、リリース）にセキュリティ活動を組み込むことで、開発の初期段階から脆弱性を潰し込み、製品全体の安全性を高めるための体系的なプロセスです。
【身近な例え：安全な家を建てるプロセス】
SDLは、頑丈で安全な「家づくり」に似ています。
- 要件定義（どんな家に住みたいか）：「地震に強い家」「泥棒に入られにくい家」といったセキュリティ要件を最初に決めます。
- 設計（設計図を描く）：耐震構造を計算し、防犯性の高い窓や鍵の配置を設計図に落とし込みます。
- 実装（家を建てる）：設計図通りに、熟練の大工が丁寧に工事を進めます（セキュアコーディング）。
- テスト（検査する）：完成前に、建物の強度や鍵の施錠具合を専門家が厳しくチェックします（セキュリティテスト）。
このように、各工程で安全性を確認することで、後から大掛かりなリフォーム（手戻り）をすることなく、安心して住める家が完成します。
【図解：セキュア開発ライフサイクル（SDL）の概念】 企画 → 要件定義 → 設計 → 実装 → テスト → リリース・運用 │ │ │ │ │ │ └──┬──┘ │ │ │ │ セキュリティ │ │ │ │ 要件の明確化 │ │ │ │ └──┬──┘ │ │ │ 脅威分析・ │ │ │ セキュリティ設計 │ │ │ └──┬──┘ │ │ セキュア │ │ コーディング │ │ └──┬──┘ │ セキュリティ │ テスト │ └──┬──┘ インシデント対応
Q. セキュリティ要件定義で重視すべきことは？
A. 情報セキュリティの3大要素であるCIA（機密性・完全性・可用性）を考慮した上で、システムが満たすべき具体的なセキュリティ要件を明確に定義することです。
- 機密性 (Confidentiality)：許可された人だけが情報にアクセスできること。（例：「管理者権限を持つユーザーしか、個人情報を閲覧できない」）
- 完全性 (Integrity)：情報が不正に改ざんされたり、破壊されたりしないこと。（例：「送金処理の金額は、途中で書き換えられない」）
- 可用性 (Availability)：必要なときに、いつでも情報やサービスを利用できること。（例：「システムは24時間365日、サービスを停止しない」）
これらのCIAを軸に、「誰の」「何を」「何から」守るのかを具体的に落とし込むことが、後続の設計・実装工程のブレを防ぎます。
Q. セキュアコーディングの代表例は？
A. 開発者がソースコードを記述する際に、脆弱性を生み込まないように実践する具体的なプログラミング手法です。入力値の検証、適切な例外処理、そしてエラーメッセージの適切な管理などが挙げられます。
【実務での適用例】
- 入力値の検証（バリデーション）：ユーザーからの入力値（ID、パスワード、検索キーワードなど）は、必ず「期待される形式・文字種・長さか」をチェックする。これにより、SQLインジェクションやXSSの原因となる不正な文字列の混入を防ぎます。
- 例外処理：データベース接続失敗などの予期せぬエラーが発生した際に、プログラムが異常終了しないよう適切に処理する。このとき、エラーの詳細情報（サーバーの内部情報など）をユーザー画面に表示してはいけません。
- エラーメッセージの統制：ログイン失敗時に「IDが存在しません」や「パスワードが間違っています」と親切に表示すると、攻撃者にヒントを与えてしまいます。「IDまたはパスワードが正しくありません」のように、情報を限定したメッセージを表示します。
Q. OWASP Top 10とは？
A. Webアプリケーションにおけるセキュリティ上の脅威や脆弱性の中で、特に重要で危険度の高いものを10項目選び、ランキング形式でまとめた国際的なレポートです。セキュア開発において、どこに注力すべきかを把握するための指針として広く活用されています。
【身近な例え：泥棒の手口トップ10】
OWASP Top 10は、いわば「Webサイトを狙う泥棒の最新手口トップ10」です。このリストを見れば、「ピッキング」「空き巣」「ガラス破り」など、世の中で最も横行している侵入手法が分かります。家の防犯対策を考えるとき、このリストの上位にある手口から優先的に対策（鍵を強化する、窓に補助錠を付けるなど）するのが効果的であるのと同じように、Web開発でもOWASP Top 10の上位項目から優先的に対策を講じることが求められます。
【OWASP Top 10 2021年版（一部抜粋）】
| 順位 | カテゴリ名 | 概要 |
|---|---|---|
| A01 | アクセス制御の不備 | 他のユーザーのアカウント情報にアクセスできるなど、権限設定の不備を突く攻撃。 |
| A02 | 暗号化の失敗 | パスワードや個人情報が平文で保存・通信されるなど、暗号化が不適切な状態。 |
| A03 | インジェクション | SQLインジェクションなど、不正なデータを注入してシステムを誤動作させる攻撃。 |
脆弱性を見つけ出す手法│午後試験で問われる5つのセキュリティテストを解説
セキュア開発プロセスを導入しても、設計上の考慮漏れや実装時のミスがゼロになるとは限りません。そこで最後の砦となるのが、リリース前の「セキュリティテスト」です。開発されたシステムに潜む脆弱性を、様々な角度から網羅的に洗い出すためのテスト手法について、それぞれの特徴と目的を明確に理解しましょう。
Q. ホワイトボックステストとは？
A. システムの内部構造（ソースコードや設計書）を完全に理解した状態で行うテストです。開発者や内部の人間が実施するケースが多く、コードの全経路（網羅率）をチェックするなど、論理的な欠陥を詳細に検証します。
【身近な例え：設計図を持つエンジン整備士】
自動車のエンジンを点検する際に、設計図を見ながら全部品を分解・チェックし、内部の微細な亀裂や摩耗まで発見するようなものです。内部構造が分かっているからこそ、表面的な動作確認だけでは見つけられない、根本的な問題点を発見できます。
Q. ブラックボックステストとは？
A. システムの内部構造には一切触れず、外部からの入力とそれに対する出力だけを見て、仕様通りに動作するかを検証するテストです。攻撃者と同じ視点で、外部から見える挙動のみを頼りに脆弱性を探します。
【身近な例え：車の試乗をする一般ドライバー】
免許取り立てのドライバーが、車の内部構造を知らなくても「アクセルを踏めば進むか」「ブレーキを踏めば止まるか」を確かめるのと同じです。ユーザーや攻撃者の立場でシステムを操作し、予期せぬ挙動や脆弱性の兆候がないかを探ります。
Q. ファジングテストとは？
A. ランダムで大量の、あるいは意図的に不正な形式のデータ（ファズ）をプログラムに送り込み、予期せぬ動作や脆弱性（特にクラッシュやサービス停止）を検出するテスト手法です。ファジング、ファズテストとも呼ばれます。
【身近な例え：自動販売機におかしな物を入れてみる】
自動販売機のコイン投入口に、対応外の外国の硬貨やゲームセンターのメダル、さらには石や砂などを手当たり次第に投入してみるようなテストです。まともなデータでは発覚しない、例外処理の不備や想定外の入力に対するシステムの脆さ（もろさ）をあぶり出します。
Q. ペネトレーションテストとは？
A. 実際に攻撃者の思考や手法を模倣して、システムへの侵入を試みる実践的なテストです。「侵入テスト」とも呼ばれます。単一の脆弱性を見つけるだけでなく、複数の脆弱性を組み合わせて、最終的にどのような被害（情報漏洩など）に繋がるかまでを検証します。
【身近な例え：本番さながらの防災訓練】
警備会社に依頼して、専門のスタッフに「本気で金庫室への侵入を試みてもらう」ようなものです。ピッキング、監視カメラの死角の利用、警備員の交代タイミングなど、あらゆる手口を駆使して侵入を試みることで、机上の空論では分からなかったセキュリティホールの実効的な危険性を評価できます。
Q. セキュリティレビューとは？
A. 設計書やソースコードを、セキュリティ専門家や経験豊富な開発者が机上で読み解き、脆弱性やセキュリティ上の懸念がないかを確認する活動です。ツールによる自動検出が難しい、設計上の根本的な欠陥やビジネスロジックの穴を発見することに長けています。
【身近な例え：ベテラン建築家による設計図のレビュー】
若手建築家が描いた高層ビルの設計図を、経験豊富なベテラン建築家が「この構造では強風に弱い可能性がある」「避難経路の設計に無理がある」といった観点からチェックする作業です。個々の部品は正しくても、全体の組み合わせや設計思想に潜む問題点を、人の知見によって発見します。
【セキュリティテスト手法の比較まとめ表】
| テスト手法 | 視点 | 主な対象 | 目的 |
|---|---|---|---|
| ホワイトボックステスト | 内部 | ソースコード、内部仕様 | コードの網羅的な検証、論理的欠陥の発見 |
| ブラックボックステスト | 外部 | システムの外部的な振る舞い | 仕様通りの動作確認、攻撃者視点での検証 |
| ファジングテスト | 外部 | 入力受付部分 | 未知の脆弱性発見、システムの堅牢性評価 |
| ペネトレーションテスト | 外部 | システム全体 | 実際の侵入経路と影響範囲の特定、総合的な耐性評価 |
| セキュリティレビュー | 内部 | 設計書、ソースコード | 設計上の欠陥発見、ロジックの妥当性評価 |