情報処理安全確保支援士 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では <script type="text/javascript"> でinput.onsubmit = function () { … } としており、判定ロジックはJavaScript依存であることが分かります。
• つまり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

解答の導き方

誤りやすいポイント

• fhBuf.cols／fhBuf.rowsをintと誤認する。実際は「unsigned short int」であり、演算時にintに昇格する点を意識する必要がある。
• 判定にそのまま $bytesOfRow\times fhBuf.rows>kMaxInteger$ を書くと、その演算自体でオーバーフローして比較が無意味になる。積による比較は避け、除算を使ってオーバーフローを未然に検出する。
• bytesOfBuffと確保サイズのチェックをkMaxMatDataのみで行うと、オーバーフローで小さくなったbytesOfBuffに対してチェックがすり抜ける場合がある。まず $kMaxInteger$ に対する保護を行うこと。
• ゼロ除算の可能性を忘れがちだが、本コードではfhBuf.cols／rowsが0の場合は既に例外が投げられる（図6の35行目）ため、除算チェックは安全に使える。実務では防御的にbytesOfRow > 0の確認を入れるとより堅牢。

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