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

ネットワークスペシャリスト 2012年 午後103


モバイル端末を利用したシステムの構築に関する次の記述を読んで、設問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)
 モバイル受発注システムでは、新たに 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リライティング

設問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効率化

設問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

設問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, 帯域幅, スループット

設問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ヘッダ

設問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, 暗号化通信, セッション管理

設問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パラメータ

設問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リライティング
戦国ITクイズ機能

\ せっかくなら /

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

クイズ画面へ遷移する

すぐに利用可能!

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

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