サイトアイコン やさしいネットワークとセキュリティ

【情報処理安全確保支援士試験 令和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の他人のアカウントが紐付いてしまうと指摘した。

  1. 図2で、サイトQの利用者ID欄に誤った利用者IDを入力する。
  2. 図4のコードが呼び出され、(c)に誤った利用者IDが代入されたまま、(d)が呼び出される。
  3. 何らかの理由で、(d)中の図3中の行番号()で(f)が発生し、結果として(d)が再試行される。
  4. 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()の結果を確認していることが分かります。

e: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の入力で、そのままアカウントの紐付けが行われることになります。

(i)に入れる適切な処理内容を50字以内で具体的に述べよ。:NamingExceptionを投げる前に、childCheckedをfalseにする

 「K主任は、図3の32行目前後に着目し、()という修正案を提示した。
 前問のとおり、childCheckedがtrueのまま抜けてしまうことが問題ですので、32行目「throw e;」の「NamingException」を投げる処理では、その前にchildCheckedをfalseにするように修正する必要があります。

モバイルバージョンを終了