【情報処理安全確保支援士試験令和2年度秋期午後2 問1 No.3】

情報処理安全確保支援士試験令和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にするように修正する必要があります。