平成18年度テクニカルエンジニア情報セキュリティ午後T問題 (問1)

SEのための情報セキュリティ対策
情報セキュリティプロフェッショナル試験対策 過去問掲載
Home> 【午後】テクニカルエンジニア情報セキュリティ過去問題 >

平成18年度テクニカルエンジニア情報セキュリティ午後T問題 (問1)

平成18年度テクニカルエンジニア情報セキュリティ午後T問題 (問1)



スポンサードリンク




問1 Webサイトのセキュリティに関する次の記述を読んで.設問1〜4に答えよ。
 
 A社は,主として事業所向けに商品を販売している,従業員数80名の文房具卸売会社である。A社ではこれまで,インターネットを電子メールとWebの閲覧にしか使ってこなかったが,このたびインターネットを利用した受注Webシステム(以下,Xシステムという)を開発することに決めた。A社には情報システムを開発する部署がないので.現在インターネット接続を管理しているF主任をリーダとして,コンピュータに詳しい数名の従業員で構成した開発チームが,開発を行うことになった。
 
〔Xシステムの基本設計〕
 Xシステムでは,利用者はインターネットからWebサイトにアクセスし,商品を選択して発注すると,その利用者ID,発注商品名及び数量が営業担当の従業員に電子メールで通知される。営業担当の従業員はその電子メールに従って,利用者あてに商品,納品書及び請求書を発送する。当初の利用者数は1日当たり1,000人と想定している。F主任は,開発に先立って,注意すべき事項について開発チーム内で話し合うことにした。次は,そのときのF主任と開発チームの一員であるG君の会話である。
F主任 :Xシステムでは,画面遷移にセッション管理が必要だな。
G君 :そうですね。セッション管理には,セッションIDを使う方式と,利用者IDを使う方式があります。いずれの方式でも利用者のブラウザからサーバに利用者を識別するデータを送信しますが,この送信方式にはクッキーを使う方式,[  a  ]フィールドを使う方式,URLのクエリストリングを使う方式があるようです。それぞれの特徴を整理すると,表1のようになります。利用者からのデータの送信にはPOSTメソッドとGETメソッドの両方を使う予定ですが,送信方式はどの方式を用いるべきでしょうか。
 
表1 セッション管理用データの送信方式の特徴
方式 各方式の特徴
利用できる環境 HTTPリクエストヘッダのRefererフィールドからの情報漏えいの可能性
(ア)クッキーを使う方式 ブラウザがクッキーをサポートしている必要がある。 [  b  ]
(イ)[  a  ]フィールドを使う方式 HTMLフォームに限る なし
(GETメソッドを使う場合は“あり”)
(ウ)URLのクエリストリングを使う方式 上記(ア),(イ)のような制限はない [  c  ]
 
F主任 :表1の各方式の特徴の中で,利用者からのデータ送信に用いる方法を考慮して,情報漏えいの可能性が最も低い方式を選ぶのがよいだろう。Xシステムの利用者の多くは事業所内からアクセスすると想定できるので,携帯電話からのアクセスは考慮しないことにしよう。
G君 :分かりました。
F主任 :それから,クロスサイトスクリプティング脆(ぜい)弱性を悪用した攻撃など,利用者から入力されるデータは,悪意のある可能性がある。利用者からの入力データを含むWebページを生成してブラウザに表示する場合には,〔1〕攻撃に利用される文字を表2のように置き換える処理が必要だ。セキュリティ機能にかかわる部分は一貫した考え方が必要だと思うので.まとめてG君に考えて作成してもらいたい。
 
表2 文字の置換
元の文字 置換後の文字列 
&
[  d  ] [  e  ]
>
' '
"
注:正しく表示するため,全角文字で表示している
 
G君 :分かりました。これまで,本格的にセキュリティ機能の設計やコーディングを行ったことはないのですが,まず利用者認証とセッション管理について設計し,Perlでコーディングしてみようと思います。セッション管理については,コーディングの負担を減らし,短期間で開発するために利用者IDを使う方式にします。
F主任 :その場合でも,セッション管理用データが不正に作り出せないような設計をするように。また,総当たり法による攻撃も想定する必要がある。
 
〔設計レビュー〕
 3日後,G君は利用者IDを使用したセッション管理用データ(以下,識別コードという)の仕様とサブルーチンの基本仕様を作成し,一部分をコーディングして開発チーム内でレビューを受けた。G君が作成した,識別コードを使用したセッション管理の仕様を表3に,サブルーチンの基本仕様の一部を表4に,またコードの一部を図に示す。
 
表3 識別コードを使用したセッション管理の仕様(抜粋)
項 目 要  件
利用者ID,パスワード 利用者ID,パスワードの文字列長はともに6文字以上12文字以下とする。
識別コード 60文字以上の英数字とする。
タイムアウト 前画面からの遷移までに10分以上経過している場合は,タイムアウトエラーとする。
 
表4 サブルーチンの基本仕様(抜粋)
ルーチン名 処理概要 引数 戻り値 
clean_msg 引数の文字列中の攻撃に利用される文字を表2に従って置き換える。 1.文字列 処理された文字列
make_sid 識別コードを作成する。 1.利用者ID(文字列) 識別コードを表す文字列
encrypt 第1引数の文字列を第2引数の共
通鍵で暗号化する。
1.文字列(16文字以内)
2.128ビットの共通鍵を表す文字列(32文字)
暗号化された32文字の文字列
now 現在時刻を秒単位で得る。 なし YYYYMMDDhhmmss形式によって現在時刻を表す14文字の文字列
make_hash 引数の文字列をハッシュ関数で計
算した値を返す。
1.文字列 ハッシュ値を表す32文字の文字列
 
sub make_sid {
my ($user_ID) = @_;
my $enc_key = "4f583bd08d45092ca12408c8437ef4";
my $sid, $salt, $sid_time;
$sid_time = now;
$sid_time =~ /..$/;
$salt = $&;
$sid = encrypt($user_ID, $salt . $enc_key);
$sid = $sid . $sid_time;
$sid = $sid . make_hash($sid);
return $salt . $sid;
}
図 G君が作成したコード(抜粋)

 次は,レビューにおけるF主任とG君の会話である。
F主任 :識別コードの仕様について説明してくれないか。
G君 :はい。識別コードは,その生成時刻と利用者IDからなる文字列を基本情報として構成され,利用者がログイン後にWebサーバにアクセスする都度,生成されます。生成時刻は,識別コードがWebサーバに返されたときにタイムアウトを判定するために付けています。利用者IDは,識別コードが不正に作り出されることを防止するために,鍵長が128ビットの共通鍵暗号を使って暗号化しています。共通鍵は128ビットの固定値ではなく,そのうち8ビットを可変部分としました。8ビットを可変とすることで,毎回異なる識別コードが生成されるので安全です。また,改ざんを検出するために,暗号化した利用者ID及びサーバの時刻情報に,それらのハッシュ値を連結しています。このため識別コードは,[  f  ]文字の利用者ID部分,[  g  ]文字の時刻部分,[  h  ]文字のハッシュ部分を連結した文字列に,共通鍵の可変部分を先頭に加えて,合計[  i  ]文字で構成されます。
F主任 :この識別コードの作り方では,暗号化された利用者IDの部分には同じ文字列が現れることがある。また,〔2〕生成される識別コードは毎回異なるが,鍵の作り方から判断して安全性が高くなっているとは言えない。さらに,プログラムコードが漏えいした場合には,不正な識別コードを容易に作り出されてしまう問題もある。より高い安全性を確保するためには,利用者IDなど意味のあるデータを含まないセッションIDを用いてセッション管理を行う方がよいだろう。セッションIDはログイン時に生成することになるね。開発の期間は多少長くなるかもしれないが,セキュリティの方が重要だ。セッション管理の方式を見直してくれ。
G君 :はい,分かりました。
 

 
設問1 セッション管理方式について,(1),(2)に答えよ。
(1)  表1中の[  a  ]に入れる適切な字句を10字以内で答えよ。
(2)  表1中の[  b  ],[  c  ]に入れる適切な字句を,“あり”,“なし”のいずれかで答えよ。
 

 
設問2 セキュリティを考慮したコーディングについて,(1),(2)に答えよ。
 
(1)  本文中の下線〔1〕の処理は一般に何と呼ばれる処理か,10字以内で答えよ。
(2)  利用者からの入力データを含むWebページを生成してブラウザに表示する場合の対策として,表2中の[  d  ],[  e  ]に入れる適切な文字列を答えよ。
 

 
設問3 G君が設計した識別コードについて,(1),(2)に答えよ。
 
(1)  本文中の[  f  ]〜[  i  ]に入れる正しい数値を答えよ。
(2)  本文中の下線〔2〕で安全性が高くなっているとは言えないとF主任が指摘した理由は何か。55字以内で具体的に述べよ。ただし,プログラムコードは漏えいしていないものとする。
 

 
設問4 G君は,F主任が指示したセッションIDを,暗号を使わずに設計することにした。このセッションIDの設計において,不正なセッションIDを容易に作り出すことをできなくするために,セキュリティの面で留意すべきことを二つ挙げ,それぞれ20字以内で述べよ。
 




【午前】情報セキュリティアドミニストレータ
【午後】情報セキュリティアドミニストレータ

【午前】テクニカルエンジニア情報セキュリティ
【午後】テクニカルエンジニア情報セキュリティ

【午前】情報セキュリティプロフェッショナル
【午後】情報セキュリティプロフェッショナル





スポンサードリンク






スポンサードリンク
免責事項 / サイトマップ / リンク /  問い合わせ
Copyright (C) 2008  SEのための情報セキュリティ対策  All rights reserved