[https://www.youtube.com/watch?v=NuzyFjXxEVA:embed:cite]
本動画では、令和5年度秋期に行われた情報処理安全確保支援士試験の午後問題1を取り上げ、Webアプリケーションに潜む脆弱性と、それを利用した巧妙な攻撃手口、そしてセキュリティ担当者が取るべきインシデント対応について徹底的に解説していきます。今回のテーマは、洋服を販売するECサイト「WebアプリQ」で発生した不可解なレビュー表示の不具合から始まるフォレンジック調査のストーリーです。試験問題のシナリオでは、開発リーダーであるN氏が、会員からの「レビューページがおかしい」という問い合わせを受けて調査を開始するところから物語が始まります。具体的には、データベース上には「16件」のレビューデータが保存されているにもかかわらず、Webブラウザ上で確認すると「2件」しか表示されないという矛盾が発生していました。この異常な挙動の原因を突き止める過程で、Webセキュリティの基礎知識だけでなく、攻撃者がどのようにシステム制約を回避し、情報を窃取したかという高度なテクニックを読み解く力が試される良問となっています。 動画の前半では、N氏が行った初動調査と脆弱性の特定プロセスに焦点を当てます。N氏がHTMLソースコードを確認したところ、本来テキストのみが表示されるべきレビュータイトルの箇所に、不可解なJavaScriptのコードが埋め込まれていることが判明しました。これは、Webアプリケーションにおける代表的な脆弱性の一つである「クロスサイトスクリプティング（XSS）」、その中でも攻撃コードがデータベースに永続的に保存され、ページを閲覧したユーザー全員が被害に遭う可能性がある「格納型XSS」と呼ばれる攻撃です。しかし、ここで一つの大きな疑問が浮上します。WebアプリQの仕様では、レビュータイトルに入力できる文字数は「50文字」に制限されていたはずです。攻撃者はどのようにして、この短い文字数制限の中で、複雑な攻撃スクリプトを実行させたのでしょうか。本動画では、この謎を解く鍵となる「分割投稿」という手口について図解を用いて詳細に説明します。攻撃者は一度の投稿ですべてのコードを書くのではなく、複数のレビュー投稿に分けてスクリプトを断片化して送り込んでいました。具体的には、最初の投稿でスクリプトタグとともにJavaScriptのコメントアウト開始記号を記述し、その後の投稿で攻撃コード本体を記述、そして最後の投稿でコメントアウト終了記号を記述するという手法です。これにより、投稿と投稿の間に挟まるWebサイト本来のHTMLタグ（日付や投稿者名など）をすべてコメントとして無効化し、複数の投稿をブラウザ上で一つの一連のスクリプトとして結合させ実行させることに成功していたのです。 動画の中盤では、攻撃者が実行させた不正なスクリプトが具体的に何を行っていたのか、そのコードの挙動を一行ずつ解析していきます。攻撃の目的は、被害に遭った会員のセッション情報を盗み出し、なりすましを行うことでした。そのために攻撃者は、非常に手の込んだデータの持ち出し方法を採用しています。まず、スクリプトはXMLHttpRequest（XHR）を使用して、被害者のブラウザの裏側で会員プロフィール設定ページへアクセスを行います。これは、攻撃者が次のステップで必要となる「CSRF対策トークン」を取得するためです。通常、重要な操作を行う際にはこのトークンが必要となるため、攻撃者はまず正規のページからトークンを抽出する準備を行いました。次に、攻撃者は被害者のブラウザに保存されているCookie情報、つまりセッションIDを取得します。ここでWebアプリQには、JavaScriptからのCookie読み取りを禁止する「HttpOnly属性」が付与されていないという不備があったことが悪用されました。そして、このセッションIDを攻撃者の手元に送る方法が、本問の最大の特徴的なポイントです。攻撃者はセッションIDの文字列をデータとして含む、偽の画像ファイル（MIMEタイプはimage/pngだが中身はテキスト）を動的に生成し、先ほど取得したトークンを使って、被害者の「アイコン画像」としてサイト上にアップロードさせたのです。つまり、攻撃者は被害者のアイコン画像を、盗んだ情報を格納するコンテナとして利用したわけです。最終的に攻撃者は、アップロードされた被害者のアイコン画像（a.png）をダウンロードし、バイナリエディタやテキストエディタで開くことで、画像データの中に隠されたセッションIDの文字列を回収することに成功しました。 動画の後半では、なぜ攻撃者がこのような複雑な手順を踏まなければならなかったのか、その理論的背景にあるWebブラウザのセキュリティ機構「同一オリジンポリシー（Same-Origin Policy）」について解説します。設問4では、攻撃者が自分の用意した外部サイト（罠サイト）にスクリプトを設置し、そこから被害者にアクセスさせる手法ではなぜ攻撃が成立しないのかが問われています。本動画では、オリジン（プロトコル、ドメイン、ポート番号の組み合わせ）が異なるサイト間での非同期通信（XHR）においては、ブラウザのセキュリティ仕様により、自動的にはCookieが送信されない仕組みになっていることを詳しく解説します。この仕組みがあるため、攻撃者は外部からの攻撃ではなく、WebアプリQの内部にスクリプトを埋め込む（XSS）必要があったのです。 最後に、このような攻撃を防ぐための抜本的な対策と、多層防御の考え方についてまとめます。今回のインシデントの直接的な原因は、ユーザーからの入力データを画面に出力する際に適切なエスケープ処理が行われていなかったことにあります。特殊文字を実体参照に変換する処理を実装することで、ブラウザにスクリプトとして解釈されることを防ぐことができます。しかし、それだけでは不十分です。万が一XSSが発生した場合でも被害を最小限に抑えるために、CookieへのHttpOnly属性の付与や、アップロードされるファイルの拡張子だけでなく内容（ファイルヘッダやマジックナンバー）まで検証するといった、複数の防御層を設けることの重要性を解説します。情報処理安全確保支援士として、単にバグを修正するだけでなく、攻撃者の意図や技術的背景を深く理解し、ログや痕跡から正確に事象を把握する能力がいかに重要であるかを、この過去問解説を通じて学んでいきましょう。Webアプリケーション開発に関わるエンジニアや、セキュリティ試験の合格を目指す方にとって、実務にも試験対策にも直結する濃密な内容となっていますので、ぜひ最後までご覧ください。
