情報処理安全確保支援士試験の午後問題において、Webアプリケーションの脆弱性はネットワークセキュリティと並ぶ最重要テーマの一つです。SQLインジェクション、XSS、CSRFといった攻撃手法は頻出ですが、それぞれの違いを明確に説明できますか？「なんとなくは分かるけど、いざ問題文で問われると混乱してしまう…」という方も少なくないでしょう。
特に午後試験では、単に用語を暗記しているだけでは不十分です。提示されたシナリオから「今、何が起きているのか」「脆弱性はサーバ側、クライアント側のどちらにあるのか」を正確に見抜く洞察力が求められます。
本記事では、Webアプリケーションの主要な脆弱性について、攻撃が成立する「場所」と「手口」に着目して、その違いを明確に解説します。安全な通信の土台となるTLSの仕組みから始め、サーバを騙すSQLインジェクション、ユーザを罠にかけるXSSとCSRF、そしてそれらに対する防御の要であるWAFまで、体系的に知識を整理していきます。
この記事を読み終える頃には、各攻撃手法の本質的な違いが理解でき、シナリオ問題で適切な脆弱性と対策を自信を持って指摘できるようになるはずです。
目次
Webアプリセキュリティの前提知識│通信を保護するHTTPS/TLSの仕組み
Webアプリケーションの個々の脆弱性を議論する前に、その土台となる通信の安全性を理解しておく必要があります。もし通信経路が暗号化されてなければ、どんなに堅牢なアプリケーションを作っても、途中でパスワードや個人情報が盗聴されてしまうからです。その通信の安全性を担保するのがHTTPS (HTTP over TLS)です。
TLSの3つの役割
- 盗聴の防止 (暗号化): 第三者が通信内容を読めないようにデータを暗号化します。
- 改ざんの防止 (完全性): データが途中で書き換えられていないかを検証します。
- なりすましの防止 (認証): 通信相手が本物のサーバであることをデジタル証明書を使って確認します。
身近な例え：信頼できるオンラインショッピング 🛍️
TLSの仕組みは、セキュリティが厳重なデパートで買い物をするようなものです。
- なりすまし防止: あなたはまず、そのデパートが本物であることの証明（デジタル証明書）を確認します。これにより、偽の店舗でないことが保証されます。
- 暗号化: 次に、あなたと店員は、二人だけが理解できる特殊な言語（共通鍵）で話すことを決めます。これで、周りの客に会話の内容を聞かれる心配がありません。
- 改ざん防止: 会計時、商品は改ざん防止シールが貼られた箱（メッセージ認証コード）に入れられます。もし誰かが箱を不正に開ければ、シールが破れてすぐに分かります。
午後試験のポイント：TLSハンドシェイク
支援士試験では、この安全な通信路を確立するまでの一連の手順、TLSハンドシェイクの流れが問われることがあります。クライアントとサーバが、どの暗号方式を使うかを取り決め、デジタル証明書を検証し、暗号化に使う共通鍵を安全に交換するプロセスです。特に、サーバが本物であることを証明し、公開鍵をクライアントに渡すデジタル証明書の役割は非常に重要です。
【サーバサイド攻撃】SQLインジェクションの原理とエスケープ処理による対策
Webアプリケーションへの攻撃の中で最も代表的なものが、サーバ側を直接狙うSQLインジェクション（SQLi）です。これは、Webサイトの入力フォーム（検索窓やログイン画面など）に、データベースを不正に操作するためのSQL文の断片を「注入（injection）」する攻撃です。
SQLインジェクションの仕組み
アプリケーションが、利用者からの入力をそのまま信用してSQL文を組み立てている場合に、この脆弱性が生まれます。
（具体例）
あるサイトのユーザ検索機能が、以下のようなSQL文で動いているとします。
SELECT * FROM users WHERE name = '（ここに入力された名前）';
もし攻撃者が、入力フォームに Taro' OR 'A'='A という文字列を入れると、サーバ内部では意図せず以下のSQL文が完成してしまいます。
SELECT * FROM users WHERE name = 'Taro' OR 'A'='A';
'A'='A' の部分は常に真（true）になるため、WHERE句の条件が全ユーザに対して成立してしまい、結果としてテーブルに登録されている全ユーザの情報が盗まれてしまいます。
身近な例え：命令を書き足せる自動販売機 🥤
これは、命令を書き足せる欠陥のある自動販売機のようなものです。
- 正しい操作: 「お茶」のボタンを押すと、
「お茶を出す」という命令が実行される。 - 不正な操作: ボタンに「お茶』または『全商品を出す」と書いたシールを貼って押す。
- 結果: 自販機は命令を誤認し、
「お茶を出す」または「全商品を出す」と解釈して、庫内の全商品を排出してしまう。
対策の基本：プレースホルダとエスケープ処理
対策の基本は「利用者からの入力を、プログラムコード（SQL文）の一部として解釈させない」ことです。
| 対策方法 | 内容 |
|---|---|
| プレースホルダ（プリペアードステートメント） | SQL文の「型」をあらかじめデータベースに送っておき、後から入力値を「データ」として流し込む方式。最も安全で推奨される対策。 |
| エスケープ処理 | ' や ; といった、SQL文で特別な意味を持つ文字を、単なる文字として扱われるように無害化（例：' → \'）する。 |
支援士試験では、「Webアプリケーションのソースコードに脆弱性があるか」を問う問題も出題されます。ユーザからのリクエストを直接SQL文に連結しているようなコードを見つけたら、まずSQLインジェクションを疑うのが定石です。
【クライアントサイド攻撃①】XSS（クロスサイトスクリプティング）の種類と対策
SQLインジェクションがサーバを騙す攻撃だったのに対し、XSS（クロスサイトスクリプティング）は利用者のブラウザを騙すクライアントサイド攻撃の代表格です。攻撃者は、脆弱性のあるサイトの入力フォームなどを通じて、罠となるスクリプト（主にJavaScript）を埋め込みます。
XSSの仕組み
攻撃の目的は、標的サイトを閲覧した他のユーザのブラウザ上で、不正なスクリプトを実行させ、そのユーザのCookie情報（特にセッションID）を盗んだり、偽のログイン画面を表示させたりすることです。
身近な例え：危険な書き込みがある掲示板 🗒️
XSSは、危険な書き込みができてしまう電子掲示板に似ています。
- 罠の設置: 攻撃者が、掲示板に「<script>（悪意のある命令）</script>」という普通のコメントに見えない、特殊なインクで書かれた書き込みを投稿します。
- 罠の発動: 他のユーザがその掲示板のページを開くと、ブラウザが特殊なインクで書かれた部分を「命令」だと勘違いして実行してしまいます。
- 被害: 結果として、ページを閲覧したユーザの個人情報（Cookie）が、攻撃者に送信されてしまいます。
XSSの種類と対策
XSSには、スクリプトがどこに保存されるかによって、主に2つの種類があります。
| 種類 | 特徴 |
|---|---|
| 格納型（Stored）XSS | 攻撃スクリプトが、サイトのデータベース等に恒久的に保存される。罠が仕掛けられたページにアクセスした不特定多数のユーザが被害に遭う可能性があり、危険性が高い。 |
| 反射型（Reflected）XSS | 攻撃スクリプトが、URLのパラメータなどに含まれる。攻撃者は、罠を仕込んだURLをメール等でユーザにクリックさせる必要がある。 |
対策の基本は、入力時ではなく「出力時」です。ユーザからの入力値を画面に表示する際に、 < > " ' & といったHTMLで特別な意味を持つ文字を、< > " ' & のような無害な表示（HTMLエンティティ）に変換するエスケープ処理が最も重要な対策となります。
【クライアントサイド攻撃②】CSRF（クロスサイトリクエストフォージェリ）の罠とトークンによる防御
XSSと同じくクライアントサイドを狙う攻撃ですが、CSRF（クロスサイトリクエストフォージェリ）は少し手口が異なります。XSSが「ユーザのブラウザでスクリプトを実行させる」攻撃であるのに対し、CSRFは「ログイン済みのユーザに、意図しないリクエストを送信させる」攻撃です。
CSRFの仕組み
攻撃者は、ユーザがログインしている状態のWebサービス（オンラインショップ、SNSなど）に対し、商品の購入や退会処理といった重要な操作を勝手に行うよう仕向けます。
身近な例え：偽造された署名済み書類 📝
CSRFは、あなたがサインした（ログイン済み）状態の白紙の契約書を、悪意のある第三者が勝手に使ってしまうようなものです。
- 準備: あなたは銀行のサイトにログインしています。あなたのブラウザは銀行から「サイン済みの証明書（セッションCookie）」をもらっている状態です。
- 罠: あなたは、攻撃者が作った一見無害なWebサイト（例：動物のかわいい画像まとめサイト）を閲覧します。
- 罠の発動: そのサイトには、あなたの銀行に対して「攻撃者の口座へ10万円送金する」という内容の送金依頼書（リクエスト）が隠されています。ページを開いた瞬間、その依頼書があなたのブラウザから銀行へ自動的に送られてしまいます。
- 被害: 送信時、ブラウザは律儀に「サイン済みの証明書（セッションCookie）」を添付してくれます。銀行は正規の証明書が付いた依頼だと信じ込み、不正な送金を処理してしまいます。
XSSとCSRFの違い
この2つの攻撃はよく混同されますが、目的と手口が根本的に異なります。
| 比較項目 | XSS (クロスサイトスクリプティング) | CSRF (クロスサイトリクエストフォージェリ) |
|---|---|---|
| 目的 | ユーザ情報の窃取（Cookieを盗むなど） | 意図しない処理の実行（勝手に購入・退会など） |
| 手口 | 脆弱なサイトにスクリプトを注入する | ログイン済みユーザに不正なリクエストを送信させる |
| 例えるなら | 掲示板への危険な書き込み | 偽造された署名済み書類 |
対策の基本：トークンによるリクエストの検証
CSRFの最も有効な対策は、トークンと呼ばれる秘密の文字列をサーバとクライアント間で検証する方法です。
- サーバは、重要な操作を行うフォームを表示する際、推測困難なランダムな文字列（トークン）を生成し、フォームに埋め込みます。
- ユーザがフォームを送信すると、このトークンも一緒に送られます。
- サーバは、送られてきたトークンが、自身が発行した正規のものであるかを確認します。正規でなければ、そのリクエストを拒否します。
攻撃者はこのトークンを知ることができないため、偽の依頼書を送信しても、サーバ側で不正なリクエストとして弾かれます。
多層防御の要│WAFによる攻撃検知とCookieの重要な属性（Secure, HttpOnly）
個々の脆弱性に対するコーディングレベルの対策に加え、Webアプリケーション全体を包括的に保護する仕組みも重要です。ここでは防御の要となるWAFと、セッション管理を安全にするCookieの属性について解説します。
WAF：Webアプリケーションの用心棒
WAF (Web Application Firewall) は、その名の通りWebアプリケーションを専門に守るファイアウォールです。通信の中身（HTTPリクエスト）を詳細に解析し、SQLインジェクションやXSSといった攻撃パターン（シグネチャ）に合致する通信を検知・遮断します。
身近な例え 🕵️
通常のファイアウォールが「封筒の宛先と差出人」しか見ない郵便局員だとすれば、WAFは「手紙の中身を読んで、危険な文言がないかチェックする」諜報員のような存在です。アプリケーションに到達する前に、悪意のあるリクエストをブロックしてくれます。
Cookieを守る重要な属性
セッション管理に使われるCookie、特にセッションIDが漏洩すると、なりすまし（セッションハイジャック）の被害に直結します。そこで、Cookieを発行する際に特定の「属性」を付与することで、ブラウザに安全な取り扱いを指示することができます。
| 属性 | 役割 | 防御できる主な攻撃 |
|---|---|---|
| HttpOnly | JavaScriptからのCookieへのアクセスを禁止する。 | XSSによるセッションIDの窃取 |
| Secure | HTTPS通信の場合のみ、ブラウザがCookieをサーバに送信するように制限する。 | 通信の盗聴によるセッションIDの窃取 |
仕事での利用例 🏢
HttpOnly属性は、XSSの脆弱性が万が一存在した場合でも、document.cookie でセッションIDを盗まれるという最悪の事態を防ぐための「保険」として極めて重要です。また、Secure属性は、ログインページはHTTPSでも、サイト内の一部にHTTPのページが混在している場合に、暗号化されていない通信でセッションIDが送信されるのを防ぎます。
支援士試験では、これらの防御策が「多層防御」の観点からどのように機能するかが問われます。アプリケーションの修正がすぐに行えない場合の暫定対策としてWAFを導入したり、XSS対策の漏れを補完するためにHttpOnly属性を設定したり、といった判断が求められます。
まとめ：脆弱性が生まれる箇所を意識し、適切な対策を選択する
本記事では、Webアプリケーションの安全性を脅かす主要な脆弱性と、その対策について解説してきました。安全な通信の基盤であるTLS、サーバを狙うSQLインジェクション、そして利用者のブラウザを悪用するXSSとCSRF。それぞれの違いは明確になったでしょうか。
午後問題を解く上での最大の鍵は、シナリオを読んで「脆弱性の原因はどこにあるのか」を見抜くことです。
- ユーザの入力値からSQL文を組み立てている → SQLインジェクションの危険性
- ユーザの入力値をそのまま画面に表示している → XSSの危険性
- 重要な処理のリクエストがCookieのみで認証されている → CSRFの危険性
このように、脆弱性が生まれる「箇所」を意識すれば、取るべき対策もおのずと明らかになります。
脆弱性対策の早見表
最後に、各脆弱性と対策の要点をまとめます。頭の中を整理するためにご活用ください。
| 脆弱性 | 攻撃対象 | 根本的な問題 | 最も重要な対策 |
|---|---|---|---|
| SQLインジェクション | サーバ（DB） | コードとデータの混同 | プレースホルダ（プリペアードステートメント） |
| XSS | クライアント（ブラウザ） | 無防備な出力 | 出力時のHTMLエスケープ処理 |
| CSRF | クライアント（ブラウザ） | 正規リクエストの誤認 | トークンによるリクエスト検証 |
これらの基本原則をしっかりと押さえ、WAFやCookieの適切な属性設定といった多層防御を組み合わせることで、Webアプリケーションの安全性は飛躍的に高まります。本記事で得た知識を武器に、午後試験の突破を目指してください。