n階層システム設計の考慮点

第8回 セキュリティ設計について

この記事を読むのに必要な時間:およそ 5.5 分

③ Web Formアプリケーションでの代表的な脅威とその対策について

Web FormアプリケーションではWindows Formアプリケーションで想定される脅威以上に以下の表に示すような脅威について対策を検討する必要があります。

表3 Web Formアプリケーションへの脅威とその対策

脅威 対策
ユーザ識別情報のなりすまし

強力な認証を使用します。Microsoft NTLMや第三者の認証機関の電子署名等を使用した認証方式を検討します。

認証Cookieは,SSL/TLSで保護します。

データの改ざん

強力な承認を使用します。Microsoft NTLMや第三者の認証機関の電子署名等を使用した認証方式を検討します。

④ 画面設計での考慮点とノウハウについて

画面設計を行う際に気を付けなければならない考慮点とノウハウについて説明します。

A) ソースコードからの情報漏洩

Webアプリケーションの場合,通常の操作ではソースコードは見ることはできませんが,サーバの脆弱性などによりソースコードの一部が流出することが考えられます。そのため,ソースコード内には内部で使用するユーザ名やパスワード等を記述せずに,安全な場所に格納されたファイルやConfigファイル内に外部ファイルとして記述するようにします。

しかし,Webアプリケーションの稼働中にはこれらのファイルの変更をしないようにします。

B) 画面からの情報漏洩

個人ごとに登録されたクレジットカード番号や口座番号を画面上に表示する場合,全桁を表示するのではなく,一部のみを表示するようにします。これにより,盗み見や不正アクセスなどにより攻撃者に知られても使用することができないようにします。

C) フィッシング詐欺

Webアプリケーションの場合,本物の画面とよく似た画面をもつサイトに移動させてクレジットカード番号などの個人情報を盗み取ろうとするフィッシング詐欺があります。さらに,フレームを使用して画面を設計している場合,サブフレームがフィッシング詐欺用の別のサイトに移動してもアドレスバーにはメインフレームのURLが表示されているため,見抜くことは難しいです。これを見抜くためには,アドレスバーに表示されているURLを確認したり,右クリックでサイトのプロパティを確認できるようにします。

D) ユーザによる表示ページの保護状態の確認不可

Webアプリケーションの場合,JavaScriptやブラウザの設定により,アドレスバーやステータスバーを非表示にすることができます。これにより,表示されているページがSSL/TLSによって保護されているか確認ができない場合があります。また,フレームを使用して画面を設計している場合,メインフレームがSSL/TLS対応になっていてもサブフレームがSSL/TLS対応になっていない可能性があります。この場合はステータスバーには保護マークが表示されたままになります。またこの逆の場合,つまりメインフレームがSSL/TLS非対応でサブフレームがSSL/TLS対応の場合ではステータスバーには保護マークが表示されません。これらを防ぐためには,以下の点を考慮して設計します。

  • アドレスバーを非表示にしない
  • ステータスバーを非表示にしない
  • フレームを使用して画面を構成するのではなく,CSSを使用する設計とする
  • 右クリックを禁止しない
  • SSL/TLS対応コンテンツとSSL/TLS非対応のコンテンツを混在させない

E) JavaScriptやActiveXのセキュリティレベルを変更しない

サイトによってJavaScriptやActiveXのセキュリティレベルを変更していると,変更し忘れで思わぬ攻撃を受ける場合があります。そのため,これらの設定は社内で決められた設定を使用し,変更しないようにします。

F) 入力チェック

入力チェックについては第3回に記載していますのでそちらをご参照ください。

G) サニタイジング

サニタイジングでは入力時のチェックだけと考えられがちですが,エラーの表示方法やメッセージについても考慮する必要があります。攻撃者がログイン画面などで「ユーザID⁠⁠,⁠パスワード」を総当たり攻撃をしてきた場合,⁠パスワードが間違っています。」といったメッセージを表示した場合,暗に「ユーザID」が存在していることを知らせていまいます。そのため,例えば「ユーザID,パスワードが間違っています。」とメッセージを変更するだけで保護性は高まります。

Webアプリケーションでは,存在しないページへの直接アクセス,ブックマークアクセス(セッション有効期限切れ等も含む)等のエラーメッセージも同一のカスタムエラーページとすることで,サーバ環境の情報や攻撃対象となるページの特定を防ぐことができます。

入力時のチェックとしては「SQLインジェクション⁠⁠,⁠OSコマンドインジェクション⁠⁠,⁠各プログラム言語の外部コマンドインジェクション⁠⁠,⁠SSI(Server Side Include)インジェクション⁠⁠,⁠LDAPインジェクション⁠⁠,⁠XPathインジェクション⁠⁠,⁠クロスサイトスクリプティング⁠⁠,⁠URLリクエストへの無効文字挿入⁠⁠,⁠メールヘッダ改ざん」等があります。これらの問題点と対策について説明します。

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。