戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

ネットワークスペシャリスト 2012年 午後1 問03


モバイル端末を利用したシステムの構築に関する次の記述を読んで、設問1〜3に答えよ。

 F社は、機械部品の卸売業を営む中堅の企業であり、社内で受発注システムを利用している。  F社の受発注システムは、Webアプリケーションで構成されており、社内にネットワーク機器及び各種サーバが設置されている。社内の有線LANは、100BASE-TXを用いたイーサネットで構築されている。会議室には無線LANのアクセスポイント(以下、APという)が設置され、IEEE 802.11g規格の無線LANを利用して、会議室に設置したPCから社内ネットワークにアクセスできる。受発注システムのWebアプリケーションは、商品名と数量を受け付け、在庫の確認と製造元への発注処理を行う。一度の注文で複数の商品が発注可能になっている。多岐にわたる取扱商品の説明は、Webサーバのカタログページとファイルサーバのカタログデータに保有している。  現在、F社では顧客の注文依頼を、電話とファックスで受け付け、オペレータが社内のPCをクライアント端末に用いて、受発注システムに入力している。しかし、営業部員からは、客先を訪問した際に、その場でインターネットを通じて受発注処理をしたいという要望が出されていた。  F社は、営業部員の要望を受け、受発注システムをインターネット経由でも利用可能にし、クライアント端末を、ノートPCとモバイル端末に変更して、クライアント端末と社内ネットワークを無線LANで接続できるよう、受発注システムの変更を行うことにした。F社が開発計画中の新しい受発注システム(以下、モバイル受発注システムという)の構成を、図1に示す。
ネットワークスペシャリスト(平成24年度 午後1 問03 図01) ↩設問2(3) ↩設問3(2)
 モバイル受発注システムでは、新たにIEEE 802.11nを実装したAP、ノートPC及びモバイル端末を導入する予定である。モバイル端末には、スマートフォン、タブレット端末など複数の種類を用意し、社員は業務に適したものを利用する。ノートPCは社内だけで利用するが、モバイル端末は社外への持ち出しを許可し、社外からRPサーバを経由してWebサーバにアクセスできるようにする。   〔無線LANの設計〕  システム企画課のG君は、まず、社内の無線LANの設計に着手した。次は、無線LANネットワークの設計に関する、G君と上司のH氏の会話である。  H氏:今回無線LANの規格としてIEEE 802.11nを利用できるということだが、今まで使っていたIEEE 802.11gとはどこが違うのかな。  G君:はい。IEEE 802.11gでは帯域幅20 MHzであったのに対し、IEEE 802.11nでは40 MHzも利用可能となっています。これは隣り合う帯域幅20 MHzのチャネルを二つ束ねることによって、送信データ量を2倍以上に増やすアという技術を使ったものです。これによって、例えば20 MHzでは理論値で144 Mビット/秒だった伝送速度が、最大でイMビット/秒となります。また、送信側と受信側の双方で複数のアンテナを使い、同時に異なるデータを送信して受信時に合成するウという技術によって、データをより高速にやり取りすることができます。  H氏:同時に、従来のIEEE 802.11gを引き続き利用しても問題ないのかな。  G君:IEEE 802.11nとIEEE 802.11gで同じチャネルを使った場合には、通信ができないことがあります。それを回避するために、IEEE 802.11nのmixed modeでは、フレームの先頭にIEEE 802.11gと同じエを付加して通信のタイミングをとり、同時利用を可能にすることができます。ただし、遅い方の通信速度に影響を受けて、スループットが低下します。  H氏:その他にも、IEEE 802.11nを利用する上で、留意すべきことはあるかな。  G君:IEEE 802.11nでは、フレームアグリゲーションを使って、①フレームの送信待ち時間と確認応答の回数を減らすことで遅延時間を短縮し、データの高速なやり取りが可能になります。ただし、使用するアプリケーションによっては、②フレームアグリゲーションの影響を考慮する必要があります。  H氏:なるほど。フレームアグリゲーションを使用するかどうかは、アプリケーションとの組合せなど、様々な試行をして決定する必要があるということだな。その他、無線LAN以外の部分では、一部をギガビットイーサネットに変更することを検討すべきではないかな。インターネット経由のデータのやり取りを減らすために、客先へ行く前に、ファイルサーバからモバイル端末に、カタログデータをダウンロードしておきたいのだが。  G君:そうですね。APの設置と併せて検討してみます。   〔Webアプリケーションの改修〕  次にG君は、Webアプリケーションの改修について検討した。G君が考えた、モバイル端末とWebサーバ間の送受信シーケンスを、図2に示す。
ネットワークスペシャリスト(平成24年度 午後1 問03 図02)
 従来、F社のクライアント端末は同一機種のPCだけであり、Webアプリケーションでは、セッション管理にクッキーを利用していた。③今回導入するノートPCとモバイル端末は、画面の大きさやブラウザの種類など、様々な仕様となっている。また、それらのブラウザの中にはクッキーを受け入れないものがあることから、G君は、Webアプリケーションがブラウザに送るURLに、パラメタとしてSIDを埋め込む方法を採用することにした。これを オ という。さらに、G君は、モバイル端末を使って、インターネット経由の受発注処理を受け付けるようにするため、必要と思われる通信はSSLを使用することにした。  図2を検証したH氏は、Webサーバの負荷を軽減するために、SSLをWebサーバ以外の機器に実装するよう、G君に指示した。さらに、H氏は、セキュリティ上の問題があることから、SIDの付与に関して改善すべき点があることを指摘し、G君はH氏の指摘に従って、見直しを実施した。  G君の検討結果を反映して、F社のモバイル受発注システムは無事完成し、順調に稼働した。

設問1:

問題文を見る
本文中のア〜オに入れる適切な字句を答えよ。

模範解答

ア:チャネルボンディング イ:300 ウ:MIMO エ:プリアンブル オ:URLリライティング

解説

解答の論理構成

  1. ア について
    • 問題文では「隣り合う帯域幅20 MHzのチャネルを二つ束ねることによって、送信データ量を2倍以上に増やす」と記されています。
    • これは複数チャネルを“束ねる”技術であり、IEEE 802.11nの代表的キーワードは「チャネルボンディング」です。
  2. イ について
    • 続けて「20 MHzでは理論値で144 Mビット/秒だった伝送速度が、最大でイMビット/秒」とあります。
    • IEEE 802.11nで40 MHz・MIMO 2×2時の理論最大値が "300" Mbit/sであることは周知の仕様です。
  3. ウ について
    • 「送信側と受信側の双方で複数のアンテナを使い、同時に異なるデータを送信して受信時に合成する」と説明されている多重化技術は「MIMO」(Multiple Input Multiple Output) です。
  4. エ について
    • 「mixed modeでは、フレームの先頭にIEEE 802.11gと同じエを付加して通信のタイミングをとり」とある。
    • IEEE 802.11系でフレーム先頭につく同期用ビット列は「プリアンブル」です。
  5. オ について
    • 「Webアプリケーションがブラウザに送るURLに、パラメタとしてSIDを埋め込む方法を採用することにした。これを オ という。」と述べられています。
    • URLにセッションIDを埋め込む手法は「URLリライティング」と呼ばれます。
以上より、 ア:チャネルボンディング
イ:300
ウ:MIMO
エ:プリアンブル
オ:URLリライティング

誤りやすいポイント

  • 「チャネルボンディング」と「バンドステアリング」を混同しやすい。後者はAPが端末を2.4 GHz / 5 GHzに振り分ける機能で文脈が異なります。
  • IEEE 802.11nの理論値はアンテナ数・ガードインターバル長で変化します。問われているのは40 MHz+短GIではなく、一般的な「2×2 MIMO 40 MHz」の "300 Mbit/s"。
  • URLにセッションIDを付与する方法を「クッキーの代替」だと覚えていても名称が出てこないケースが多い。

FAQ

Q: IEEE 802.11nのmixed modeでスループットが低下する理由は何ですか?
A: 「IEEE 802.11gと同じプリアンブル」を付けることで互換性は確保できますが、伝送がg端末に合わせた制御となり、高速なn端末でも待ち時間が増えるためです。
Q: URLリライティングを使うときのセキュリティ上の注意点は?
A: セッションIDがURLに露出するため、履歴・リファラや第三者への転送で漏えいしやすくなります。HTTPS化やワンタイムID、タイムアウト短縮などの対策が必要です。
Q: MIMOとアンテナダイバーシティの違いは?
A: ダイバーシティは受信品質向上が目的で同一データを複数アンテナで扱います。MIMOは複数ストリームを同時送信してスループット向上を狙う点が異なります。

関連キーワード: IEEE 802.11n, チャネルボンディング, MIMO, URLリライティング

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:〔無線LANの設計〕について、(1)〜(3)に答えよ。

問題文を見る
(1)本文中の下線①を実現する、フレームアグリゲーションの仕組みを、25字以内で述べよ。

模範解答

宛先が同じ複数のフレームを連結して送信する。

解説

解答の論理構成

  1. 本文では、IEEE 802.11nの特徴として「フレームアグリゲーション」を挙げ、下線部で「①フレームの送信待ち時間と確認応答の回数を減らす」仕組みだと述べています。
  2. 送信待ち時間や確認応答(ACK)はフレーム1本ごとに発生します。そこで複数フレームをまとめれば、待ち時間もACKも1回で済みます。
  3. まとめる条件は“同じ送信先”であることです。送信先が変われば受信側で順序管理が複雑化し、ACKも個別に必要になるためです。
  4. したがって「宛先が同じ複数のフレームを連結して送信する」ことで下線部の狙いを達成でき、これがフレームアグリゲーションの本質です。

誤りやすいポイント

  • 「大容量フレームを作る」とだけ答えると、“宛先が同じ”条件が欠け減点となります。
  • 逆に「ACKをまとめる」と説明しても、具体的な操作(フレーム連結)が示されていないと不十分です。
  • フラグメント(分割送信)と混同し、逆の意味を書いてしまうケースがあります。

FAQ

Q: フレームアグリゲーションはIEEE 802.11n以外でも使えますか?
A: 802.11acなど後続規格にも採用されていますが、802.11gにはありません。
Q: 連結することで誤りが増えませんか?
A: 誤り訂正はMAC層で行い、再送単位もアグリゲート全体ではなくサブフレームごとに制御できます。
Q: ACK回数が減ることで省電力効果もありますか?
A: はい。送受信機会が減るため、特にバッテリー駆動のモバイル端末で効果があります。

関連キーワード: フレームアグリゲーション, ACK削減, IEEE 802.11n, 無線LAN効率化

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:〔無線LANの設計〕について、(1)〜(3)に答えよ。

問題文を見る
(2)本文中の下線②でG君が指摘した、フレームアグリゲーションの影響はどのようなものであると考えられるか。40字以内で具体的に述べよ。

模範解答

無線チャネルの占有時間が長くなり、その間は他の通信が待たされる。

解説

解答の論理構成

  1. 問題文では、IEEE 802.11nの機能として
    「①フレームの送信待ち時間と確認応答の回数を減らすことで遅延時間を短縮」
    と述べられています。
  2. しかし同時に「②フレームアグリゲーションの影響を考慮する必要があります」と注意書きがあります。
  3. フレームアグリゲーションは複数のMACフレームを1つにまとめて送るため、1回の送信で占有する時間(送信時間+SIFSなどの保護時間)が長くなります。
  4. 無線LANではCSMA/CAが採用されており、メディア(チャネル)は1台が送信している間、他端末は送信できません。
  5. したがって、巨大化したアグリゲートフレームを送信している間は「他端末の通信が待たされ、応答性が低下する」という影響が生じます。
  6. 以上より、設問の答えは
    「無線チャネルの占有時間が長くなり、その間は他の通信が待たされる。」
    となります。

誤りやすいポイント

  • 「遅延時間を短縮できる」とだけ覚え、占有時間の増大という副作用を忘れる。
  • 有線LANと混同し、CSMA/CAによる排他制御の影響を考慮しない。
  • 「パケットロス時の再送量が増える」など、直接の影響でない点を挙げてしまう。
  • 電波干渉や帯域幅40 MHzの話題に引っ張られ、フレームアグリゲーション固有の問題を書き漏らす。

FAQ

Q: フレームアグリゲーションは常に有効にすべきですか?
A: 音声・リアルタイム通信など応答性重視のアプリケーションでは、占有時間の増大が遅延を招く場合があります。用途に応じてパラメータ(AMPDU長など)を調整することが推奨されます。
Q: アグリゲーションで占有時間が長くなってもスループットは高くなるのでは?
A: 送信端末自身のスループットは向上しますが、同一チャネルを共有する他端末の待ち時間が延び、ネットワーク全体の公平性や応答性が低下することがあります。
Q: 40 MHzチャネル幅とフレームアグリゲーションは別機能ですか?
A: 別機能です。40 MHzは帯域幅を広げて生の物理レートを上げる仕組み、フレームアグリゲーションはMAC層で複数フレームをまとめてオーバヘッドを減らす仕組みです。

関連キーワード: フレームアグリゲーション, 無線チャネル占有, CSMA/CA, IEEE 802.11n

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:〔無線LANの設計〕について、(1)〜(3)に答えよ。

問題文を見る
(3)H氏が指摘した、ギガビットイーサネットに変更する区間を2か所、図1の機器名を用いて答えよ。

模範解答

①:ファイルサーバとSWの間 ②:SWとAPの間

解説

解答の論理構成

  1. 【問題文】では社内有線LANが「100BASE-TX」を前提としており、このままではモバイル端末へ大量のカタログデータを転送する際にボトルネックになります。
  2. H氏は「インターネット経由のデータのやり取りを減らすために、客先へ行く前に、ファイルサーバからモバイル端末に、カタログデータをダウンロードしておきたい」と発言しています。
  3. モバイル端末へ至る主経路は
      「ファイルサーバ → SW → AP → 無線区間 → モバイル端末」
     です。高速化の対象は無線区間“以外”と明言されているので、有線部分のうちデータ量の大きい区間を「ギガビットイーサネット」に置き換えるのが合理的です。
  4. したがって、
     ① 「ファイルサーバ とSWの間」
     ② 「SWとAPの間」
     を1000BASE-Tへ格上げすることで、カタログデータ転送時の待ち時間を大きく短縮できます。

誤りやすいポイント

  • 「APから先の無線区間を高速化」と誤読し、ギガビット対応AP導入だけで済むと思い込む。実際には有線側の100BASE-TXが律速になります。
  • APではなく「Webサーバ」方向を高速化すると答えるミス。今回の高速化目的はカタログデータの事前ダウンロードなので、ファイルサーバ経由の経路が最優先です。
  • SW(スイッチングハブ)を介さずサーバ同士を直結すると誤想定。図1では全てのサーバがSW配下に集約されているため、SW経由が前提となります。

FAQ

Q: なぜ「DBサーバ とSWの間」は対象外なのですか?
A: DBサーバはカタログデータの大量転送ではなく取引情報の読み書きが主体であり、瞬間的な帯域要求は比較的小さいためです。
Q: APだけギガビット対応にする意味はありますか?
A: APのuplink速度が1000BASE-Tでなければ、多数端末が同時接続した際に無線側のスループットを活かせません。そのため「SWとAPの間」をギガビット化します。
Q: ファイルサーバ側ポートをギガビット化しても、クライアントが100Mbpsなら効果はありますか?
A: 同時に複数端末へ配信する際、バックボーン帯域に余裕が生まれるため全体スループットが向上します。端末個々のピーク速度もSW~AP区間を1Gbps化することで底上げできます。

関連キーワード: ギガビットイーサネット, ボトルネック, 無線LAN, 帯域幅, スループット

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:〔Webアプリケーションの改修〕について、(1)〜(4)に答えよ。

問題文を見る
(1)本文中の下線③に対応するための、Webアプリケーションの改修内容を40字以内で述べよ。また、その場合に、Webアプリケーションが参照するHTTPリクエストのヘッダ部のフィールドの名称を答えよ。

模範解答

改修内容:モバイル端末の種類に対応した形式のページコンテンツを送るようにする。 名称:User-Agent

解説

解答の論理構成

  1. 端末特性の多様化
    【問題文】では「③今回導入するノートPCとモバイル端末は、画面の大きさやブラウザの種類など、様々な仕様となっている」と明記されています。したがって、端末ごとに最適化されたページを返却しなければ閲覧性・操作性が低下します。
  2. 端末識別に必要な情報源
    HTTPのリクエストで端末情報を伝える代表的なヘッダが「User-Agent」です。ここにはブラウザ名・バージョン・OS・端末種別などが含まれます。
  3. 具体的な改修内容へ結び付け
    サーバ側で「User-Agent」を解析し、スマートフォン向け/タブレット向け/PC向けなど端末に合わせたHTML・CSS・画像サイズを動的に切り替える仕組みを組み込みます。
  4. 結論
    以上より、改修内容は「モバイル端末の種類に対応した形式のページコンテンツを送るようにする」。参照するヘッダ部のフィールド名称は「User-Agent」となります。

誤りやすいポイント

  • Accept-LanguageやAcceptなどと取り違え、「User-Agent」を選べない。
  • 画面解像度に応じてCSSを切り替えるだけで十分と判断し、サーバ側改修の必要性を見落とす。
  • 端末識別にCookieを使おうとして、そもそも「クッキーを受け入れないものがある」制約を忘れる。

FAQ

Q: クライアント側でレスポンシブWebデザインを採用すればサーバ改修は不要では?
A: 画面幅のみで最適化できる場合は有効ですが、端末種別やブラウザ機能差によってはサーバが出力するリソース形式自体を変えた方が効率的です。
Q: User-Agentは偽装できるのでは?
A: 完全な判別は困難ですが、主要ブラウザは正しい値を送るのが一般的です。不正アクセス対策としては追加で機種登録や認証を組み合わせます。
Q: 将来新しい端末が増えた場合の対応策は?
A: User-Agentパターンを外部設定ファイルやDBに持たせ、更新時に再デプロイせず追加できる設計が望ましいです。

関連キーワード: User-Agent, コンテンツネゴシエーション, レスポンシブデザイン, HTTPヘッダ

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:〔Webアプリケーションの改修〕について、(1)〜(4)に答えよ。

問題文を見る
(2)H氏がG君に指示した、SSLを実装すべき機器名を、図1から一つ選んで答えよ。

模範解答

RPサーバ

解説

解答の論理構成

  1. H氏の狙いを確認
    【問題文】には「図2を検証したH氏は、Webサーバの負荷を軽減するために、SSLをWebサーバ以外の機器に実装するよう、G君に指示した。」とあります。すなわち、SSLハンドシェイクや暗号処理をWebサーバから切り離し、別の機器で“SSLオフロード”することが要求されています。
  2. SSLを終端できる候補機器を図1から抽出
    図1(モバイル受発注システムの構成)に示されている社内外の主な機器は「ルータ」「FW」「SW」「DNSサーバ」「RPサーバ」「Webサーバ」などです。このうち、Webサーバ自身は除外する必要があります。
  3. 条件を満たす機器の特定
    SSLを終端し、暗号化された通信を復号して内部のHTTPへ中継する役割として最も適切なのは、DMZ内に配置された「RPサーバ」であると判断できます。リバースプロキシは元々、①SSL終端、②キャッシュ、③負荷分散などを担う設計が一般的で、要件「Webサーバの負荷を軽減」に合致します。
  4. 結論
    以上より、SSLを実装すべき機器は「RPサーバ」となります。

誤りやすいポイント

  • 「FW」にSSL機能を持たせると考えてしまう
    ファイアウォールはパケットフィルタリングやNATが中心で、SSL終端機能は前提とされていません。
  • 「ルータ」を選択するミス
    ルータは経路制御が主目的であり、SSLオフロードを担当する設計はまれです。
  • 「DNSサーバ」と混同
    DNSは名前解決専用で、HTTP/HTTPSを中継しません。Webサーバ負荷軽減の文脈と結び付かない点に注意が必要です。

FAQ

Q: なぜSSLをRPサーバに実装するとWebサーバの負荷が下がるのですか?
A: SSLの暗号化・復号化処理はCPU負荷が高いため、RPサーバで終端して平文HTTPでWebサーバに渡せば、Webサーバは暗号処理を実施せずに済みます。
Q: RPサーバでSSL終端した場合、内部ネットワークは平文になりますか?
A: DMZ内から社内LANへは平文HTTPで流れる構成になります。必要に応じて内部でもHTTPSを使う二重暗号化構成を検討できます。
Q: セッションIDがURLに含まれるときの追加対策はありますか?
A: HTTPSページへのリダイレクト統一、SIDの使い回し制限、URL書き換え時のヘッダ制御やReferer制御などがあります。

関連キーワード: SSLオフロード, リバースプロキシ, DMZ, 暗号化通信, セッション管理

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:〔Webアプリケーションの改修〕について、(1)〜(4)に答えよ。

問題文を見る
(3)H氏が指摘したセキュリティ上の問題を、30字以内で述べよ。

模範解答

非SSLの通信時に、SIDが漏えいするおそれがある。

解説

解答の論理構成

  1. 【問題文】では、G君が「Webアプリケーションがブラウザに送るURLに、パラメタとしてSIDを埋め込む方法」を採用し、「これを オ という」とあります。
    → SIDはURLに含まれるため平文で送受信される可能性があります。
  2. 図2には多数の “非SSL” 区間が描かれ、そこでも「SID=xxx」「SID=yyy」などが付いた要求・応答が行われています。
    → 平文HTTP区間でSIDがネットワーク上に露出することが読み取れます。
  3. H氏は「セキュリティ上の問題があることから、SIDの付与に関して改善すべき点がある」と指摘しました。
  4. 平文HTTPでは暗号化されないため、盗聴・キャプチャによりSIDが第三者に知られる危険があります。SIDを奪取されるとセッションハイジャックが成立します。
  5. 以上より、H氏が指摘した問題は
    「非SSLの通信時に、SIDが漏えいするおそれがある。」
    となります。

誤りやすいポイント

  • 「SSLが必要な通信だけ暗号化」と読んで、ログイン後も常時SSLにすべきと気付かない。
  • URL埋込型SIDとクッキーの違いを混同し、「クッキーが無効だから安全」と誤解する。
  • 図2に“SSL”と書かれている区間だけを見て「全部暗号化されている」と思い込む。
  • SID漏えい=セッションハイジャックにつながる危険を過小評価する。

FAQ

Q: なぜURLにSIDを入れると危険なのですか?
A: URLはリクエストラインに平文で載り、プロキシやアクセスログにも残ります。非SSL区間では盗聴者が容易に取得でき、SIDを奪われると正規ユーザになりすまされます。
Q: SSL区間だけを暗号化する運用では駄目なのでしょうか?
A: SSLと非SSLを混在させると、非SSL側でSIDが漏えいします。安全を確保するにはログイン後すべてのページをSSLに統一する、もしくは非SSL区間ではSIDを含めない設計が必要です。
Q: クッキーを使えばこの問題は解決できますか?
A: クッキーでも非SSLで送れば同じく漏えいします。根本対策は通信経路の暗号化と、漏えいしても影響を最小化する短寿命・ワンタイムSIDの導入などです。

関連キーワード: セッションID, HTTPS, セッションハイジャック, パケット盗聴, URLパラメータ

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:〔Webアプリケーションの改修〕について、(1)〜(4)に答えよ。

問題文を見る
(4)SIDの付与に関するH氏の指摘に従って、G君が実施した見直しの内容を、35字以内で述べよ。

模範解答

非SSLの状態からSSLを利用する際は、SIDを振り直す。

解説

解答の論理構成

  1. 図2のシーケンスでは、非SSLの通信で「トップページ表示 SID=xxx」が払い出され、その後SSLで認証完了すると「ログイン完了表示 SID=yyy」と SIDが変更されています。
  2. H氏は「セキュリティ上の問題があることから、SIDの付与に関して改善すべき点がある」と指摘しました。
  3. HTTP(非SSL)の状態で発行したSIDを、そのままHTTPS(SSL)へ持ち込むと、盗聴や セッションフィクセーション攻撃でなりすましを招く危険があります。
  4. そこでG君は「SSLを利用する際は、SIDを振り直す」という対策を採用し、SSL確立後に新しいSID(yyyなど)を再発行する設計へ見直しました。

誤りやすいポイント

  • 「SSLにしたから安全」と考え、HTTPで発行したSIDを続けて使用してしまう。
  • 認証完了後ではなく、認証前にSIDを更新してしまい、ユーザ識別が曖昧になる。
  • URLパラメータにSIDを埋め込む方式では、ブラウザが自動的に送出するため盗聴されやすい点を見落とす。

FAQ

Q: なぜクッキーではなくURLにSIDを埋め込むのですか?
A: 「ブラウザの中にはクッキーを受け入れないものがある」ため、確実にセッションを維持する方法としてURLへの埋め込み(URLリライティング)を選択しています。
Q: SIDを振り直すタイミングは認証後と書籍にありますが、本問では「SSLに切り替えたら振り直す」と読めばよいのですか?
A: はい。本問は「非SSL → SSL」に遷移する場面が認証直後に一致しているため、そのタイミングで新しいSIDを再発行する実装が求められています。
Q: URLにSIDが入るとブックマークしたとき危険では?
A: 危険です。ブックマークやRefererに残る恐れがあります。SIDを短寿命にする、ログアウト処理で無効化するなど追加対策が必要です。

関連キーワード: セッションID, SSL/TLS, セッションフィクセーション, HTTPS, URLリライティング

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

ネットワークスペシャリストを
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について