情報処理安全確保支援士 2011年 春期 午後1 問01

解答の論理構成

1. 【問題文】図6では
   string::iterator readPoint = src.a();
   string::iterator atEOL = src.b();
   と記述されており、readPointとatEOLの2つの反復子（イテレータ）で文字列src全体を走査しています。
2. ループ条件は
   while(readPoint != atEOL){ … }
   です。反復子が「先頭から末尾（終端位置）まで」を指し示すのが自然でなければ、この条件は成立しません。
3. 標準C++ライブラリstringクラスの代表的なメンバ関数は
   • begin() : 先頭要素を指すイテレータを返す
   • end() : 末尾の次（終端）を指すイテレータを返す
   です。その他の候補（clear、sizeなど）はイテレータを返さない、あるいは意味が合致しません。
4. したがって
   ・readPointは先頭を指す必要があるため a に入るのは “begin”
   ・atEOLは終端を指す必要があるため b に入るのは “end”
   となり、解答は
   a：ア
   b：ウ
   で確定します。

誤りやすいポイント

• size() と混同する
  size() は要素数を返す関数でありイテレータ型ではないため、代入自体がコンパイルエラーになります。
• 末尾位置のイメージ違い
  end() が「最後の文字」ではなく「最後の次」を指すイテレータである点を忘れると、ループ条件を誤って「<=」などに置き換えてしまいoff-by-oneエラーを招きます。
• clear() の機能誤認
  イテレータを返しそうに見えても、clear() は内容を消去する副作用のみを持つため全く用途が異なります。

FAQ

解答の論理構成

1. 脆弱性の種類を確認
   問題文には「パーセントエンコード関数にバッファオーバフロー脆弱性があり」と明示されており、対象は「図4」の関数です。
2. 書き込み先バッファの特定
   「図4」1行目に
   void urlPercentEncode(char *dst, char *src, int n)
   とあり、dstが書き込み先バッファであることが分かります。
3. 上限チェックの不備
   ループ条件は6行目
   while(src[srcPos] != '\0' && dstPos < n){
   で行っていますが、エンコード対象文字の場合は18〜22行目で 最大３バイト を一度にdstに書き込みます。
   dst[dstPos++] = '%'; // 1バイト ... dst[dstPos++] = x; // 2バイト目 ... dst[dstPos++] = x; // 3バイト目
   しかしdstPos < nの判定は １回のループ開始時点のみ なので、ループ途中でnを超過してもチェックされず、dstの後続領域に上書きが発生します。
4. 被害が出る領域
   問題文は「隣接したメモリ領域に置かれたフラグ変数が想定外の値に書き換えられる」と説明しており、これはdstの直後にあった変数への不正書き込みです。
   したがって、オーバフローが起きるメモリ領域は「dstが指し示す領域」と結論付けられます。

誤りやすいポイント

• src側を疑ってしまう
  読み出しバッファであるsrcはサイズを超えて読み込まれてもメモリアクセス違反になりにくく、今回の脆弱性の直接原因ではありません。
• nのチェックは十分と誤認
  １ループ３バイト書き込む場合があることに気付かないと、条件式dstPos < nで十分と勘違いしやすいです。
• 「フラグ変数」そのものを回答に書く
  設問は「バッファオーバフローが発生するメモリ領域」を聞いており、書き換えられた側ではなく あふれ出した側 を答える必要があります。

FAQ

解答の論理構成

1. 【問題文】の「パーセントエンコード関数にバッファオーバフロー脆弱性があり」とあるとおり、原因はurlPercentEncode() 内の領域管理にあります。
2. 図4‐6行目のwhile条件は
   while(src[srcPos] != '\0' && dstPos < n){
   で、dstPos < nという“1バイト以上空いていれば継続”という判定しか行っていません。
3. しかし図4‐18～22行目ではエンコード対象文字を見つけると
   dst[dstPos++] = '%'; // 1バイト x = (src[srcPos] & 0x00f0) >> 4; dst[dstPos++] = …; // 2バイト目 x = src[srcPos++] & 0x000f; dst[dstPos++] = …; // 3バイト目
   の計3バイトを書き込みます。
4. したがって、ループ開始時点でn - dstPosが「1バイトまたは2バイト」しか残っていない状態でエンコード対象文字が現れると、3バイト目の書込みでdstの領域外に到達し、隣接メモリ（フラグ変数など）を上書きしてバッファオーバフローが発生します。
5. よって模範解答は「dstが指し示す領域の残りが2バイト以下となった時点で、srcにエンコードすべき文字があった場合」となります。

誤りやすいポイント

• 「ナル終端を付与できないだけ」と思い込み、3バイト連続書込みによる境界超過を見落とす。
• dstPos < nなので安全だと早合点し、必要バイト数（1文字で最大3バイト）を考慮しない。
• 逆に「残り1バイトのときのみ危険」と狭く捉え、2バイト残りの場合を失念する。
• src側の読込位置（srcPos）ばかり注視し、dst側の書込み量を軽視する。

FAQ

解答の論理構成

• 【問題文】では、旧実装について「図4のソースコードでは文字列を配列として取り扱っていたので領域の境界をプログラムで管理する必要があった」と明示しています。
• その後の改修方針として「標準C++ライブラリの文字列クラスを使用してパーセントエンコード関数を作り直す」と記述し、図5で関数シグニチャを「string urlPercentEncodeString(string src)」へ変更しています。
• さらに、「図6のソースコードではcので、バッファオーバフローが発生することはなくなった。」と背景を説明しています。
• 文字列クラスstringは格納領域の確保・拡張・終端管理を処理系（ライブラリ）が自動で行います。利用側はpush_backなどのメンバ関数を呼ぶだけで済み、配列添字演算で自力管理する必要がありません。
• したがって、改修後は「領域の境界」を開発者が意識せずに済み、配列境界を越えて書込む不具合——すなわちバッファオーバフロー——が構造的に除去されるため、c には「文字列をstringクラスとして取り扱っており、領域の境界は処理系が管理することとなる」が入ります。

誤りやすいポイント

• 「イテレータを使えば安全」と早合点し、根本理由を“イテレータ”に求めてしまう。安全性を担保しているのはstringが内部でサイズ管理している点です。
• 「push_backも配列添字と同じ書込み」と誤解し、push_backでも境界チェックがないと思い込む。stringは必要に応じて自動で再確保します。
• 「UTF-8化や128バイト制限があるから安全」と問題の主旨を取り違える。今回の質問はバッファオーバフロー防止の技術的根拠を問うています。

FAQ

解答の導き方

• 図7（4. ポインタ・配列）にある「文字列処理を行う場合、文字列を格納するための d の使用を禁止する。」
  根拠として本文に「図4のソースコードでは文字列を配列として取り扱っていたので領域の境界をプログラムで管理する必要があった」とあり、さらに改修後に「標準C++ライブラリの文字列クラスを使用してパーセントエンコード関数を作り直す」とあります。これらから、禁止したいものは「配列として文字列を保持する方法（手動で境界管理が必要なもの）」であると読み取れます。日本語で最も直接的に表す語句は「文字型の配列」です。したがって空欄dには「文字型の配列」が適切です。
• 図7（4. ポインタ・配列）にある「配列又はポインタに添字を指定して書込みを行う場合、e を毎回実施する。」
  根拠として図3の仕様は「nの値はdstが指す文字列に書き込める最大バイト数」と定め、図4の実装ではループ条件に「while(src[srcPos] != '\0' && dstPos < n)」のようなチェックがある一方で、エンコード時に複数バイトを連続して書き込んでおり（例：dst[dstPos++] = '%' の後さらに2バイト書く）、ループ条件の一回の比較だけでは各書込みが上限を超えないことを保証できず脆弱性を招きました。ここで求められている対策は「書き込みごとに上限を確かめること」ですから、空欄eには「上限チェック」が当てはまります。
• 図7（5. 関数）にある「引数としてポインタを受け取った場合、添字指定での f は禁止する。」
  根拠として図7の同項目に「関数内で値を変更する場合を除き、関数の引数であるポインタはconstへのポインタとする。」や「文字列処理を行う関数では、処理が成功したときは、原則として処理結果の文字列を返却値として返す」とあること、および改修で「urlPercentEncode() を呼び出していた部分は、すべて図5の仕様に基づく関数urlPercentEncodeString()を呼び出すように修正した」ことから、関数が受け取ったポインタ先を添字で書き換える行為（添字指定での書き込み＝代入）を禁止していることが明らかです。したがって空欄fには「代入」が適切です。

誤りやすいポイント

• 「文字型の配列」を単に「配列」としてしまう誤り
  → 問の意図は文字列を保存するためのCスタイルの配列（手動管理が必要な配列）を明確に禁止する点にあるため、単に「配列」だと対象があいまいになります。
• 「上限チェック」と「境界チェック／範囲チェック」を混同する誤り
  → 意味は近いですが、設問文は「書込み時の上限（最大書込みバイト数）を毎回確認する」という趣旨なので、より直接的な表現である「上限チェック」が求められます。実装上は「各書込み前に容量を確認する」ことを忘れないでください。
• 添字による「読み取り」と「代入」を取り違える誤り
  → 問は「添字指定での（何を）禁止するか」を問うています。禁止されているのは書き込み（代入）であり、読み取りのみを指す語を入れると趣旨が合いません。
• 読み取りは安全だと思い込む誤り
  → 読み取りの境界外参照も未定義動作であり危険です（下のFAQ参照）。

FAQ