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

解答の論理構成

1. 図2には、SQL 文を組み立てる処理として
   　"string query = "SELECT report FROM reports WHERE user = '" + user + "'";"
   　"query += " AND day = '" + day + "'";"
   　の二行が掲載されています。
2. 上記のように user と day をそのまま文字列連結していると、利用者が入力欄に
   　' OR '1'='1 のようなコード片を埋め込んだ場合でも、SQL 文がそのまま実行されてしまいます。
3. これは「入力値をエスケープせずに SQL 文字列へ直接結合する」という典型的な SQL インジェクションの原因です。
4. したがって、SQL インジェクションの原因となるコーディング部分に書かれた変数名は user, day の二つになります。

誤りやすいポイント

• query 変数そのものを答えてしまう。query は完成した SQL 文を格納するもので、原因はその中に差し込まれる user, day です。
• rep や con など、データ取得後に使われる変数を挙げてしまう。これらは SQL 文の生成に関与しません。
• 図3・図4のプレースホルダ利用コードと混同し、「脆弱性は除去済み」と誤認してしまう。

FAQ

解答の論理構成

1. 問題文は「B君は、このコードに対し、SQLインジェクション対策を行ってみた。この対策は、aを用いてSQL文を組み立てるというものである。」と明言しています。
2. 図3のSQL文は SELECT report FROM reports WHERE user = ? AND day = ? のように ? を挿入しており、図4でも同様に ? を使っています。? は SQL の「値を後からバインドする位置」を示す記号です。
3. この記号を使う手法は JDBC でも ODBC でも「プレースホルダ（置き換え文字）」と呼ばれます。
4. したがって、a に入る適切なプログラミング技法は「プレースホルダ」です。

誤りやすいポイント

• 「パラメータバインド」と答えてしまう
  ⇒ バインドは 実行時の操作、技法名として問われているのは ? を使った「プレースホルダ」です。
• PreparedStatement＝プレースホルダと混同
  ⇒ PreparedStatement は API クラス名、プレースホルダは SQL 文中に埋め込む仕組みです。
• 「バインド変数」と書く
  ⇒ 意味は近いものの、問題文の用語と合致せず減点リスクがあります。

FAQ

解答の論理構成

1. 図3の C++ コードには、SQL インジェクション対策として
   “pstmt = con->prepareStatement(query);”
   という記述があります。ここで "prepareStatement" はデータベース接続オブジェクトがプレースホルダ付き SQL を扱うために呼び出す関数名です。
   【問題文】
   “pstmt = con->prepareStatement(query);” （図3）
2. 図4の Java コードは同じ対策を Java で実装したものと明記されています。
   【問題文】
   “B君は、図3のC++コードと同様の対策を実施した同じ仕様のプログラムをJavaで作成してみた。”
3. Java でデータベースアクセスを行う場合、java.sql.Connection インタフェースには C++ と同名の
   prepareStatement(String sql)
   というメソッドが定義されています。従って、図4の
   ps = con.b(query);
   には "prepareStatement" が入ります。
4. 以上より、b に入る英字は
   prepareStatement
   となります。

誤りやすいポイント

• createStatement と混同する
  SQL 文字列をそのまま渡す場合は createStatement() ですが、プレースホルダを使う今回は prepareStatement() です。
• メソッド名の大文字小文字
  Java は大文字小文字を区別します。PrepareStatement や prePAREstatement などは誤りです。
• “Statement” と “PreparedStatement” の役割の混同
  PreparedStatement はコンパイル済み SQL を扱い、バインド変数で値を安全に渡せる点が違いです。

FAQ

解答の論理構成

1. 【図2】【図3】の C++ コード、【図4】の Java コードでは、入力値である user、day、rep を次のようにそのまま HTML へ出力しています。
   • cout << "user = '" << user << "'
     ";
   • out.write("user = '" + user + "'
     ");
2. これらの変数は「利用者画面の入力データから取り出され」ると【図1】で明記されています。したがって外部から任意の文字列（例：）を混入させることが可能です。
3. 上記のような未加工の出力は、ブラウザ上でスクリプトが実行される「クロスサイトスクリプティング」を招きます。
4. 本文には「cをd処理するという対策を図3と図4のコードにそれぞれ追加した」とあり、対策対象はまさに HTML へ出力するデータであることが示唆されています。これはクロスサイトスクリプティングの典型的な防御手法であるエスケープ処理に一致します。
5. 以上より、下線①の代表的な脆弱性は「クロスサイトスクリプティング」であり、解答群では「ア」に該当します。

誤りやすいポイント

• SQL インジェクション対策コードが示されているため、つい同系統の「コマンドインジェクション（ウ）」と誤認しやすい。
• 「セッション」や「リクエスト」という語に引きずられて「クロスサイトリクエストフォージェリ（イ）」や「セッションフィクセーション（エ）」を選んでしまう。
• 入力値の検証＝サーバ側のバリデーションと早合点し、出力時のエスケープ不足が脆弱性になる点を見落とす。

FAQ

解答の論理構成

1. 脆弱性の特定
   • 図3・図4には、cout << "user = '" << user << "'
     "; や out.write("user = '" + user + "'
     "); など、利用者入力（user、day、rep）をそのまま HTML へ出力する記述があります。
   • 本文には「この後、図2～4のコードにはSQLインジェクション以外にも①代表的な脆弱性の原因となるコードが含まれている」とあり、ここで想定される代表的脆弱性は XSS（クロスサイトスクリプティング）です。
2. どの値を保護するか
   • XSS は「HTML へ直接出力される文字列」に悪意あるタグやスクリプトを混入させることで成立します。従って防御対象は「HTMLにおける特別な記号」（<、>、"、'、& など）です。
3. 採るべき対策技法
   • XSS への第一の防御策は、前項の特別な記号を無害化する「エスケープ」です。
   • 問題文の指示「cをd処理する」という形式に合わせると、 ・c＝攻撃ベクトルとなる文字集合そのもの
     ・d＝適用する処理名
     となるため、
     • c「HTMLにおける特別な記号」
     • d「エスケープ」
       が妥当です。

誤りやすいポイント

• 「入力値をそのまま表示」が必ずしも XSS とは限らないと誤解してバリデーション（長さチェックなど）だけで済ませてしまう。
• SQL インジェクション対策で PreparedStatement を導入したことで「もう安全」と思い込み、表示処理の脆弱性に気付かない。
• エスケープとサニタイジングの使い分けを混同し、タグ除去のような別技法を書いてしまう。

FAQ

解答の論理構成

1. 【問題文】では「B君は、cをd処理するという対策を図3と図4のコードにそれぞれ追加した」とあります。この“①代表的な脆弱性”は、ユーザや DB から取得したデータをそのまま HTML へ出力しているために発生する XSS であり、対策は「HTML エスケープ（出力時エンコード）」です。
2. XSS は「利用者入力や DB 取得値を、ブラウザが解釈可能な形で返す」箇所が攻撃点になります。図3のコードで該当する行を確認します。
   • cout << "user = '" << user << "'
     ";
   • cout << "day = '" << day << "'
     ";
   • string rep = res->getString("report");
     cout << "report = '" << rep << "'
     ";
     いずれも
     タグを含む文字列連結で直接 HTML に書き出しています。
3. ここで使われる変数は
   • user …… 利用者画面からの入力（図1「user ― 利用者画面からの入力を基に作成した営業社員名」）
   • day …… 利用者画面からの入力（図1「day ― 利用者画面からの入力を基に作成した、表示したい営業報告の日付情報」）
   • rep …… DB から取得した営業報告本文（図3 string rep = res->getString("report");)
     以上3つです。
4. したがって、出力時にエスケープ対象となる変数は
   user, day, rep
   となります。

誤りやすいポイント

• rep を見落とす
  DB 取得値も攻撃者が登録していれば XSS が成立します。入力値だけを対象にすると失点します。
• 変数名の綴りミス
  【問題文】に合わせて小文字で「user」「day」「rep」と書かないと誤答扱いになります。
• XSS と SQL インジェクションを混同
  どちらも入力値が関与しますが、前者は「出力時エスケープ」、後者は「プリペアドステートメント」で対策が異なります。

FAQ

解答の論理構成

1. C++ の脆弱性要因
   問題文は「〔脆弱性の要因となる問題〕 ・データを転記する際のメモリ領域の境界チェック漏れ ・eによる誤った領域へのアクセス …」と示しています。
   C++ でメモリ領域を直接扱う代表的な仕組みはポインタです。したがって、誤った領域へのアクセス原因となる e は「ポインタ」と判断できます。
2. 代表的な脆弱性名
   続けて「〔上記問題が引き起こす代表的な脆弱性〕 ・f ・整数オーバフロー」と列挙されています。
   境界チェック漏れやポインタ誤操作が招く典型的な脆弱性はバッファサイズを超えた書き込み・読み込み、すなわち「バッファオーバフロー」です。よって f は「バッファオーバフロー」になります。
3. Java が抱える性能面の注意点
   図6の説明では「長時間連続動作させる場合にはgの実行による応答性への影響を考慮する必要がある」と述べられています。
   Java で応答性に影響を与える自動メモリ回収機構は「ガーベジコレクション」です。表1の Java デメリット欄も同じ文脈で g を示しているため、答えは「ガーベジコレクション」となります。

誤りやすいポイント

• ポインタと配列添字を同一視してしまい、e に「配列」などを書いてしまう。
• C++ の脆弱性で「ヒープオーバフロー」や「スタッククラッシュ」を挙げ、f を細分類で答えて減点される。
• Java の性能低下要因をスレッド切り替えや Just-In-Time コンパイルと誤認し、g を「JIT コンパイル」としてしまう。

FAQ

解答の論理構成

• 【問題文】図5には「C++は、メモリ内容への柔軟なアクセスが可能である」とあり、その要因として「eによる誤った領域へのアクセス」「データへのeと、関数へのeを混同したアクセス」が列挙されています。ここでeはポインタを指し、メモリアドレスを自由に計算・参照できることが分かります。
• 同じく図5の〔上記問題が引き起こす代表的な脆弱性〕には「f」が挙げられています。すなわち「バッファオーバフロー」はポインタ操作に起因する典型的脆弱性です。
• 図6では「Javaが提供しているメモリ内容へのアクセス手段は限定的であり、メモリマネジメントは…Java VMが行う」と記述されています。ここから、Javaはポインタを公開しておらず、アドレス自体をプログラムから直接扱うことができない仕様であることが読み取れます。
• したがって、C++と異なり「アドレスを計算対象にできない」ことが、Javaでf攻撃が成立しにくい根本理由です。

誤りやすいポイント

• 「境界チェックを自前で書けるから Java でもバッファオーバフローは起こり得る」と誤解するケース
  → Javaは配列境界を超えるアクセス時に例外を送出し、任意の領域を書き換える前に実行が停止します。
• 「ガベージコレクションがあるから安全」として理由を GC に限定してしまうケース
  → GC はメモリ解放の自動化であり、ポインタ不在という根本仕様とは異なる観点です。
• 「Java の ‘unsafe’ ライブラリを使えばアドレス操作できる」と考え、例外的手段を一般仕様と混同するケース
  → 標準言語仕様の話題であり、特殊 API の使用は前提外です。

FAQ