URLについて質問させてください。

模範解答はアンケート入力１からアンケート入力２に遷移するURLの拡張機能に、アンケート確認のURLを登録するでした。
私は「アンケート入力１のURLの拡張機能設定画面に、アンケート確認のURLを登録する」と考えました。「アンケート入力１からアンケート入力２に遷移するURL」と「アンケート入力１のURL」は別モノ、別概念なのでしょうか。

図１の（２－３）にある拡張機能の設定手順説明では「診断対象のURLの拡張機能設定画面に…」とあり、診断対象は「アンケート入力１画面」ではないかと思いこの解答としました。

本問の説明は複雑になってしまいました。分かりずらいと思いますが、すみません。

>「アンケート入力1からアンケート入力2に遷移するURL」と
>「アンケート入力1のURL」は別モノ、別概念なのでしょうか。
本問の観点からすると別物になります。
本問のURLには2種類あると考えてください。
・「アンケート入力1のURL」とはアンケート1【画面】のURL
・「アンケート入力1からアンケート入力2に遷移するURL」とは
  アンケート入力1画面からアンケート入力2画面の間の【矢印（→）】を
  表しています。

具体的には
・「アンケート入力1のURL」：パラメータがついていないアンケート入力1のURL
・「アンケート入力1からアンケート入力2に遷移するURL」：アンケート入力1で
  入力されたパラメータがついている、アンケート入力2のURL
です。

本問はP7「入力したスクリプトが【二つ先の画面】でエスケープ処理されずに
出力されていました。」
という文章の【二つ先の画面】を正確に把握する必要があります。

この【二つ先の画面】とうのは
「アンケート入力1」画面から見た「アンケート確認」画面のことです。

本問はDASTツールの動作がイメージできるかどうかがポイントと思われます。
DASTツールの基本動作は
・入力したデータ（GET,PUTしたデータ）
・出力されたデータ（サーバから返ってきたデータ）
の2つを比較します。
比較の結果、
・不正な結果が返ってこなかった（XSS対応済）
・不正な結果が返ってきた（XSS未対応）
を判定します。

・検査対象URLに「アンケート入力2からアンケート確認に遷移するURL」を設定した場合
  【入力:アンケート入力2からアンケート確認に遷移するURL】
    ->【出力:アンケート確認】が比較・検査される
これは正常に検査されています。

しかし、
・検査対象URLに「アンケート入力1からアンケート入力2に遷移するURL」を設定した場合
  【入力:アンケート入力1からアンケート入力2に遷移するURL】
    ->【出力:アンケート入力2】が比較・検査される
これは意図した結果が得られません。なぜなら、
「アンケート入力1」->「アンケート入力2」に画面遷移しただけでは、まだ
アンケート項目の入力が全て完了していないからです。
【入力:アンケート入力1からアンケート入力2に遷移するURL】の結果が出力されるのは
【出力:アンケート確認】まで画面が遷移しないとだからです。

そのために(2-3)の診断対象URLの拡張機能を利用します。
検査対象URL：「アンケート入力1からアンケート入力2に遷移するURL」の判定対象として
二つ先の画面である「アンケート確認」を登録します。
これにより途中の画面遷移により「アンケート入力2」を挟んだとしても、
【入力:アンケート入力1からアンケート入力2に遷移するURL】
  ->【出力:アンケート確認】を
比較・判定できるようになります。

pixさま
いつも大変わかりやすい解説ありがとうございます。

＞DASTツールの基本動作は
＞・入力したデータ（GET,PUTしたデータ）
＞・出力されたデータ（サーバから返ってきたデータ）
＞の2つを比較します。

という説明でハラ落ちしました。DASTツールの動作がイメージできるかどうかがポイントと記載いただいているとおり、私はDASTツールの動作をイメージできていませんでした。
入力したデータとの比較対象であるとするならば、画面を示すURLではなく、last_name,first_name,memberといったパラメータを含んだURLでないないと意味がない、したがって「アンケート入力１のURL」とするのは誤りである旨納得しました。

DASTツールの動作がイメージできていないという観点で、追加で質問させてください。
設問３に関連する内容です。

図１DASTツールの機能概要においてDASTツールは「パラメータを初期値から何通りもの値に変更したHTTPリクエストを順に送信し、応答から脆弱性の有無を判定する」とあります。
下線⑤では特定のパラメータが同じ値であるリクエストを複数回送信するとエラーとなり、遷移できない箇所がある、とあります。
Y氏の懸念は「特定のパラメータが同じ値であるリクエストを複数回送信」なのですが、機能概要では「何通りもの値に変更したHTTPリクエスト」とあるので「パラメータは同じ値ではないはず」と思いました。この箇所を見る限り、Y氏の懸念は当てはまらないのではないかと思いましたがいかがでしょうか。概要に記載していなだけで、DASTツールは「特定のパラメータが同じ値であるリクエストを複数回送信」を送るのはあたりまえで、DASTツールの知識を問う問題ということなのでしょうか。

>Y氏の懸念は「特定のパラメータが同じ値であるリクエストを複数回送信」なのですが、
>機能概要では「何通りもの値に変更したHTTPリクエスト」とあるので「パラメータは同じ
>値ではないはず」と思いました。
1画面遷移するURLに付与されるパラメータの数は1つとは限りません。
通常であれば複数個（5、6個）引き渡されるでしょう。
DASTツールでリクエストを送る場合、送る都度全てのパラメータを変化させるのではなく、
１つのパラメータを何通りにも変化させ、それを別のパラメータにも行っていくような
動作を想像できます。

その場合、いくつかのパラメータは前と同じになってしまうので、攻撃とみなされ
サーバ側でエラーにされる可能性が考えられます。

これはDASTツールの知識というよりは、本問の文章からサーバ・DASTツールで
なにが起こっているのかをイメージできるかにかかっています。

もし、このあたりについて学習したいのであれば、
「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」：徳丸本
を読んでください。

pixさま
ありがとうございます。
まだ十分理解できないので、問題文に引き寄せて、再度質問させてください。

具体的に模範解答にある（C）キャンペーンは１会員につき１回しか申し込みできないから
の例では、「パラメータ」はどのようなもので、どういう形で投入されるものをイメージすればよいのでしょうか。

>「パラメータ」はどのようなもので、どういう形で投入されるものをイメージ
>すればよいのでしょうか。
リクエストはGETかPUTしかありません。
PUTはパラメータがみえないので、GETの例を挙げます。
パラメータ名は適当です。
GET https://サイトM/キャンペーン/キャンペーン申込完了.html?group_code=001&kaiin_id=1234&campaign_id=333 HTTP/1.1
パラメータに"kaiin_id"があるため、同じ"kaiin_id"で同じ申込はできないと
想定します。

pixさま
返信ありがとうございます。pixさまの記載にある「 “kaiin_id"があるため、同じ"kaiin_id"で同じ申込はできない」ということは私も問題文から読み取りました。これは仕様であり正常な動作と理解しています。
下線部⑤にある表現をpixさまから頂いたパラメータの例に当てはめると「kaiin_idが同じリクエストを複数回送信するとエラーになり、…」となるわけですが、ここが理解できない部分です。エラーを起こしたわけではなく、正常な動作として「キャンペーン申し込み完了画面には遷移しない」と理解していますがいかがでしょうか。
また「適切な診断を行うために、ツールＶの拒否回避機能を設定して」と問題文はつづきます。「kaiin_idが同じリクエストを複数回送信し、２回目以降でもキャンペーン申し込み完了画面に遷移すること」を確認できたとして、これは適切な診断をしたと言えるのでしょうか。「同じkaiin_idではキャンペーン申し込み完了画面に遷移しない」というテストができていないと思いましたが、いかがでしょうか。

>「kaiin_idが同じリクエストを複数回送信するとエラーになり、…」となるわけ
>ですが、ここが理解できない部分です。エラーを起こしたわけではなく、正常な
>動作として「キャンペーン申し込み完了画面には遷移しない」と理解していますが
>いかがでしょうか。
以下の概念を混同しているように見受けられます。
・エラー：その名の通り、失敗を意味します
・異常：ソフトウェアでハンドリングできなかったエラー
・順正常：ソフトウェアでハンドリングできたエラー

以下の2つはソフトウェア的にハンドリングされておりますので、両方とも
順正常と考えられます。
・「kaiin_idが同じリクエストを複数回送信するとエラーになり、…」
・「キャンペーン申し込み完了画面には遷移しない」
片方がエラーで片方が正常というのはエンジニアリング的に曖昧な区分です。


>「同じkaiin_idではキャンペーン申し込み完了画面に遷移しない」というテストが
>できていないと思いましたが、いかがでしょうか。
本問の意図は脆弱性診断です。
「同じkaiin_idではキャンペーン申し込み完了画面に遷移しない」というのは
ソフトウェアの機能実装の問題です。この機能はソフトウェアの段階で
単体テスト、結合テストフェーズでテストされる項目です。
脆弱性診断でテストされる項目ではありません。

pixさま
ありがとうございます。

＞「同じkaiin_idではキャンペーン申し込み完了画面に遷移しない」というのは
＞ソフトウェアの機能実装の問題です。この機能はソフトウェアの段階で
＞単体テスト、結合テストフェーズでテストされる項目です。
について、なるほどと思う一方、やはり少し疑問が残ります。

もう一つの正答についてはいかがでしょうか。画面遷移（Ａ）で、理由は「同じアカウントで連続５回間違えるとアカウントがロックされるから」とあります。連続して間違える回数が６回目となるとアカウントロックされるのは準正常だと思いますが、アカウントロック機能が適切に動作するかどうかも「脆弱性テストの範疇のテストには該当しない、本テストで確認できなくてよい」と判断するのでしょうか。

>画面遷移（Ａ）で、理由は「同じアカウントで連続５回間違えるとアカウントが
>ロックされるから」とあります。連続して間違える回数が６回目となると
>アカウントロックされるのは準正常だと思いますが、アカウントロック機能が
>適切に動作するかどうかも「脆弱性テストの範疇のテストには該当しない、
>本テストで確認できなくてよい」と判断するのでしょうか。
アカウントロックは「不正なアクセス」を防止する機能であり、ソフトウェア
要件における準正常です。

しかし、ここでの脆弱性診断の目的は「SQLインジェクション」の検査です。
脆弱性診断のアクセスが「不正なアクセス」とみなされ、アカウントロックされて
しまっては、想定する画面遷移ができなくなり、脆弱性診断に支障が生じてしまい、
本末転倒です。

したがって、脆弱性診断においてアカウントロックは検査すべき対象ではなく、
診断を邪魔する厄介な機能扱いです。
そのため下線⑤の後ろに「注意せよ」と警告が書かれています。

pixさま
繰り返しの更問いに、都度回答いただき大変感謝しております。
もう少し掘り下げさせてください。

一点目
「ここでの脆弱性診断の目的は「SQLインジェクション」の検査です。」と記載していただきましたが、出題文では、この診断（フェーズ５：診断手順案に従った診断の実施）で「ＸＳＳ」と「アクセス制御の回避」の脆弱性が検出された報告されていることからしても「SQLインジェクション」以外の検査も含まれると理解しています。「アカウントロック機能が適切に動作するか」はソフトウェア要件のテストであることに異論はありませんが、それと同時に脆弱性診断としてテストされる事柄に含まれるのではないでしょうか。
なぜそう考えるかというと、設問にもなっている「会員Nが所属しているグループによりキャンペーンリンクを出し分ける機能」もソフトウェア要件のテストという側面はあると思うからです。それでも、診断対象となっています。このことから、脆弱性診断においてアカウントロックは検査すべき対象ではない、との解釈は難しく感じました。

二点目
模範解答である
  画面遷移：（Ａ）
  理由：「同じアカウントで連続５回間違えるとアカウントがロックされるから」
について、下線部⑤の「特定のパラメータ」はどのようなものをイメージすればよいのでしょうか。回答に当たって、私も一旦（A）と判断して、その際の特定パラメータはpwではないかと考えたのですが、後に打ち消しました。パスワードは毎回同じか、異なるかにかかわらず、間違ったパスワードであれば５回でロックされます。つまりアカウントロックされる理由は「特定のパラメータが同じ値であるリクエストを複数回送信した」からではなく、したがって、pwのパラメータに対して拒否回避機能を有効にしてもロックは回避できないと解釈しました。

>一点目
>「ここでの脆弱性診断の目的は「SQLインジェクション」の検査です。」と記載して
すみません。ここは「SQLインジェクション」ではなく「XSS」の検査でした。

>「アカウントロック機能が適切に動作するか」はソフトウェア要件のテストで
>なぜそう考えるかというと、設問にもなっている「会員Nが所属しているグループ
>によりキャンペーンリンクを出し分ける機能」もソフトウェア要件のテストという
>側面はあると思うからです。
「アクセス制御の回避」とはCSRFを検査する意図と考えられます。
意図しない画面遷移はCSRFの原因となるからです。CSRFは脆弱性検査の範囲内です。


>二点目
いろいろ混同していると思われます。以下の2つは別と思われます。
・アカウントロック
  遷移（A）の箇所でパスワードを5回連続で間違えた場合
・リクエストエラー
  遷移（C)の箇所で特定のパラメータが同じ値であるリクエストを複数送信した場合

pixさま
ありがとうございます。
設問３（２）は、下線部⑤について問われていますので、2組の解答の両方について「特定のパラメータが同じ値であるリクエストを複数回送信した結果エラーになっている事例」を挙げる必要があると思って該当箇所を探しその理由を考えました。そして行き詰まりました。
pixさまは、いただいたコメントを見る限り（A）のエラーは「特定のパラメータが同じ値であるリクエストを複数回送信した結果エラーになっている事例」ではないと解釈されていると思いますが、出題文にある「下線部⑤について、該当する」の条件について、どのように解釈されていますでしょうか。

すみません。解答から逆算するに、下線⑤は（A）と（C）の両方にかかります。
（A）5回とも同じ間違ったパスワードでログイン試行する
（C）同じ会員が申込済みのキャンペーンに再度申し込む
です。
これにより、（A）・（C）より先の画面に遷移することができなくなります。

pixさま
再度ご回答いただきありがとうございます。下線⑤は（A）と（C）の両方にかかるとの認識が一致してよかったです。

（A）5回とも同じ間違ったパスワードでログイン試行する
これによって、画面遷移ができないのは私も理解できます。アカウントロックされると思います。
ただし、IPAの模範解答は「同じアカウントで連続５回間違えるとアカウントがロックされるから」であり、「同じ間違ったパスワード」とは記載していません。この言葉が用いられていないことからすると、出題者こそがpixさまの指摘する「アカウントロックとリクエストエラーを混同」しているのでは？と感じましたがどう思われますか。

また
（A）5回とも同じ間違ったパスワードでログイン試行する
が正解だった場合、Vツールの「拒否回避機能」を使うことにより、アカウントロックは回避できるのでしょうか。図１のツールVの仕様を読む限り、「拒否回避機能」は特定のパラメータが同じ値であるリクエストを複数回送信すると拒否されてしまう診断対象URLに対して効果を発揮します。（A）では同じ間違ったパスワードか、異なる間違ったパスワードかにかかわらず、アカウントロックが動作すると思うので拒否の理由、ロジックは違います。なので「拒否回避機能」でのアカウントロック回避はできないと考えました。
実際のDASTツールをご利用であれば（pixさま以外の方でも結構ですが）実際のところどうなのか共有いただけますと幸いです。

>ただし、IPAの模範解答は「同じアカウントで連続５回間違えるとアカウントが
>ロックされるから」であり、「同じ間違ったパスワード」とは記載していません。
>この言葉が用いられていないことからすると、出題者こそがpixさまの指摘する
>「アカウントロックとリクエストエラーを混同」しているのでは？と感じましたが
>どう思われますか。
脆弱性診断を行う際にはログインするためになんらかのユーザIDとパスワードが
必要になります。
この時、パスワードを間違えて設定してしまうと、脆弱性診断は自動ログインで
ログイン試行を同じパスワードで何度も行うと思われます。
そのため、アカウントロックが発生すると考えられます。

>（A）5回とも同じ間違ったパスワードでログイン試行する
>が正解だった場合、Vツールの「拒否回避機能」を使うことにより、
>アカウントロックは回避できるのでしょうか。
Vツールの「拒否回避機能」ではできないと思われます。
単純に脆弱性診断で利用するユーザIDとパスワードを間違えないようにという
基本的な事項の指摘だと思います。

pixさま
何度もレスをかえしていただきありがとうございました。
記載いただいたとおり、DASTツールを利用する際には、ユーザIDとパスワードを間違えないようにする必要があることは、理解できました。また「脆弱性診断においてアカウントロックは検査すべき対象ではなく、診断を邪魔する厄介な機能扱いです。」とのコメントも、実務・試験の両方に役立つ示唆を得た気がします。

個人的には設問３（２）の解答が二組ではなく一組だけの出題だったとしたら、あるいは下線部⑤の次の行にある「適切な診断を行うために、…実施した」の一文がなければ、正解に近づけたかもしれないと思いました。出題者の意図がわからず、出題者の勘違い・混同の疑念が払しょくできない最大の要因となっているところです。pixさま以外でも、この一文についてどう解釈したのかコメントいただける方がいらっしゃればありがたいです。