情報処理安全確保支援士試験 令和2年度 秋期 午後2 問1
【出典：情報処理安全確保支援士試験 令和2年度 秋期 午後2 問1（一部、加工あり）】
[コードレビュー]
アカウントの共通利用の設計を終えたJ主任は、サイトPのWebアプリの改修に着手した。
図3及び図4は、サイトPのアカウントにサイトQのアカウントを紐付ける場合のサイトP上での紐付け処理のJavaソースコードである。
利用者が、サイトPにログイン後、図2の画面を操作し、”紐付け”ボタンをクリックした場合、図4の行番号101のsiteIDにサイトの識別文字列として”siteQ”が代入された状態で図4のコードの実行が開始される。図4のコードが正常に終了したら、紐付けが完了したことを表示する。
J主任は、情報処理安全確保支援士（登録セキスペ）のK主任とともにコードレビューを実施した。K主任は、次のような特定の状況では、サイトPのある利用者のアカウントに、サイトQの他人のアカウントが紐付いてしまうと指摘した。
- 図2で、サイトQの利用者ID欄に誤った利用者IDを入力する。
- 図4のコードが呼び出され、（c）に誤った利用者IDが代入されたまま、（d）が呼び出される。
- 何らかの理由で、（d）中の図3中の行番号（ｅ）で（f）が発生し、結果として（d）が再試行される。
- （d）が3回試行され、全て同じく（f）が発生すると、（g）の値はtrueなので、図4中の行番号（h）に進み、紐付けが行われる。
K主任は、図3の32行目前後に着目し、（ｉ）という修正案を提示した。
c：idPair.childID
「図4のコードが呼び出され、（c）に誤った利用者IDが代入されたまま、（d）が呼び出される。」
（c）は、誤った利用者IDを代入する変数になります。
図3（Web-PのWebアプリにおけるAccountLinkのクラス定義）の4行目に「String childID; //子アカウントの利用者ID//」とあり、これが誤った利用者IDが入力される変数childIDになりそうです。
次に図4（Web-PのWebアプリにおけるAccountLinkのメソッドを呼んでいる部分）の101行目「AccountLink idPair = new AccountLink(siteID, userID, userPassword, loginID);」では、new演算子を使用して、AccountLinkクラスのインスタンス「idPair」を作成しています。
このuserIDに誤った利用者IDが代入されることになります。
流れとしては、誤った利用者IDがuserIDに代入され、それが図3の11行目「public AccountLink(String site, String id, String pw, String loginID」でidに引き渡され、14行目「childID = id;」でchildIDに代入されています。
AccountLinkクラスのインスタンス名「idPair」の変数「childID」なので、「idPair.childID」となります。
d：idPair.checkChild()
「図4のコードが呼び出され、idPair.childIDに誤った利用者IDが代入されたまま、（d）が呼び出される。」
「何らかの理由で、（d）中の図3中の行番号（ｅ）で（f）が発生し、結果として（d）が再試行される。」
「（d）が3回試行され、全て同じく（f）が発生すると、（g）の値はtrueなので、図4中の行番号（h）に進み、紐付けが行われる。」
3回試行される処理は、図4の103行目「for(int retryCount = 1; retryCount < 4; retryCount++)」にあります。
この中の処理で、105行目「result = idPair.checkChild();」とあるようにidpair.checkChild()の結果を確認していることが分かります。
ｅ：26、f：NamingException
「何らかの理由で、（idPair.checkChild()）中の図3中の行番号（ｅ）で（f）が発生し、結果として（idPair.checkChild()）が再試行される。」
「（idPair.checkChild()）が3回試行され、全て同じく（f）が発生すると、（g）の値はtrueなので、図4中の行番号（h）に進み、紐付けが行われる。」
（idPair.checkChild()）が再試行される箇所を探すと、図4の110行目「catch (NamingException e) //再試行のために、一定時間待つ。」の部分が該当します。
そして、「NamingException e」は図3の31行目にあり、その処理は26行目「if (siteQAuth(childID, childPW) == NO_ERROR)」により例外として発生することになります。
g：idPair.childChecked、h：117
「（idPair.checkChild()）が3回試行され、全て同じく（NamingException）が発生すると、（g）の値はtrueなので、図4中の行番号（h）に進み、紐付けが行われる。」
「紐付けが行われる」箇所を探すと、図4の117行目「idPair.makeLink(); //アカウントの紐付けを実施する。」が該当します。
そして、その条件としては直前の113行目「if (!idPair.childChecked)」により、「idPair.childChecked」が真の場合が該当し、偽の場合には、114行目「return AccountLink.ERROR_LINK_FAILED」を返します。
ここで、変数「childChecked」の値を確認すると、図3の12行目「childChecked = false;」で「false」となり、19行目「childChecked = childSite.equals(“siteQ”) || childSite.equals(“siteR”);」のif文でサイトの識別文字列が正当であれば「true」となります。
そして、25行目以降の認証情報チェックで認証が実行できなかった場合には、「true」のまま抜けてしまいます。
この部分が問題となり、誤った利用者IDの入力で、そのままアカウントの紐付けが行われることになります。
（ｉ）に入れる適切な処理内容を50字以内で具体的に述べよ。：NamingExceptionを投げる前に、childCheckedをfalseにする
「K主任は、図3の32行目前後に着目し、（ｉ）という修正案を提示した。」
前問のとおり、childCheckedがtrueのまま抜けてしまうことが問題ですので、32行目「throw e;」の「NamingException」を投げる処理では、その前にchildCheckedをfalseにするように修正する必要があります。