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

解答の論理構成

1. 問題文では、「GETメソッドではなくPOSTメソッドを使用しておかないと、①HTTPヘッダ内のフィールドが原因で、バナー広告に設定されたリンク先のWebサーバへセッションIDが漏えいする」 と記載されています。
2. GET メソッドでセッション ID をクエリパラメタに埋め込むと、リンク遷移時に現在閲覧している URL（＝セッション ID 付き）が外部サイトへ伝わる仕組みが存在します。
3. ブラウザはリンクをクリックした際、HTTP リクエストに元ページの URL を示す Referer ヘッダを自動付与します。これにより外部サイトに「どのページから来たか」が通知されます。
4. クエリパラメタにセッション ID が含まれていれば、そのまま Referer ヘッダに載ってしまい漏えいします。
5. 以上から、下線部①の “HTTPヘッダ内のフィールド” は Referer であると導けます。

誤りやすいポイント

• Cookie と混同する
  セッション ID を Cookie で管理する場合はブラウザが外部サイトに送信しないため本問の漏えいは起きません。
• フィールド名の綴り
  正しくは “Referrer” ではなく HTTP 仕様どおり “Referer” と綴ります。
• Location ヘッダの誤認
  Location はサーバ側が返す応答ヘッダであり、今回の「ブラウザ→外部サイト」送信ヘッダではありません。

FAQ

解答の論理構成

• 問題文には、ファイル拡張子の判定を「③スクリプトによらない方式」に変更せよとあります。
• その理由として、Q主任が「②契約者の操作によっては、拡張子が画像ファイルのものでないファイルがアップロードできてしまう」と指摘しています。
• 図2の HTML では
• つまり JavaScript が動かない状態ではチェックが行われません。JavaScript を動かなくする典型的な「契約者の操作」はブラウザ側でスクリプトを無効化することです。
• 従って下線②の操作は「ブラウザの設定でスクリプトを無効化する」となります。

誤りやすいポイント

• 「ファイル名を変更する」と勘違いしやすいですが、ファイル名変更はスクリプト判定後にサーバ側が再検証すれば防げるため、設問の趣旨とずれます。
• 「HTTP を直接叩く」と解釈すると余分な想定になります。問題文の指摘は JavaScript 依存のチェックに潜む単純な盲点を問うています。
• 「ブラウザの拡張機能で改ざん」と考えると複雑化しますが、基本動作として JavaScript を無効化できることを見落としやすいです。

FAQ

解答の論理構成

• 基本設計の会話では、V君がブラウザ側スクリプトで拡張子を判定する案を提示しました。
  引用：
  「この指摘への対策の一つとして、アップロードするファイルの拡張子を画像ファイルのものに制限することとした。制限する方式として、V君は、Webブラウザにおいてスクリプトによって判定することを考えた。」
• しかしQ主任は、契約者の操作次第で制限を回避できる弱点を挙げ、 引用：
  「②契約者の操作によっては、拡張子が画像ファイルのものでないファイルがアップロードできてしまうという問題点を指摘し、制限する方式には③スクリプトによらない方式を検討するよう指示した。」
• 「③スクリプトによらない方式」は、ブラウザ（クライアント）ではなくサーバ側で判定を行う方式を指します。ブラウザ依存を排除することで、利用者がスクリプトを無効化した場合や改ざんした場合でも安全に拡張子制限を適用できます。
• したがって解答は「Webアプリケーションで拡張子判定を行う。」となります。

誤りやすいポイント

• 「MIMEタイプ判定」とだけ答えると拡張子制限かどうかが不明確になり減点される恐れがあります。
• 「サーバ側でウイルスチェックを行う」など、拡張子以外の対策を混在させると設問の焦点がずれます。
• 「HTTPS 強制」や「Content-Disposition ヘッダ」など、別のセキュリティ手法と混同しないよう注意が必要です。

FAQ

解答の論理構成

1. 38行目の計算
   bytesOfBuff = bytesOfRow * fhBuf.rows; とあります。
   直前の 37行目で bytesOfRow は列数に kColors を掛けた後に 256 バイト境界へ調整しているため、元画像が大きい場合には bytesOfRow がかなり大きくなります。ここで fhBuf.rows（行数）との乗算を行うと、32 ビット符号付き整数の最大値である 0x7fffffff を超えるケースが発生し得ます。
   → この現象は「整数オーバフロー」です。
2. オーバフローが起きた場合の副作用
   bytesOfBuff に本来より小さい値が格納されてしまい、41行目
   pixBuf = (char*)malloc(bytesOfBuff);
   で確保される領域も不足したサイズになります。
3. 不足領域への書込み
   47～53行目の for ループでは、元画像全体を読み込みます。実データサイズは正しい値のままなので、確保サイズを超えて pixBuf を更新し続け、結果として
   50行目 fread(pixBuf, kColors, fhBuf.cols, fp);
   でメモリ境界を越えて書き込むことになります。
   → これは「バッファオーバフロー」です。
4. 追加行による修正
   図7の追加行
   if ( c < d ) throw out_of_range("Image too large");
   で、乗算前に「列数×行数×色数」が安全な範囲か確認し、オーバフローとそれに続くバッファオーバフローを事前に防止しています。

誤りやすいポイント

• 「配列境界を超える＝バッファオーバフロー」に目が行き、原因である「整数オーバフロー」を見落とす。
• 37行目の 256 バイト境界調整を“端数切り上げ”と誤解し、計算式が安全だと思い込む。
• unsigned short int で定義されているヘッダ項目を「正なら問題なし」と考え、列数・行数チェックを甘くしてしまう。

FAQ

解答の論理構成

• ソースコード３６〜３８行目では
  bytesOfRow = fhBuf.cols * fhBuf.colors; bytesOfRow += 255 - ((bytesOfRow + 255) % 256); /256バイト境界に調整/ bytesOfBuff = bytesOfRow * fhBuf.rows;
  と計算しています。
• 変数型はすべて int であり、上限は １１行目に定義された
  const int kMaxInteger = 0x7fffffff; です。
• 行３８行目の乗算で得られる真の値が kMaxInteger を超えると、
  bytesOfBuff には符号付き整数のオーバフロー（a）が生じ、
  ― すなわち期待より小さい（場合によっては負の）値が入ります。
• そのまま４１行目で
  pixBuf = (char*)malloc(bytesOfBuff);
  を実行すると、確保するバッファが実際に必要なサイズより不足し、
  ５０行目の fread(pixBuf, kColors, fhBuf.cols, fp); で
  バッファオーバフロー（b）が発生します。
• したがって a が起こる条件は
  「パディングを含めた１行分のバイト数（bytesOfRow）とヘッダ部の行数（fhBuf.rows）の積が kMaxInteger を超える場合」
  となります。

誤りやすいポイント

• １行分のパディング調整 255 - ((bytesOfRow + 255) % 256) を忘れ、単純に fhBuf.cols * fhBuf.colors だけで判定してしまう。
• 「オーバフローが起きたら負になる」と思い込み、積が負値になるケースしか想定しない（実際には正の小さい値になることもある）。
• kMaxMatData（１０行目）との比較で十分と勘違いし、kMaxInteger まで考慮していない。

FAQ

解答の論理構成

1. 背景把握
   • 【問題文】図6 37～38 行で
     bytesOfRow += 255 - ((bytesOfRow + 255) % 256); /256バイト境界に調整/ bytesOfBuff = bytesOfRow * fhBuf.rows;
     とあり、bytesOfRow * fhBuf.rows で int 型の乗算が行われています。
   • 同図 39 行目で
     if (bytesOfBuff > kMaxMatData) throw out_of_range("Image too large");
     というサイズ上限チェックを行っていますが、実際には 38 行目の乗算時点で int の最大値（kMaxInteger）を超えると桁あふれ（整数オーバフロー） が発生し、正常な比較ができなくなります。
2. 追加行の目的
   • 【問題文】図7では
     if ( c < d ) throw out_of_range("Image too large");
     を 37～38 行の間に挿入し、乗算を実行する前に 桁あふれを未然に検知 させるのが狙いです。
3. オーバフローの一般的な判定式
   • 乗算 A * B が kMaxInteger を超えるかどうかは
     if (A > kMaxInteger / B) // 乗算するとオーバフロー
     で判定できます。
   • これを「左右を入れ替えた形」にしても論理は同じで、
     if (B > kMaxInteger / A)
     でもかまいません。
4. 当該変数への当てはめ
   • 乗算の片方 A が bytesOfRow、もう片方 B が fhBuf.rows です。
   • よって、チェック式は次の2パターンのいずれかになります。
     ア群
     if (kMaxInteger / fhBuf.rows < bytesOfRow) …
     イ群
     if (kMaxInteger / bytesOfRow < fhBuf.rows) …
   • 問題指示「c、d のどちらか一方は、kMaxIntegerを含むこと」にも合致しています。
5. よって模範解答は
   • ア群
     • c：kMaxInteger / fhBuf.rows
     • d：bytesOfRow
   • イ群
     • c：kMaxInteger / bytesOfRow
     • d：fhBuf.rows

誤りやすいポイント

• kMaxMatData と kMaxInteger を取り違え、上限比較を誤る。
• 既に計算済みの bytesOfBuff を使ってチェックしてしまい、乗算後のオーバフローを防げない。
• /（整数除算）が切り捨てであることを忘れ、境界条件を間違える。
• “大きい方”と“小さい方”を逆に比較し、常に例外が発生しない・常に発生するというバグを入れる。

FAQ