令和7年秋期試験 午後試験【問1】についての投稿を受け付けるスレッドです。

選んだ人少なそう

途中から記述式が曖昧な問いで難しかったから途中で解くのやめました

問1はweb系の仕事してるのもあって過去一の出来
嬉しすぎる

工夫、
①src属性の値としてファイルを埋め込む
②ダブルクオーテーションを使い、単なる文字列と判定されるようにする

で迷って①にしました、どっちも自信ありません

①はCSPの話が強調されているので最初は外部スクリプトを読み込もうとしたのでは?と判断しました
②はhtmlをエスケープ処理するにしました

進捗管理画面の対策は普通に「タスク名出力の前にエスケープ処理を施す」にしました

タスク名であってますか

あ、なるほど、最初は外部スクリプト読み込みだったけど、内部にファイルを配置してオリジン違反を回避したのか...

②をその問題かと間違えました。CSPの話があったので、そこは「スレッドでアップロードしたファイルを指定する」にしました

①はCSPの同一オリジン制限逃れるために、Sシステムの""/file/""配下にスクリプト書いたファイルおいて、それ実行させる的な感じ
②はエスケープ・サニタイズ
と書きました

工夫の2つはXSSの定番対策書いておけばいいんですかね。
ファイルのほうは、ファイル内容のチェックからのサニタイズ
画面のほうは、出力エスケープ
をそれぞれ書きました。

この投稿は投稿者により削除されました。(2025.10.12 17:44)

最初両方できないにしたけど違うんですかね…

B出来なかったらそもそもjavascript が動かない気がします

不安だけど全部埋められたよ。簡単説あり？

ペンテストも迷ったけどどちらかというとバックエンドやネットワークの侵入がメインのスコープのテストだから結局DAST/OWASP ZAPなどのツールを使用した脆弱性試験にしたな

今回のものはWebアプリ上の権限設計の不備を洗い出すことが目的のように読めたので

最初はできない/できない
にしました。(自信はなし)

aiですが

この画像に示されているHTTPレスポンスヘッダーには、コンテンツセキュリティポリシー (CSP) が設定されています。
Content-Security-Policy: default-src 'self'
default-src 'self' の設定は、特にディレクティブが指定されていないリソース（スクリプト、画像、CSSなど）について、現在のオリジン（Sサービスと同じプロトコル、ホスト、ポート）からのみ読み込みを許可するという意味です。
この設定に基づき、a と b の動作は以下のようになります。
• a：Sサービス以外のドメインからのリソースの読み込み：
ブロックされる（読み込み不可）
• 理由：'self' は現在のオリジン（ドメイン）のみを許可するため、他のドメインからのリソースはブロックされます。
• b：\text{<script>} タグ内に直接記述されたスクリプト（インラインスクリプト）の実行：
ブロックされる（実行不可）
• 理由：CSPでは、インラインスクリプトの実行を許可するためには、script-src ディレクティブに 'unsafe-inline' を明示的に指定する必要があります。default-src 'self' のみではインラインスクリプトは禁止されます。

できる/できる
じゃない？

なるほど、できない、出来ないっぽいですね。ありがとうございます

CSPってscriptタグ直書きは基本許容しない気がしてたが分かんないや

脆弱性診断ツールに引っかからないようなものなんだよね？
エスケープしてないことの脆弱性なんて楽勝で引っかかる気がするんだけど

脆弱性ツールに引っかからないのはタスクが締切日を過ぎないとレスポンスに含まれないからだと捉えて、最後はそこに焦点を当てました

できない/できない
にして、工夫は「同じオリジンの別ファイルからスクリプトを読み込む」にしました。
スクリプトをベタ書きしたXSSだとCSPでブロックされるので、わざわざ別のファイルからスクリプトを読み込む工夫をしたのかなーと思いました

なるほどねえ、そこまで読めなかった
最初はエスケープ書いたんだけどね、悔やまれるよ

1番最後に追加する検査ってなんだ？
問題に関連しない解答はNGになるタイプだから、コードレビューによるセキュアコーティングのチェックみたいなことをかいたw
検査かと言われると...

私は、最後のは「DASTを用いて、脆弱性を動的に検査する」と書いてしまった笑

同じく最後悩んで、このツール反射型XSSしか見てないのかなと思ったので、今回のようなStored XSS検出できるようにしないといけないのかと苦し紛れに書きましたw

SASTとDASTの組み合わせは鉄板ですし、良さそうに思います。

うっわインラインスクリプトが実行できないの、攻撃者がわざわざファイルアップロードして読み込ませてたのから推測できた
間違えちゃった〜ああ〜

キーワードは表示条件を満たすことだと考えちゃいましたね。その先のテスト自体は何でも良いと捉えました

脆弱性ツールはリクエストとレスポンス云々って書いてあったから、ある機能で登録したものが別の機能で攻撃として現れる類（格納型）の攻撃は検査できなかったんかなと思ってタスク名の出力時にエスケープ処理を施すにした。

4回目の受験ですが厳しいですね、、

設問1
a:できない、b:できる
設問2
(1)ロール管理
(2)c:タスク名
(3)d:個人タスク<script src= 〜略〜 </script>
(4)e:管理者、f:締切日を過ぎたもの、g:利用者のロールを管理者に設定する
(5)図3の内容をscriptタグに直接入力する
設問3
(1)h:拡張子と拡張子の中身が整合性が取れない場合、エラーとしアップロードしない。
(2)プロジェクト管理
(3)「<」「’’」「>」などの特殊文字を、「&lt;」「&quot;」「&gt;」などに置換する。
設問4
テスト時に、ロールが異なる利用者で、攻撃者の視点で悪意のある攻撃ができないかを確認する。

＞ ある機能で登録したものが別の機能で攻撃として現れる類（格納型）の攻撃は検査できなかった

なるほど。つまり最後は攻撃者の視点すら入ってればそれでいい?

3の(1)、そもそも元従業員がアクセスできるのやばくねと思って、元従業員の利用者IDでのスレッドへのアクセスを拒否するにしました

最後の問題は、最近流行りの妥当性があれば部分点貰えるやつかなと思いました。

DASTでWEBアプリの動的な挙動を確認する。はダメですかね。。。。

2の(4)はB者の管理者だとダメかな、？

できない／できないだと、＜script src も動かないんだよなー。と今更思う。でも、あれ成功したスクリプトなんだよね？？？

CSPでインラインスクリプト許可するならnonce使わないと無理。
default-src 'self'だけなら同一オリジン（今回の場合はアップロードしたファイルは同一オリジン内に保存されてる）だけは読み込める。

工夫って個人タスクって名前にすることで、他の人からスルーされるとかそういうことかと思った。

<40
自分もそう思ったんですけど、実行できるならわざわざスクリプトをファイルとしてアップロードしてからsrcで読み込ませなくていいよな…となりました

工夫ですが、/files/のパスでエラーになったので、/files/パスにするように工夫したという勝手なシナリオで解答してしまった・・・。とほほ・・・・。

設問1
a:できない、b:できる
設問2
(1)ロール管理
(2)c:タスク名
(3)d:個人タスク<script src= ~ </script>
(4)e:管理者、f:締切日を過ぎている、g:is_adiminの値を0に設定し、管理者のロールに変更する
(5)Sサービスと同じドメインから読み込めるリソースを参照するように文字列を変更する工夫
設問3
(1)h:拡張子偽造対策のために、ファイルの中身が拡張子に適しているかチェックする
(2)プロジェクト管理
(3)サービス利用者の入力に対して、エスケープ処理を行って出力させる処理
設問4
Sサービスの設計書を参照しながら、考えられる脆弱性を挙げ、手動で検査を行う手法
(ばつ)

is_adiminの値を0
→is_adiminの値を1

設問3
(1)ファイルの内容を確認し、スクリプトが含まれている場合はエラーにする。

にしましたが、HTTPレスポンスで、自動でファイルを判別しない。nosniffみたいなのが正解な気がしてきた。。。。

設問1
a:できない、b:できない
設問2
(1)ロール管理
(2)c:タスク名
(3)d:個人タスク<script src= 〜略〜 </script>
(4)e:管理者、f:締切日を過ぎたもの、g:ロールを一般利用者から管理者に変更する
(5)Sサービスの同じオリジンからスクリプトを読み込ませる工夫
設問3
(1)h:ファイル名をランダムな値に変更し保存した上で、内部的にはランダムな値でファイルを参照し、ダウンロードするときは元のファイル名でダウンロードさせる
# 拡張子とファイル内容のチェックも考えたのですが、Excelにスクリプト書いて共有したい時もあるよなーと思い、ファイル名がわかっちゃうからダメなんじゃない？と考えて上記にしました。
(2)プロジェクト進捗管理
(3)タスク名を出力する際にHTMLタグをエスケープ処理する
設問4
DASTを用いて、内部の動的な処理によって出力される値が想定された値通りに出力されていることを確認する
# SASTときたので、DASTかなと思ってDASTとだけ書いたのですが、回答欄的にもうちょい書かなきゃかなと思って蛇足になってしまった感。。。

> # SASTときたので、DASTかなと思ってDASTとだけ書いたのですが、回答欄的にもうちょい書かなきゃかなと思って蛇足になってしまった感。。。

私もです。SASTはヒントで、DASTだよなーとは思いますが、違ってたら、罠
すぎますが・・・。なので、DASTでWEBアプリの挙動確認するという単純な解答を書きましたが、どうなることやら。

問3(1)h エクセルやワードが触れられているので、スクリプトやマクロが含まれていないか確認する、としてしましました…

あー、インラインスクリプトじゃなくて同一オリジン上の外部スクリプト読み込み扱いになるのかー…
じゃあ できない/できない だな

最後はペネトレーションテストについて書いたけど違いそう…
SASTは中身のコードを分析する静的な調査だから、もう一個なんかやるなら実際に攻撃のシミュレーションするのが良くね？って思ってしまった

設問3 (1)でMIMEスニッフィングが思いついた時は自分をほめたかったです
==========
設問1  a できない
  b できない
設問2 (1)  ロール管理
 (2) c タスク名
 (3) d 個人タスク<script src="/files/F1234567890.xlsx"></script>
 (4) e 利用者
  f タスクの締切日が過ぎた場合
  g パラメータis_admin=1(管理者のロール)が設定された
 (5) ① スクリプトをHTMLに記述せず、ファイルにしてxlsxに偽装してアップロードした
設問3 (1) h ファイルのMIMEが偽装（スニッフィング）されてないかチェックする
 (2) i プロジェクト進捗管理
 (3) ② タスク名を出力する前に値をエスケープ処理する
設問4  j DASTを使って動的にブラックボックスでテストする

ロール権限を変更できるの管理者だから、最初「管理者」って書きましたが、文章中に管理者がタスク一覧を見るという文章が一切なかく「利用者」が見るという流れだったので、ロールチェックせずに変更の脆弱性があるのかと勝手に深読みして「利用者」に変えてしまった・・・。

利用者で合ってると思います。
表１のプロジェクト進捗管理の機能概要にも「利用者が」って書かれてるので管理者は進捗管理のページ見る想定されていませんし、ロール管理機能の備考見てもパスにget送れば権限見ずstate返してるようなので管理者である必要はないハズです。

> SASTはヒントで、DASTだよなーとは思いますが、違ってたら、罠すぎますが・・・

SASTで静的にコードチェックするから動的な確認だよなーそしたらDASTか。と思ったのですが、診断ツールXがDASTの可能性あるかも？という疑念が振り返ってて湧いてきています。。。

> 問3(1)h エクセルやワードが触れられているので、スクリプトやマクロが含まれていないか確認する、としてしましました…

それが正解かもしれないです。
私の回答は回答欄にギチギチになってしまったので、IPAの想定する回答ではないと思いますｗ

> 最後はペネトレーションテストについて書いたけど違いそう…
> SASTは中身のコードを分析する静的な調査だから、もう一個なんかやるなら実際に攻撃のシミュレーションするのが良くね？って思ってしまった

上でも書いたのですが、私も静的調査はSASTでするから動的なものをーと思って、SATに引っ張られてDASTと書いてしまいましたが、ペネトレーションテストの方が可能性あると思います。

「診断ツールXは送信したリクエストとそれに対するレスポンスから脆弱性を検出する」とあるので、多分、書かせたいのはHTTP通信に現れない挙動に含まれる脆弱性を見つけることだと思います。DASTだと診断ツールXとかぶってしまう気がするので、ペネトレーションテストか、ワンチャン可能性あるのはSCAな気がしています。。。

さすがに管理者だと思う
利用者の権限でできるならこんな回りくどい方法をつかわずに、
自分の権限でログインして直接リクエスト投げればいい

診断ツールXが検知できなかった理由は、今回の攻撃が格納型XSSで、リクエストとレスポンスだけ見ても検知できなかったことが原因だと思いました（この偽装エクセルが格納された状態の環境でテストすれば検知したとはおもいますが、テスト時の環境は別だと思うので）。ただDASTでそれが対応できるのか不明です…。格納するファイルまでテストケースとして網羅して検査してくれるものなんですかね…？

> 表１のプロジェクト進捗管理の機能概要にも「利用者が」って書かれてるので管理者は進捗管理のページ見る想定されていませんし、ロール管理機能の備考見てもパスにget送れば権限見ずstate返してるようなので管理者である必要はないハズです。

私もこの脆弱性があるのであれば、利用者ロールで直接/management/roleにブラウザからアクセス可能になっちゃうので、それはないのでは？という気がしています。
もしこの脆弱性が残っているなら、図4項番5においても脆弱性があることになるので、[インシデントへの対応及び攻撃への対策]で何も対策されないのはまずいですね。
加えて、Uさんが調査する際にB社の管理者の利用者IDを使ってログインして確認しているので、調査結果として記載するならばeは管理者でもいい気がします。

設問1

a：できない
Content-Security-Policy: default-src 'self'; の設定により、すべてのリソース（画像、スクリプトなど）の読み込み元が自サイト（'self'）に限定されます。

b：できない
default-src 'self' の設定は、インラインスクリプト（<script>タグ内に直接記述されたスクリプト）の実行を許可しません。インラインスクリプトの実行を許可するには、'unsafe-inline'などを追加する必要があります。


設問2
(1) 図3のスクリプトは、表1中のどの機能を悪用するものか、機能名を答えよ。

ロール管理
図3のスクリプトは、自身のロールを管理者（is_admin: 1）に変更するために、ロール管理機能の一部であるパスmanagement/roleへのGETリクエストと、パスmanagement/rolesetへのPOSTリクエストを送信しています。


(2) 図4中のcに入れる適切なタスクの項目を、表1中の字句を用いて答えよ。
タスク名
図2のHTMLの構造から、悪意のあるスクリプト（script src="/files/F1234567890.xlsx"></script>）が埋め込まれているのは、タスクの一覧が表示される部分です。具体的には、タスク名として登録された文字列がそのままHTMLに出力され、スクリプトとして解釈されています。したがって、悪用されたタスクの項目はタスク名です。

(3) 図4中のdに入れる適切な文字列を、図2から抜き出して答えよ

個人タスク<script src="/files/F1234567890.xlsx"></script>

図2のHTMLの該当箇所は以下の行です。
HTML
<li>個人タスク<script src="/files/F1234567890.xlsx"></script>（締切日過ぎ 5日）</li>
この行は、「タスク名」として登録された文字列がHTMLエスケープされずにそのまま出力された結果、WebブラウザによってHTMLタグとして解釈されたものです。したがって、登録されたタスク名は、表示されたタスク名と注入されたスクリプトタグを組み合わせたものと考えられます。

(4) 図4中のe、f、gにいれる適切な字句を答えよ。

記号 適切な字句 理由
e 管理者 
図3のスクリプトが悪用するのはロール管理機能であり、この機能にアクセスできるのは管理者のみです（表1「利用者管理」「ロール管理」）。また、インシデントは「元従業員Zが割り当てられていなかったプロジェクトのファイルが保存されていた」ことであり、攻撃が成功した結果、元従業員Zのロールが管理者になったと推測されます。
f 締切日を過ぎたとき 
図2はプロジェクト進捗管理画面であり、その機能概要（表1）には「未完了のタスクのうち締切日を過ぎたものは、プロジェクト進捗管理画面にそのタスク名と締切日からの経過日数が表示される」とあります。攻撃が成功するには、タスクがこの一覧に表示される必要があります。
g ロールが管理者に変更された 
図3のスクリプトは、パスmanagement/rolesetに対してis_admin: 1を指定してPOSTリクエストを送信しており、これは利用者IDU00331001（元従業員ZのID）のロールを管理者に変更する処理です。

(5) 本文中の下線①について、工夫の内容を、具体的に答えよ。
類似した文字列による攻撃がCSPの設定で防御できていた、ということは、失敗した攻撃はインラインスクリプト（例：<script>alert(1)</script>）を実行しようとしたと考えられます。なぜなら、設問1で確認した通り、現在のCSP設定（default-src 'self'）はインラインスクリプトの実行を防御できるからです。

一方、成功した攻撃（図4）では、悪意のあるスクリプトをアップロード済みのファイル（F1234567890.xlsx）に記述し、<script src="...">タグを使って外部ファイルとして読み込ませる形にしています。このタグの読み込み元はSサービス内のパス（/files/...）であり、CSPのdefault-src 'self'によって読み込みが許可されます。

したがって、工夫の内容は以下の通りです。
インラインスクリプトではなく、スクリプトを記述したファイルをアップロードし、そのファイルを<script src="...">タグで読み込む形式に変更した。

設問3
[インシデントへの対応及び攻撃への対策]に関する回答は以下の通りです。
(1) 本文中のhにいれる追加すべき処理の内容を、具体的に答えよ。
図4の攻撃では、拡張子が.xlsxのファイルにスクリプトを記述し、そのファイルがスクリプトファイルとして実行されることを悪用しています。これを防ぐには、ファイルの内容が拡張子と一致しているか、または危険な内容でないかを確認する必要があります。

アップロードされたファイルの実体（内容）が、許可された拡張子のファイル形式と一致するかを検証する。（例：マジックナンバーの確認）

または、ファイルの内容をスキャンし、HTMLやスクリプトとして解釈される可能性のある文字列**（例：<script）が含まれていないかを確認する。

(2) 本文中のiに入れる適切な機能名を答えよ。
プロジェクト進捗管理
図4の項番4で脆弱性となったのは、タスク名として入力された文字列がHTMLエスケープされずにプロジェクト進捗管理画面に出力されたことです。これは、表1の機能のうち、タスクの進捗状況を表示する機能と関連しています。

(3) 本文中の下線②について、追加すべき処理の内容を、具体的に答えよ。
攻撃が成功したのは、タスク名に含まれる<や>などの特殊文字がHTMLタグとして解釈されたためです。これを防ぐには、HTMLに出力する前にこれらの特殊文字を無害化する処理が必要です。

タスク名など、利用者からの入力データをHTMLに出力する際に、特殊文字（<、>、"、&など）をHTMLエスケープ処理する。

設問4
本文中のjにいれる適切な検査方法を、具体的に答えよ

SAST（Static Application Security Testing：静的アプリケーションセキュリティテスト）は、実行せずにソースコードを分析する手法です。SASTで検知できない実行時の脆弱性を検知できる検査方法として、動的解析手法が挙げられます。

DAST（Dynamic Application Security Testing：動的アプリケーションセキュリティテスト）

または
ペネトレーションテスト（侵入テスト）
I AST（Interactive Application Security Testing）

＞生きたかったさん(No.55) さん

正解だといいんですが。でも権限確認（認可制御）の不備自体がかなり大きな問題（脆弱性）なので、もしほんとに一般ユーザーでも変更できちゃうなら、文章中でもっと言及していないとおかしいな、と思ったりしています。ありがとうございました。

設問1  a できない
  b できる
設問2 
 (1)  スレッド管理 ←やらかした
 (2) c タスク名
 (3) d 個人タスク<script src="/files/F1234567890.xlsx"></script>
 (4) e B社の管理者
  f タスクの締切日が過ぎたものであること
  g 管理者のロールが設定された
 (5) ① src="/files/F1234567890.xlsx" とCSP default-src 'self' を認める文字列にしたこと
設問3 (1) h アップロードされたファイルの内容が実行可能なスクリプトである場合拒否する処理
 (2) i プロジェクト進捗管理
 (3) ② 入力された値をサニタイズしてスクリプトを無効化する処理
設問4  j ー

深読みしてファイルのタグが書けるのは仕様で、ロール管理が利用者も出来ることが問題点と指摘してしまった😱
素直にエスケープ処理が必要って書いておけば良かった
解けたはずなのに半分くらい落としてる

解答を共有したい人向けに
簡易のフォーマットをコメントしておきますね

設問1
a

b

設問2
(1)

(2)
c

(3)
d

(4)
e

f

g

(5)


問3
(1)
h

(2)
i

(3)

問4
j

合っててくれー
設問1
a
できない
b
できる

設問2
(1)
ロール管理

(2)
c
タスク名

(3)
d
個人タスク<script src="/files/F1234567890.xlsx"></script>

(4)
e
管理者
f
締切日が過ぎる
g
管理者のロールに変更する

(5)
攻撃を行うスクリプトをxlsxファイルとしてアップロードし、HTML上から呼び出す。

問3
(1)
h
拡張子に対応するソフトでファイルを開くことができ、
HTML上でスクリプトを実行できないことをチェックする。

(2)
i
プロジェクト進捗管理

(3)
スクリプトを実行する文字列にエスケープ処理を行う。

問4
j
脆弱性を引き起こすパラメータを入力し、手動でテストを行う。

問3こんな感じで回答しました。
人によって回答する観点が違って難しいですね。

問3
(1)
h
アップロードしたファイルの名称を推測困難であるランダムな文字列に変換する

(2)
i
プロジェクト進捗管理

(3)
リクエスト内のuser_idが管理者のものであることを確認する処理

問1 aできない、bできない
問2（1）ロール管理
（2）タスク名
（3）個人タスク‹script src="/files/F1234567890.xlsx"›‹/script›
（4）e管理者
fタスクの締切日を過ぎた状態
gロールを管理者に変更する処理
問3（1）ファイルヘッダをみて、ファイル名の拡張子の種類のファイルか確認する処理
(2)プロジェクト進捗管理
(3)タスク名に対してHTMLエンコードした上で表示する
問4セキュリティ有識者によるペネトレーションテスト

問4はDASTと迷った上で診断ツールxで検知されないという点を加味してペネトレにしました。

No.60、No.61の方の解答が1番しっくりくる……。
勉強になる……。

6割あればいいですからね...

設問１
a:できない（SAMEORIGINだから）
b:できない（できたらわざわざファイルに書かないというメタ読み）

設問２
(1)ロール管理
(2)タスク名
(3)個人タスク＜script～/script＞
(4)e:B社の管理者
    f:ロール管理にログイン済であること（CSRFトークンが必要だから）
    g:管理者のロールがセットされた
(5)sctiptタグに直接処理を記載せず、slsxファイルに記述した。

設問3
(1)hテキストデータとして開いてscriptとして動作するか検証する
(2)スレッド投稿(問題があったのがタスク管理機能で、類似ってことなので他に入力がありそうなところはここかなと)
(3)入力された文字をサニタイジングする。

設問４セキュリティ専門企業に、経験を活かした人力のテストを実施してもらう。
   （自信なし）

3-(2)、４以外は割と手ごたえありなんですがどうでしょう・・・

>むりむりかたつむりさん 
>  f:ロール管理にログイン済であること（CSRFトークンが必要だから）
空欄eの前に「タスクが次の条件を満たしたときに、」とあるので、条件はタスクに対する条件だと考えられます。

タスクの締切が過ぎてるって自分もちょっと思ったんですが、未完了かつって書いてあるし、
未完了のタスクも表示されてないとダメだよなって思って考え直したんですよね。

＞No.72さん
確かに、タスクがって書いてました・・・
深読みしてしまった・・・

設問4外部の専門業者は、アウトでしょうか？

DASTはXSSを検知できると書いてあるサイトが多いので、DASTかと思いたい。ツールXで、レスポンスみるだけではダメで。

3-2について、
「なお、この処理が行われていないという脆弱性は、診断ツールXでは検知されない」
とう記述がわざわざ記載されているので、
エスケープするという回答を除外させたいのだと思いました。

診断ツールXを使ったレスポンスをみたらエスケープされているかどうかわかるはずなので。

受かりたいさん
診断ツールXは送信したリクエストとそれに対するレスポンスから脆弱性を判断するとあります。
プロジェクト進捗管理画面単体ではおそらく入力してそれが表示されるものがないので検知できないのではと思ったんですがどうでしょうか？

今回のパターンはタスク管理で文字列を仕込んで、それをプロジェクト管理画面で実行させるというように画面をまたいでいるのでリクエストレスポンスだけでは検知できないのではと思いました。

プロジェクト管理→プロジェクト進捗管理

設問１
a:できない
b:できる
 （scriptタグ内を＜script＞～＜/script＞ではなく＜script "ｺｺ"＞だと思い込んで
  「scr="略"が発動してるからできるじゃん」と最初「できない」と書いたのに
  「できる」にしてしまった…）

設問２
(1)ロール管理機能
(2)タスク名
(3)個人タスク＜script 中略＜/script＞
(4)e:B社の管理者
   f:元従業員Zも管理者も担当しているタスク
   g:元従業員Zが管理者として設定された
(5)sctiptタグ内でソースファイルを参照する形でスクリプトを読み込ませた

設問３
(1)h X-Content-Type-OptionsでMIME形式を指定する
（たぶん求められる回答は「サービスSのレスポンスヘッダに
  X-Content-Type-Options: nosniffを設定する」だと思います。
  図1で全レスポンスヘッダを挙げられてたのもそれが理由かと。
  X-Content-Type-Optionsヘッダを問うてる問題だとひらめいたものの
  ちゃんと覚えてない上、気が動転して"ヘッダ"の文言まで忘れてた…）
(2)タスク管理機能
   (「類似の問題がないかどうかSサービス全体を確認したところ」という文を
     理解せずに「1箇所だけだった」をタスク名入力だけ脆弱性があったと誤読。
     スレッド投稿機能のことを言っていたのだと掲示板で理解)
(3)利用者が入力した文字列の特殊文字にエスケープ処理をほどこす

設問４
  X-Content-Type-OptionsでMIME形式を指定する
  (1つ前がSASTなのでDASTか…？と思ったものの解答欄が広いので何を
    答えたらいいのかわからなくなりどっちか正解してくれと
    設問3 (1)と同じ回答を書く)

落ち着いていれば正解できたも問題も気が動転して細かい取りこぼしが多い…

最後のところは、中核人材育成プログラムの脆弱性診断の内製化で触れている部分がヒントだと思います。

具体的には自動ツールで見つけられないものは、手動で診断する必要があるというお話です。
今回のようにタスク管理で入力されたものが、直接的なつながりのないプロジェクト進捗管理で発火しているので、過去問でも繰り返し脆弱性診断のたびに触れている話題がそのまま答えだと思いました（つまり手動で補完する必要があるということです）

格納型XSS、CSRF、MiMEスニッフィング攻撃の複合であり、ツールXはDASTのようにリクエスト送信して動的検査しているが見つけられなかった。こんな風に理解できれば高得点狙えた感じかな。自分は無理でしたが。

最後の問題、何かしら書かねば…と思い
スクリプトタグを含む値がDBに登録できないことと、登録されたものを画面表示できないことを確認する
というアナログな内容を書いてしまった

皆さんの意見を合わせて正しそうな回答を載せてみます。

設問１
a:できない
b:できない

設問２
(1)ロール管理
(2)タスク名
(3)個人タスク‹script src="/files/F1234567890.xlsx"›‹/script›
(4)e:B社の管理者
    f:タスクの締切日を過ぎた
    g:管理者のロールを設定する
(5)（インラインスクリプトを実行させたり、）Sサービス外のスクリプトファイルを読み出す記述ではなく、Sサービス内にスクリプトファイルをアップロードしそれを実行する記述にした。（ここに関しては出題者の意図としては、インラインスクリプトよりも同一オリジンの話を読み取ってほしいように思う。）

設問3
(1)アップロードされたファイルの実体（内容）が、許可された拡張子のファイル形式と一致するかを検証する。
(2)プロジェクト進捗管理
(3)タスク名など、利用者からの入力データをHTMLに出力する際に、特殊文字（<、>、"、&など）をHTMLエスケープ処理する。

設問４ペネトレーションテストでセキュリティ専門家によって実際に攻撃を仕掛ける。（DASTは診断ツールXですでに実施済み。表面的な脆弱性しか検出できず、今回のような複合の攻撃を見つけられない。）

設問４、普通のDASTツールなら、単一画面のレスポンスだけじゃなく、他の画面の影響含め検査できると思うんですが
どうなんでしょうか、
クローラーが見つけられないページではないですし

あざさん
うーん、どうなんですかね、、、
すでに診断ツールXを使用しているのに追加でまたDASTを実施するっていうのは問題としてどうなんだというところと、
今回みたいにタスクが未完了で締切日を過ぎたものじゃないと画面に出てこないようなものを検出できるDASTツールがあるのかというところからペネトレーションテストかなと思いました。

問4は色々議論あるようですが
問3(1)がわかる偉い人解説お願いします
自分は全く分からず
テキストとして読み込んだときスクリプトが含まれるか検査するみたいに書きました

すみません。
設問3の(2)ですが、「スレッド投稿機能」が正しいのですか。
私も「スレッド投稿機能」と書きました。
ただ、次の問いの⑶では、「管理者もアクセスできるようにする」と書きました。何故なら、「スレッド投稿機能」だけ管理者がアクセスできないからです。

>> No.88
設問3の(2), (3)は格納型XSSが発動する箇所と、そこでの防護措置を回答するものと思われます。

> 図4の項番4について、 ～

図4の項番4は「図2のHTMLが表示された」ってトコなので。
というわけで「プロジェクト進捗管理」が正答だと思われます。

必要な対応は「HTMLとして意味を成す文字列を単なる文字列として解釈させること」。
つまりエスケープとかサニタイズとか、そのへんの処理になると思います。
僕は「HTMLサニタイズを実施する」としました。言葉足らずなので「表示されるHTML中の文字列に対し～」とか、何かしら足せてれば安心だとは思います。

問3(1)はすでに出ている通りMIMEタイプに着目する解答が正解なんじゃないかと。
X-Content-Type-OptionsをnosniffにしてMIMEスニッフィングをさせない。
的な答えでしょうか。
見た目はxlsmファイルですが実体はJavaScriptのため、MIMEスニッフィングによりscriptだと判定されて実行されてしまったというお話だったと思うので、
「アップロードされたファイルが許可された拡張子であ ることのチェックに加えて…」
の続きとして、ブラウザが勝手にMIMEタイプを判定してしまうのを防止する必要があると言うことを記述させたいのだと思います。

No87さん
色々調べてみました。
私も詳しくはないですので参考程度にしてください。

「前提1」
拡張子が .xlsx でも、**中身がスクリプトであり、サーバーがそれを JavaScript として配信している（Content-Type が text/javascript など）**なら、実行される可能性があります。

逆に、

サーバーがそれを正しく Excel ファイル（application/vnd.openxmlformats-officedocument.spreadsheetml.sheet）として配信していれば、ブラウザはスクリプトとして実行しません。

「前提2」
多くのウェブサーバ／アプリは拡張子→MIME のマッピング（mime.types や言語ライブラリの mime.guess）で Content-Type を決めますが、その実装を誤ると（＝ユーザ入力をそのまま使う・チェックしない）攻撃者が偽装できる余地が生まれます。

「前提からの考察」
問題文において、現状は攻撃が成功していることから前提2のチェックをせずにアップロードを許可しているので、拡張子が.xlsxならファイル実体もエクセルファイルであるかをチェックすることで攻撃を防げるようになります。

「補足」
スニッフィング禁止という回答も候補としてあると思います。
X-Content-Type-Options: nosniff は、ブラウザが「中身を見て JS かもしれない」と判断して実行することを防ぐものです。
しかし、サーバーが text/javascript を返している場合はスニッフィング禁止を付けても関係なく実行されます。
→ つまり「Content-Type が JS なら拡張子 .xlsx でも実行される」ということから、アップロード時のファイルチェックが一番有効だと考えました。

> 87
> 問3(1)がわかる偉い人解説お願いします
「ファイルの内容と拡張子が表すデータタイプが食い違っていることを確認する」だと思います。
アップロードできるファイルも画像とOffice系ファイルの7種類だけなので妥当かなぁと思っています。

割と定番な問題だと思います。
https://www.ipa.go.jp/archive/security/vuln/programming/cc/chapter9/cc9-4.html

最初のSサービス概要部分に
「利用者には2種類のロールがある。」「（略）管理者と（略）一般利用者である。」
とあるので表1の「利用者」は管理者と一般利用者の両方を指しているはずです。
そこを勘違いしてしまっている人も多そうですね。

かくいう私はSASTが静的解析テストってことがわからずにSASTの事を解答してしまいました...
勉強不足が出ましたね...
模範解答はDASTだと思います。
「半年ごと及び新機能リリース前に診断ツールＸによる脆弱性診断を実施することにしている」とあるのでコスト面や対象範囲という点でペネトレではなくDASTが妥当という判断です。

ファイルタイプのチェックとして、アップロードできるファイルの拡張子は, docx, xlsx, pptx, pdf, jpg, gif 及び png の 7 種類である。

でもContent-Typeがtext/javascriptの場合、拡張子は.jsって事になりませんか？
インラインで呼ぶ場合もCSPで阻止されているからこその回避策ですし。

No93さん
反応ありがとうございます。
私の認識ではファイル拡張子が.xlsxでもContent-Typeをtext/javascriptに偽装できるものと思っていますが間違ってますかね？

DASTについてですが、格納型XSSを見つけるのには不適切じゃないかな？と思ってます。
SASTとDASTを組み合わせるのは定番だと思いますが、「図4の項番4の脆弱性のように診断ツールXで検知されないものであっても、検知できる可能性のある検査として…」という前置きがあったので、格納型XSSを見つけるための方策だと思いました。
なので、SASTと手動による脆弱性診断じゃないかな？なんて思います。

以下はAI出力で恐縮ですが、格納型XSSとDASTの相性について論じてもらいました。
”格納型XSSは、特定のユーザーグループ（例：管理者）にしか表示されない管理画面や、特定の条件でのみ表示されるログなど、アプリケーションの深い階層や特定の機能に潜んでいる場合があります。
DASTツールがすべてのシナリオを網羅し、ユーザーの権限レベルや特定のワークフローを模倣してテストすることは非常に困難です。”

この投稿は投稿者により削除されました。(2025.10.14 23:40)

私のほうが誤っている事に気が付きました。
nosniffではなく、MIMEタイプを明示的に指定してチェックするほうが正解だと思います。

>No95
「手動による脆弱性診断じゃないかな」とのことですが、DASTでも手動で診断できたのでは？
知識不足な初学者なので、ご了承下さい。

設問4はNo95の内容で基本的には私も考えてます。
DAST，ペネトレあたりは正直言葉の定義なので難しいところですが、DASTはツールのイメージが強いので「ツールだけじゃ無理、攻撃者の視点を持って悪用できる方法はないかを探す。」ということをした上でじゃないと今回のようなものは検知できないかなと思って、ペネトレの方が定義に近いと思いました。

>No.98
私の先入観による勘違いでした。
ZAPのようなツールでクローリングするのをDASTだと思っていた節があったので、今度先輩に怒られてきます…

設問1
a:できない
- 理由：図１の HTTPレスポンスヘッダに "SAMEORIGIN" の記載がある
b：できる
- 理由：埋め込み script で攻撃に成功しているから

設問2
(1):ロール管理
- 理由：図3 の.XLSX ファイルで admin 権限のフラグを 1 に設定を試みているから。

(2)：
c：タスク名
(3)：
d：<script src="/files/F1234567890.xlsx"></script>

(4):
e：管理者
f：タスク締切日を過ぎた
g：admin 権限付与

(5)：HTTPOnly の環境下でスクリプトを用いて HTTP リクエストを送信するために fetch で HTTP リクエストを生成した。


問3
(1)：
h：不正なスクリプトを検知する

(2)：
i：ロール管理

(3)：
ログイン後、ロール管理画面への GET リクエストを禁止する

問4：
j：SBOM を導入してソフトウエアの依存関係を可視化し、脆弱性のあるパッケージを検出する。

> 101
おー、問3 (2) ロール管理の人がいましたね。

私もそうしたんですよね。。。csrf_token対策がないのかなーと思って、ロール管理画面では一般利用者にcsrf_tokenを発行しないとか、そういう理由にしましたが。

みなさん！！！60点取れればいいんですよ！！！！

しかし、この午後の問1だけ他の大問より明確に問題ページ数が少ないのに、大問の中で一番選ばれてないということは、よほど情報処理安全確保支援士を受験する皆さんはHTMLとECMAScriptが苦手なんでしょうね…

> No.104
コード(HTMLとScript)の量は多くはないし、画面遷移もないから例年のWeb問題よりとっつきやすいと思ったんですが、選んだ人少なくてびっくりです。

最後の設問以外は正誤がはっきりしてるので、感覚通り採点結果になりそうだなー

ITECは解答速報出ましたね

設問４の回答の解像度が低い
セキュアコーディングしたことないんじゃないかな

こんな属人的な方法に頼るのをIPAは解答とするのかな

設問２の（e）って利用者じゃなくて管理者なんですね。itecもTACも管理者になってました。
現実問題だと管理者しか変更できないのは当たり前ですが、管理者しか変更できない設定になってると書いてなくて利用者にしちゃいました。

ITECもTACもペネトレーションテストって字もDASTって字もなくて「へ…？」って感じ

ペンテストで点数くれないかな…

でもペンテストって脆弱性診断をもっと踏み込んでやるやつですよね
とすれば、診断ツールでも見つからないものをより踏み込んだペンテストで探すっていうのは、✕にする理由がないと思うんですよね

気休めですが…

>111
うん、期待したい‥モヤモヤするけどクリスマスまで待ちますかね。。。

私なんか、設問２の（e）は「攻撃者」としてしまいました。

最後のやつ、「開発プロセスにて行う」「脆弱性診断ツールで見つけられない脆弱性も見つける」って調査について書くのがポイントなのかなと思ったが…
とすると、ITECの書いてるIAST、エージェントは診断ツールと見なされて後者に該当しなくて微妙なような
どちらかというとペネトレーションの方が当てはまるような…
ただ、ペネトレーションは開発プロセスに入るにしてもリリース直前で、狭義の開発プロセス(実装まで)には含まれないから、開発プロセスは開発プロセスでも狭義の開発プロセスですっていうならこれも怪しくなるか
TACのセキュアコードレビューが確かにまぁ、一番合うのか…

最後のやつ、リリース前に手動の脆弱性診断を外部業者に頼めばいいじゃんって思いましたけどね。
実際現場ではそうですし。
脆弱性診断は手動実施のプランとツール実施のプランがあるので、手動のやつを実施して貰えばこの手の脆弱性は指摘結果として還元されますね。

元従業員のアカウントが使用できるのって大した問題ではないのでしょうか。。。

元従業員が従業員時代にこの攻撃を仕掛けて本来閲覧できないプロジェクトのファイルを閲覧していたんだと思います

退職が決まった時点で退職者のアカウントは停止してない（
弁護士の島田直行とかは退職日でなく退職申請が出た日即日やるように日経に書いてたが、個人的には最終日でいいと思っている
）と、後々いまはやりのリベンジ退職とかろくなことにつながらないですね。放置してる会社も多いですが、他人はろくなことをしないという前提の元動かないと足下をすくわれます。
それ自体は問題にならないが、実際の問題に繋がる機会を与えている点では問題ですな。

>りんりんさん(No.115)
>リリース前に手動の脆弱性診断を外部業者に頼めばいいじゃん

実際、そういうテーマの問題が過去にもありましたし、解答例の一つとしてか、あるいは正解として採用されてそうですよね

> 117

> 元従業員が従業員時代にこの攻撃を仕掛けて本来閲覧できないプロジェクトのファイルを閲覧していたんだと思います

なぜ、元従業員のPCに例のxlsxあったのか、ずっとモヤモヤしてましたが、そういうことか。

色々調べたけど、セキュアコードレビューいいんならペネトレもいけるだろこれ！？って気持ちが強まったぞ
俺は勝った、そうに違いない、そうに違いないんだ…
安心して眠るぞ…