復習問題 2026-09-30

解答: a

昨日の第1問は、192.168.10.0/26 から見て .70 は別ネットワークだ、というところで終わりました。では別ネットワークだと分かった PC は次に何をするのか——それが今日の問題です。

大前提として、実際にフレームを運ぶイーサネットは MAC アドレスしか見ません。つまり送信するには必ず「次に渡す相手の MAC アドレス」が要ります。PC はサブネットマスクの計算結果で、その相手を2通りに切り替えます。

ここが午前で狙われる点です。別ネットワーク宛てでも、IP ヘッダの宛先 IP は最終目的地のままで変わりません。変わるのは外側のフレームの宛先 MAC だけで、ルータを1つ越えるたびに書き換えられていきます。「IP は端から端まで、MAC は隣の1区間だけ」と覚えると混ざりません。

b は誤りで、この場合に ARP で聞くのはゲートウェイの MAC であって宛先の MAC ではありません（そもそも別ネットワークの機器には ARP のブロードキャストが届きません。ARP は同じネットワーク内にしか流れないからです）。c はグローバルかプライベートかという別の切り口で、判定に使われるのはサブネットマスクとの計算結果だけです。d は名前から IP を引く DNS の話で、ARP はその後段——IP から MAC を引く段——にあたります。

3つのアドレスの並びで整理しておくと、この先の問題でも迷わなくなります。

解答: b

昨日の NAPT は「IP アドレス＋ポート番号を書き換える」仕組みでした。そのポート番号を持っているのがこの2つ、トランスポート層のプロトコルです。ここを押さえると NAPT の話が一段はっきりします。

選び分けの基準は「届かなかったときに困るか、遅れる方が困るか」の一点です。ファイルは1バイト欠けたら壊れるので TCP。通話や動画は、欠けた音を再送してもらっても遅れて届くだけで意味がないので UDP。昨日出てきた DHCP が UDP なのは、そもそもまだ自分の IP アドレスが無い状態でブロードキャストする必要があり、コネクションを張れないからです。

a と c は TCP と UDP を入れ替えた誤答で、この2つは毎回このパターンで作られます。d は明確な誤りで、UDP にもポート番号はあります（DNS は 53、DHCP は 67/68）。ポート番号はトランスポート層の機能で、どちらにも共通です。

ウェルノウンポートは午前でそのまま問われるので、よく出るものだけ。

解答: b

昨日の表で名前だけ出して中身に触れていなかった行です。これで「攻撃と対策」の主要4つが揃います。

SQL インジェクションは、入力値がデータではなく SQL 文の一部として解釈されてしまう攻撃です。たとえば WHERE 名前 = '入力値' という文を文字列連結で組み立てていると、入力に ' OR 'A'='A と書かれた瞬間に条件が常に真になり、全件が返ります。原因は文法と値が混ざることにあります。

プレースホルダは、先に WHERE 名前 = ? という形で SQL の文法を確定させ、値は後から ? の場所へはめ込みます。値の中に ' や OR が入っていても、文法はもう決まったあとなのでただの文字として扱われる——これが効く理由です。XSS と対にして覚えると筋が通ります。

a は昨日の第3問の答え（XSS）、c は一昨日の答え（CSRF）、d はパスワードリスト攻撃・総当たり攻撃への対策です。「エスケープ＝XSS、プレースホルダ＝SQL、トークン＝CSRF」の3語だけで午前のこの手の問題はほぼ処理できます。8/22 に「トークンと エスケープが混ざる」と書いてあったところは、3つ目を足しても混ざらない形になりました。

なお午後 問1 では「入力値のチェックだけでは不十分な理由を述べよ」という形でよく問われます。答えの筋は、チェックは想定した文字の漏れに弱く、プレースホルダは文法が確定しているので漏れという概念自体が無い——という対比です。

解答: b

昨日は同じ「受注明細」を正規化の側から見ました。今日はそれを取り出す側です。午後 問6 は正規化と SQL の2本立てで出るので、両方から触っておきます。

要は WHERE と HAVING の違い1点だけで、判定基準は「集計の前か、後か」です。

a は WHERE に SUM() を書いており誤りです。WHERE が動く時点ではまだ行が1本ずつバラバラで、合計は計算されていません。この「まだ存在しないものは参照できない」という順番が、そのまま句の並び順にもなっています。

c は句の順序が逆で構文エラー。SQL は書く順番が決まっています。

SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY

d は GROUP BY SUM(数量) という集計値でのグループ化になっており、求めているものと違います。グループ化するのはまとめたい単位の列（ここでは商品番号）です。

実行される順番で読むと丸ごと納得できます。FROM で表を出し、WHERE で行を絞り、GROUP BY で商品番号ごとの束にし、HAVING で束を絞り、最後に SELECT で列を選ぶ——書く順と実行順が違うのは SELECT だけ、と覚えておけば十分です。

解答: a

昨日の第5問で「相手の公開鍵で隠す、自分の秘密鍵で署名する」まで来ました。今日はその穴を埋める問題です。

穴というのはこういうことです。公開鍵は誰でも配れる。ということは、攻撃者が「これが B の公開鍵です」と言って自分の公開鍵を配ることもできてしまいます。そうなると A はそれを B の鍵だと信じて暗号化し、中身は攻撃者に読まれます（中間者攻撃）。公開鍵暗号そのものは、その鍵が本当に本人のものかを保証しません。

そこで、信頼できる第三者である認証局が「この公開鍵は確かに B のものです」と保証書を出す。その保証書がディジタル証明書で、中身は利用者の公開鍵＋持ち主の情報に、認証局の秘密鍵で署名を付けたものです。昨日の表の下の行——「作れるのは本人だけだから証明になる」——を、認証局が自分の鍵でやっている形です。

「では認証局の公開鍵は誰が保証するのか」と続きますが、ここはルート証明書としてブラウザや OS にあらかじめ組み込まれていることで打ち止めになります。この連なりが信頼の連鎖（トラストチェーン）で、全体の枠組みを PKI（公開鍵基盤）と呼びます。HTTPS でブラウザが証明書を検証しているのが、まさにこの手順です。

b は署名の対象が秘密鍵になっており誤り。秘密鍵は誰にも渡さないものなので、認証局に預ける時点で成り立ちません。c は共通鍵を渡す方法がなく（昨日の鍵配送問題そのもの）、そもそも公開鍵は隠す必要がありません。d は利用者の秘密鍵で暗号化しており、それでは利用者が自分で自分を保証しているだけで、第三者の保証になりません。

失効の扱いも一緒に。秘密鍵が漏れた証明書は有効期限内でも無効にする必要があり、その一覧が CRL（証明書失効リスト）、1件ずつ問い合わせる仕組みが OCSP です。名前だけでも出ます。