|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
本章の内容は、日本政府が情報セキュリティ対策のための統一基準を定めた、「政府機関等の情報セキュリティ対策のための統一基準群（平成28年度版）」(http://www.nisc.go.jp/active/general/kijun28.html)の内容に基づいています。
出展：「府省庁対策基準策定のためのガイドライン （平成 28 年度版）」
（https://www.nisc.go.jp/active/general/pdf/guide28.pdf）
「府省庁対策基準策定のためのガイドライン （平成 28 年度版）」
（https://www.nisc.go.jp/active/general/pdf/guide28.pdf） を加工して作成。
本章では、WebOTXを利用する上で、実施すべきセキュリティ対策について説明します。
システムにログインするユーザの認証、アクセス制限、権限管理は、システムのセキュリティを高める上で重要な役割を果たします。 WebOTXに関わる主なユーザとして、OSで管理するユーザ情報、WebOTXの運用管理操作を行うユーザ(運用管理ユーザ)、配備されたアプリケーションにログインするユーザがあります。 本章では、これらのユーザのうち、運用管理ユーザのセキュリティ対策について説明します。
運用管理ユーザを適切に管理し、不正アクセスを防止するために以下のことを推奨します。
1つの運用管理ユーザを複数人で使い回すと、意図しない人物から不正な運用管理操作が行われても見過ごしてしまう可能性があります。
ユーザは共通の特性によってグループ単位に分けることができます。複数のユーザをグループとしてまとめることで、ユーザの管理、アクセス制御がしやすくなります。
WebOTXインストール直後、またはサンプルとして提供しているドメイン定義プロパティを利用してドメインを作成した場合、運用管理ユーザ(admin)が既定の設定で作成されます。 adminユーザのパスワードは既定の文字列が設定されるため、そのまま使用し続けることは非常に危険です。このパスワードは必ず変更してください。
また、インストール時やドメイン作成時に使用したproperitesファイル(ドメイン定義ファイル)は作成時のみに使用されるため、不要である場合は削除してください。
ユーザ管理の詳細については、[ 構築・運用: ドメインの構築 > ユーザ管理 > ユーザ管理の概要 ]を参照してください。
WebOTXの運用管理ユーザはFileレルムを認証レルムとして使用する必要があります。 運用管理ユーザの作成・削除方法は、[ドメインの構築 > ユーザ管理 > Fileレルムを利用したユーザ管理 > ユーザ]を参照してください。
パスワードの変更手順は、[ 構築・運用: ドメインの構築 > ユーザ管理 > Fileレルムを利用したユーザ管理 > ユーザ > ユーザの更新 > パスワードの変更]を参照してください。
その他、アプリケーションを使用するためのユーザもWebOTXで管理することができます。アプリケーション向けのユーザは使用する認証レルムにより作成方法、削除方法が異なります。それぞれ以下を参照してユーザを作成・削除してください。
ユーザ管理の手段として、ユーザの作成・削除以外に、使用しないユーザを無効化しておくことで、それらのユーザに対する不正ログインを防止することができます。 WebOTXでは、運用管理ユーザを無効化する機能を提供しています。
運用管理ユーザの有効化/無効化はcreate-file-userコマンド、またはupdate-file-userコマンドの--enableオプションに、有効化の場合はtrue、無効化の場合はfalseを指定することで切り替えることができます。
[運用管理コマンドを利用する場合]
otxadmin > update-file-user --enable <true/false> --authrealmname admin-realm <運用管理ユーザ名>
また、統合運用管理ツールのユーザ管理画面からも有効化/無効化を切り替えることができます。詳細については、 [構築・運用: ドメインの構築 > ユーザ管理 > Fileレルムを利用したユーザ管理 > ユーザ] を参照してください。
認証のセキュリティ強度を向上させるための手段として、ユーザのパスワード認証のセキュリティを強化することが考えられます。 WebOTXでは、管理するユーザのパスワード認証のセキュリティを強化するために、以下の機能を提供しています。
ユーザのパスワードに対して、8文字以上かつ、英数字と大文字小文字を含めなければならないという制限をつけることができます。
連続でのログイン失敗回数に上限値を設け、この上限値を超えた場合は、次回ログイン試行までに一定の期間 ログイン試行を受け付けないようにします。
パスワード認証のセキュリティを強化のための機能の利用手順を説明します。
JVMオプションに-Dcom.nec.webotx.admin.password.complexity=trueを設定することで、 ユーザのパスワードに対して、8文字以上、英数字、大文字小文字を含めなければならないという制限をつけることができます。
詳細については、[ 構築・運用: ドメインの構築 > ユーザ管理 > Fileレルムを利用したユーザ管理 > ユーザ ] を参照してください。
ロックアウト機能は、以下の手順で有効化することで利用できます。
[運用管理コマンドを利用する場合]
otxadmin > set server.admin-service.lockout.enabled=true
詳細については、[構築・運用: ドメインの構築 > ユーザ管理 > 運用管理ユーザのロックアウト]を参照してください。
認証情報の漏えいを防ぐ手段として、認証情報の暗号化、認証情報へのアクセス制限などが考えられます。 WebOTXでは、運用管理ユーザの認証情報の漏えいを防ぐために、以下の機能を提供しています。
WebOTXで管理されるすべてのユーザのパスワードは、通信時に暗号化されています。また、パスワードを保存する際は暗号化された状態で保存されています。
特定の運用管理ユーザに対して認証情報にアクセス可能なロールを付与することで、その他の運用管理ユーザが認証情報へアクセスすることを制限します。
運用管理ユーザのパスワードに有効期限を設け、定期的にメッセージを出してパスワードの変更を促します。パスワードを定期的に変更することで、なりすましの被害を受け続けることを避けることができます。
パスワードの暗号化については、インストール時の状態ですべてのパスワードが暗号化されており、復号化された状態で通信、保存されることはありません。以下、ロール機能、パスワードの有効期限管理機能の利用方法を説明します。
認証情報へのアクセス制限は、ロール機能を有効化し、用意されているuserManagerロールを特定の運用管理ユーザが所属するグループに付与することで、そのグループに所属する運用管理ユーザにのみアクセス権限を与えることができます。
[運用管理コマンドを利用する場合]
otxadmin > set server.admin-service.role-manager.enabled=true
otxadmin > add-custom-role-config --role userManager --kind group <グループ名>
ロール機能の詳細については、[構築・運用: ドメインの構築 > ユーザ管理 > ロール > 運用管理ユーザのロール]を参照してください。
パスワード有効期限管理機能はcreate-file-userコマンド、またはupdate-file-userコマンドの--enablepasswordageオプションに、true/falseを指定することで機能の有効化/無効化を切り替えることができます。 また、--passwordageオプションにてパスワードの有効期間を日数で指定することができます。
[運用管理コマンドを利用する場合]
otxadmin > update-file-user --enablepasswordage <true/false> --passwordage <パスワードの有効期間(日数)> --authrealmname admin-realm admin1
パスワード有効期限管理機能の詳細については、[構築・運用: ドメインの構築 > ユーザ管理 > 運用管理ユーザのパスワード有効期限管理 ]を参照してください。
ロールとは、ユーザ/グループが持つ役割の事です。個人、またはグループにロールを付与することで、そのユーザまたはグループが実行できる処理を限定したり、アクセスできるデータを制御することができます。 WebOTXでは、運用管理ユーザ向けにロール機能を提供しています。
ロール機能の詳細については、[ロール]を参照してください。
ロール機能の利用方法についていくつかの例を挙げて説明します。運用管理ユーザ向けのロールは、運用管理ユーザが所属するグループに付与することで運用管理操作の実行権限を付与します。
例1 設定の閲覧ユーザの作成
運用管理ユーザをlogin以外のグループに所属させないように設定した状態で、ロール機能を有効化すると、設定の閲覧のみ可能な運用管理ユーザを作成することができます。
[運用管理コマンドを利用する場合]
otxadmin > create-file-user --authrealmname admin-realm --userpassword xxxxxx viewer1
otxadmin > set server.admin-service.role-manager.enabled=true
otxadmin > logout
otxadmin > login --user viewer1 --password xxxxxx
上記のようにlogin以外のグループに所属しない運用管理ユーザとして、viewerユーザが既定で用意されています。viewerユーザは無効化されていますので、使用する場合は有効化して利用してください。
例2 アプリケーション配備ユーザの作成
ユーザ管理やドメイン管理など、業務上使用頻度の高いロールはあらかじめ用意されています。 それらのロールに対してはすでに必要なコマンド及び操作が登録されているため、ロール機能を有効化し、グループに対してロールを付与するだけで使用することができます。 ここでは、アプリケーション配備者向けのロールを使用するユーザを作成します。
[運用管理コマンドを利用する場合]
otxadmin > create-file-user --authrealmname admin-realm --groups deployers --userpassword xxxxxx deployer1
otxadmin > set server.admin-service.role-manager.enabled=true
otxadmin > add-custom-role-config --role deployer --kind group deployers
otxadmin > logout
otxadmin > login --user deployer1 --password xxxxxx
ロール機能の利用手順の詳細については、[構築・運用: ドメインの構築 > ユーザ管理 > ロール > 設定方法]を参照してください。
インターネット上で送受信されるデータは、盗聴、改ざんを防止するため、通信時に暗号化することが推奨されています。 WebOTXでは、クライアントから運用管理コマンドを実行する際にprotocolオプションにjmxmpを指定した上で、secureオプションをtrueにすることで、ドメインとの通信にSSL/TLSを利用することができます。
ドメインとの通信にSSL/TLSを利用するためには以下の設定を行います。
[運用管理コマンドを利用する場合]
otxadmin > set server.admin-service.jmx-connector.system-option.enabled=true
otxadmin > set server.admin-service.jmx-connector.system-option.security-enabled=true
以上で設定は完了です。
クライアントからSSLを利用してドメインに接続するにはコマンドに--secureオプションでtrueを指定します。loginコマンドの実行例を以下に示します。
otxadmin > login --user admin --password adminadmin --port 6712 --protocol jmxmp --secure=true
アプリケーションを経由しての攻撃に対処するために、あらかじめ実行できるプログラムやアクセス可能な領域を限定することで、安全性を強化することができます。
WebOTXでは、各サービスが動作するために必要なセキュリティポリシーをデフォルトで以下のファイルに記述しています。
${INSTANCE_ROOT}/config/server.policy
アプレット (またはセキュリティマネージャの下で動作しているアプリケーション) が、ファイルの読み書きなど、セキュリティ保護された操作を行うためには、その操作を行うためにアクセス権を付与する必要があります。必要に応じてserver.policyファイルに必要な権限を設定するようにしてください。
セキュリティポリシー、ポリシーファイルの記述に関する詳細は、Java SDK の 「セキュリティ」 に関する情報を参照してください。
WebOTXは標準設定で、WebOTXに関する操作の記録や、利用者のアクセス履歴をログファイルに出力しますので、これらを不正侵入や不正操作の検証に利用することができます。 WebOTXがログに出力する情報のうち、セキュリティ上の問題の調査に活用できるものは以下の通りです。
WebOTXに関する操作履歴
WebOTXのサービス起動停止や設定変更に関する情報です。意図せぬ運用操作が行われていないかを確認できます。
アクセス履歴
WebOTXのサービスへのアクセス履歴に関する情報です。想定外のIPアドレスからのアクセスや意図せぬ宛先へのアクセスの有無等を確認できます。
ログについての詳細は、[ 構築・運用 > ログ ] を参照してください。
WebOTXが出力するログによるセキュリティ検証を行う場合は、具体的には以下のログを利用してください。
WebOTXに関する操作履歴
| ログ名 | ファイルパス | 概要 |
|---|---|---|
| agent_operation.log | ${INSTANCE_ROOT}/logs | 統合運用管理ツールまたは運用管理コマンドからの運用操作履歴 |
| adminconsole_operations.log | ${INSTANCE_ROOT}/logs/agent | 運用管理コンソールの操作履歴 |
アクセス履歴
| ログ名 | ファイルパス | 概要 |
|---|---|---|
| access.log | ${INSTANCE_ROOT}/logs/web | WebOTX Webサーバへのアクセス履歴 |
| server_access.log | ${INSTANCE_ROOT}/logs | Webコンテナへのアクセス履歴 |
| manager_access.log | ${INSTANCE_ROOT}/logs | 運用管理コンソールへのアクセス履歴 |
各種ログ出力からセキュリティの問題を調査するためには、ログファイルは適切な情報な出力されており、 なおかつ十分な期間保全されている必要があります。 WebOTXでは、これらの事項を保証するために、以下の機能を提供しています。
WebOTXのログをサーバ内に保存する期間の設定です。WebOTXではログファイルの肥大化を防ぐためにログローテーションにより古いログを自動的に削除します。
ログに出力するメッセージフォーマットの設定です。 ログに出力されたイベントメッセージは、そのイベントを発生させた主体者を特定するための識別情報を含まなければなりません。 WebOTXが出力する各種ログは既定の設定でこの要件を満たすため、特にメッセージフォーマットを変更する必要はありません。
ログに出力するメッセージにイベント発生時刻を出力する設定です。 WebOTXが出力する各種ログは既定の設定でこの要件を満たすため設定を変更する必要はありませんが、 出力された時刻が適切であることを保証するために、OSの機能によりサーバの時刻を正しく設定する必要があります。
システムが攻撃を受けた際、メモリやCPUの使用率、コネクション数が普段とは異なる場合があります。このような変化を監視しておくことで、攻撃にいち早く気付くことができます。 WebOTXには統計レポートという機能があり、一定時間ごとにメモリの使用率、CPUの使用率を含む様々な性能情報を収集し、CSVファイルへ出力することができます。
統計レポート機能は以下のコマンドを実行して有効化します。
[運用管理コマンドを利用する場合]
otxadmin > set server.diagnostic-service.statistics-report.enabled=true
統計レポートの詳細な利用方法は、[ 構築・運用 > 診断サービス > 統計レポート ] を参照してください。
WebOTXでは診断サービスという機能を提供しています。診断サービスは、アプリケーションサーバの障害解析に必要な情報を、複雑な手順や設定を行うことなく取得し、 さらに取得した情報を収集して１つのアーカイブファイルにまとめる機能です。 主に以下の情報を、不正侵入や不正操作などの検証に利用できます。
オペレーティングシステムのメモリ使用状況、ディスク使用状況、ネットワークの状態などの情報を攻撃やサーバ不正操作による過負荷の検出に利用できます。
サーバ、ドメインの運用管理エージェントへのアクセスログは、サーバやドメインへの不正侵入や不正操作の検証に利用できます。 また、標準出力・標準エラー出力に関するログや、各サービスに関するログ、JVMが出力するエラーログファイルなどは、システムの異常動作の検証に利用できます。
各種の統計情報です。サーバへの攻撃や不正操作の検証に利用できます。
診断サービスで収集可能な情報についての詳細は、 [ 構築・運用 > 診断サービス > 診断サービスの設定 ] を参照してください。
診断サービスの利用方法について説明します。
まず、取得したい情報をあらかじめ設定しておく必要があります。
[運用管理コマンドを利用する場合]
otxadmin > set server.diagnostic-service.system=true
次のコマンドを入力して、診断を実行します。
otxadmin > generate-diagnostic-report domain1
このコマンド実行によって、情報を収集したzipファイルが作成されます。
診断サービスの利用方法についての詳細は、
[ 構築・運用 > 診断サービスの実行 ] を参照してください。
セキュリティ脆弱性のWebOTX製品への影響に関しては、製品Webサイトにて重要なお知らせとして順次公開します。
重要なお知らせの[影響のある製品]を確認し、利用している製品・バージョン・対象OSに該当する場合、[対処方法]または[回避方法]を参照して対策を実施してください。
[対処方法]としてパッチ適用が記載されている場合、サポートポータルから利用製品・バージョン・OSのパッチをダウンロードして適用してください。
(注意) 一部を除いてパッチモジュールは製品保守契約を結んでいただいたお客様に限定して提供させていただいています。
まだ契約がお済でないお客様は、保守契約締結の後、ダウンロードをお願いいたします。
重要なお知らせの最新情報については下記をご確認ください。
http://jpn.nec.com/webotx/index.html
重要なお知らせの[対処方法]にパッチ適用およびパッチ公開ページへのリンクが記載されている場合、リンク先であるNECサポートポータルにて利用している製品・バージョン・OSに対応するパッチのREADMEとパッチモジュールをダウンロードしてください。パッチの適用方法に関してはREADMEを参照してください。
NECサポートポータル(保守契約者のみ)
https://www.support.nec.co.jp/PSLoginSupportId.aspx
WebOTXでは、Apache HTTP ServerベースのWebOTX Webサーバとは別にJavaベースの内蔵Webサーバを提供しています。内蔵Webサーバにはクライアントとのやり取りを行うリスナと呼ぶコンポーネントが存在します。既定の状態で「HTTPリスナ1」と「HTTPリスナ2」がありますが、SSL通信を行うリスナは「HTTPリスナ2」です。
内蔵Webサーバ利用時にクライアントとの間の通信でセキュリティを確保するには、SSL通信を行うリスナである「HTTPリスナ2」を有効にし、このHTTPリスナ2に対してクライアントから [https://〜] とアクセスします。
また、HTTPリスナ2の既定のポート番号は443となっていますので、ファイアウォールやプロキシでもしこのポート番号を遮断しているる場合は許可してください。
内蔵WebサーバでSSLを利用する場合、セキュリティ上非SSL用のリクエスト受付口(HTTPリスナ1)は不要です。ここではまずその設定を行います。
otxadmin> set -u admin -w adminadmin server.http-service.virtual-server.server.network-listeners=http-listener-2
otxadmin> set -u admin -w adminadmin server.network-config.network-listeners.network-listener.http-listener-1.enabled=false
以上が内蔵WebサーバでSSLを利用する基本的な設定になります。この後、内蔵Webサーバに対してサーバ証明書の設定や必要に応じてクライアント認証の設定、暗号化アルゴリズムの設定などを行います。引き続き [ リファレンス ＞ 設定 ＞ 共通SSL設定 ] を参照してください。
本章では、WebOTXで利用するWebサーバに関するセキュリティ対策を説明します。
WebOTX Webサーバでは、接続元のIPアドレスやネットワークドメイン単位に、アクセスを許可したり禁止したりすることができます。 それによって、公開されている情報の重要度やインターネットからアクセス可能か否か等に応じて、部外者からのアクセスを防いだり、攻撃を防いだりすることを検討する必要があります。
Webサーバの定義情報ファイル (httpd.conf) を直接編集して設定を行います。定義例は次の通りです。
例) http://server/webapp 配下に配備されているWebアプリケーションに対して、 yourdomain.com からのアクセスを禁止する場合<Location /webapp> Order Deny,Allow Deny from yourdomain.com ... </Location>
設定方法の詳細は、[ 構築・運用 > ドメインの構築 > Webサーバガイド > 運用 > 特定クライアントに対するアクセス制限 ] を参照してください。
攻撃等によるサーバリソースの枯渇を防ぐための対策として、WebOTX Webサーバでは、最大同時接続数を指定することが可能です。 最大同時接続数の既定値400を超えるユーザからの接続が見込まれる場合は、そのユーザ数に応じた接続数に変更してください。その際、ブラウザによっては6本程度までの同時接続が行われることをご留意ください。
それ以外の特定クライアントに限定したアクセス数の制限や、帯域制限を行うことも考えられますが、WebOTXではそうした機能を提供しておりません。別途、そのための製品をご利用ください。
最大同時接続数の変更方法は、次の通りです。
[運用管理コマンドを利用する場合]
otxadmin > set server.WebServer.MaxClients=250
otxadmin > invoke server.WebServer.stop otxadmin > invoke server.WebServer.start
最大同時接続数の変更に伴って見直すべき他の項目など、詳細は、[ 構築・運用 > ドメインの構築 > Webサーバガイド > 運用 > 最大同時接続数の変更 ] を参照してください。
WebOTX Webサーバにおいて、既定で出力するログと、その出力内容は次の表の通りです。
WebOTX Webサーバへのアクセスで問題が発生した場合は、エラーログ (error.log/error_log) ファイルを確認し、問題の原因につながる情報が出力されていないかを確認してください。また、アクセスログ (access.log/access_log/ssl_request.log/ssl_request_log) で、想定外のクライアントからのリクエストが無いかや、想定されたリクエスト数かを定期的に確認することも検討する必要があります。
| ログファイル名 | 出力内容 |
|---|---|
| error.log (Windows) error_log (UNIX) |
サーバ起動/停止、および、サーバ動作に問題が発生した場合に情報を出力します。既定では、WebOTX Webサーバにバンドルする rotatelogs を利用して、ファイルサイズ10Mバイト、世代数3でローテートします。 |
| access.log (Windows) access_log (UNIX) |
HTTP通信時のアクセス情報を出力します。1 行が 1 リクエストに対応しています。既定では、WebOTX Webサーバにバンドルする rotatelogs を利用して、ファイルサイズ10Mバイト、世代数5でローテートします。既定の設定での出力イメージは次の通りです。127.0.0.1 - - 2017-10-01 10:20:28 "GET /manual/ HTTP/1.1" 200 9743 1656250左から順に、次の項目を出力します。 (IP アドレス) (リモートログ名) (認証リモートユーザ名) (アクセス日) (アクセス時刻) "(リクエスト行)" (HTTPステータスコード) (送信バイト数) (処理時間[マイクロ秒]) |
| ssl_request.log (Windows) ssl_request_log (UNIX) |
HTTPS通信時のアクセス情報を出力します。1 行が 1 リクエストに対応します。既定では、WebOTX Webサーバにバンドルする rotatelogs を利用して、ファイルサイズ10Mバイト、世代数5でローテートします。既定の設定での出力イメージは次の通りです。2017-10-01 10:20:28 127.0.0.1 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /manual/ HTTP/1.1" 200 9743 15625左から順に、次の項目を出力します。 (アクセス日) (アクセス時刻) (IP アドレス) (プロトコルバージョン) (暗号スイート) "(リクエスト行)" (HTTPステータスコード) (送信バイト数) (処理時間[マイクロ秒]) |
| mod_jk-24.log | Webサーバプラグインモジュールの動作トレースや障害内容を出力します。 |
エラーログのフォーマットは、WebOTX Webサーバの定義情報ファイル (httpd.conf / ssl.conf) の、ErrorLogFormatディレクティブで、また、アクセスログのフォーマットは、LogFormatディレクティブで変更可能です。変更後は、WebOTX Webサーバの再起動を行ってください。
なお、通常、アクセスログは、リクエスト処理が終わったタイミングで、リクエストを受け付けた時刻を出力します。例えば、リクエストの受け付け時刻と、リクエスト処理の終了時刻をミリ秒単位まで両方記録する場合の定義例は次の通りです。
LogFormat "%h %l %u [%{%Y-%m-%d %H:%M:%S}t.%{msec_frac}t] [%{end:%Y-%m-%d %H:%M:%S}t.%{end:msec_frac}t] \"%r\" %>s %b %D" common
定義情報ファイル内の、ログに関するディレクティブ、および、ログフォーマット文字列については、[ リファレンス > 設定 > HTTPサーバ > WebOTX Webサーバ設定方法 > ログ出力 ] を参照してください。
WebOTX Webサーバでは、mod_status モジュールを利用した統計情報採取機能を提供しています。これにより、運用管理エージェント上で、現在の接続数や、総アクセス数等を、運用管理コマンドや、統合運用管理ツールで参照することが可能です。 これらの情報により、過負荷になっていないか等をご確認ください。
採取可能な情報については、[ リファレンス > MBean > 統計情報一覧 > 採取可能なパフォーマンス情報 > WebServerStats ] を参照してください。
運用管理コマンドにより、WebOTX Webサーバの統計情報を採取する手順は次の通りです。
otxadmin > set server.monitoring-service.module-monitoring-levels.web-server=LOW
otxadmin > invoke server.WebServer.stop otxadmin > invoke server.WebServer.start
otxadmin > get --monitor server.web-server.*
統合運用管理ツール/運用管理コンソールからの情報取得方法等については、[ 構築・運用 > モニタリング > モニタリング情報の採取 ] を参照してください。
WebOTX Webサーバで脆弱性が見つかった場合は、その影響有無等の情報を、製品Webサイトで重要なお知らせとして公開し、脆弱性の影響がある場合は、対応するパッチを公開しています。
また、WebOTX Webサーバは、Apache HTTP Server をベースとしており、SSL (HTTPS) 通信を実現する mod_ssl モジュールでは、 OpenSSL のライブラリをリンクしています。 Apache HTTP Server Project、および、OpenSSL Software Foundation から公開される脆弱性に関する情報も有用です。
セキュリティ問題に関する情報は変化していますので、常に最新の情報をご確認頂くよう、ご留意ください。
WebOTX Webサーバの脆弱性に関する情報をはじめ、WebOTXに関連する重大な障害や、他製品の障害によるWebOTXへの影響、その他重要なお知らせは、次のページで公開しています。
Apache HTTP Serverと、OpenSSL の脆弱性情報は、次のページで公開されています。
クライアントとWebサーバ間の通信における情報漏洩を防ぐために、SSLを利用して通信データを暗号化することが有効です。 WebOTX Webサーバでは、OpenSSLライブラリを利用したmod_sslモジュールを使用して、SSL 3.0、および、TLS 1.0/1.1/1.2/1.3 を利用し、かつ、128Bit以上の暗号化方式をサポートしています。また、SSLクライアント認証機能も利用可能です。
WebOTX Webサーバでは、評価用のサーバ証明書と秘密鍵ファイルを提供していますので、インストール直後でも、評価用のサーバ証明書を利用することにより、 次のコマンドにより、SSL通信機能を有効化して WebOTX Webサーバを再起動することで、SSL通信を利用することができます。
[運用管理コマンドを利用する場合]
otxadmin > set server.WebServer.security-enabled=true
また、SSL通信で利用するサーバ証明書や、秘密鍵等は、WebOTX WebサーバのSSL通信に関する定義情報ファイル (ssl.conf) にて指定します。 関連する主なディレクティブは次の通りです。
| ディレクティブ名 | 説明 |
|---|---|
| SSLCertificateFile | サーバ証明書のパスを指定します。通常、サーバ証明書のサブジェクト(Common Name(CN))に設定する値と、WebOTX Webサーバが動作するサーバサイトURL (例: https://www.yourdomain.com/ の場合、www.yourdomain.com) を一致させる必要があります。 |
| SSLCertificateKeyFile | 秘密鍵ファイルのパスを指定します。 |
設定例は次の通りです。
<VirtualHost _default_:443>
:
ServerName <バーチャルサーバのFQDN/IPアドレス>:443
:
SSLEngine on
SSLCertificateFile "/opt/WebOTX/WebServer24/conf/ssl.crt/server.crt"
SSLCertificateKeyFile "/opt/WebOTX/WebServer24/conf/ssl.key/server.key"
:
</VirtualHost>
詳細は、[ 構築・運用 > ドメインの構築 > Webサーバガイド > 運用 > SSL(HTTPS通信) 設定方法 ]、および、[ リファレンス > 設定 > 共通SSL設定 > WebOTX Webサーバを使う場合 ] を参照してください。 なお、サーバ証明書を第三者機関 (認証局) で発行した場合は、認証局の指定に従ってください。その際、Apache HTTP Server 向けの説明を参考にしてください。
また、定義情報ファイル内の、その他のSSL通信に関するディレクティブについては、[ リファレンス > 設定 > HTTPサーバ > WebOTX Webサーバ設定方法 > SSL定義 ] を参照してください。
SSLクライアント認証を利用する場合は、WebOTX Webサーバの定義情報ファイル (ssl.conf) にて、設定を行います。関連する主なディレクティブは次の通りです。
| ディレクティブ名 | 説明 |
|---|---|
| SSLCACertificateFile | クライアント証明書を発行した認証局 (CA) の証明書を指定します。 |
| SSLVerifyClient | クライアント側での証明書の提示方式を設定します。次のいずれかを指定します。 none : クライアント認証を要求しない。 optional : クライアント認証を要求する。クライアントから有効な証明書が提示されなくても、処理を続行します。 require : クライアント認証を要求する。クライアントから有効な証明書が提示されない場合、エラーを発生させます。 optional_no_ca : クライアント認証を要求する。クライアントから提示された証明書が検証できなくても、処理を続行します。 |
| SSLVerifyDepth | クライアント証明書に署名した認証局の階層の最大数を指定します。 |
設定例は次の通りです。
<VirtualHost _default_:443>
:
SSLCACertificateFile "/opt/WebOTX/WebServer24/conf/ssl.crt/ca-bundle.crt"
SSLVerifyClient require
SSLVerifyDepth 3
:
</VirtualHost>
詳細は、[ リファレンス > 設定 > 共通SSL設定 > WebOTX Webサーバを使う場合 > 双方向認証の場合の手順 ] を参照してください。 なお、クライアント証明書を第三者機関 (認証局) で発行した場合は、認証局の指定に従ってください。その際、Apache HTTP Server 向けの説明を参考にしてください。
WebOTX Webサーバの既定の定義情報ファイル (httpd.conf) では、必須の機能、および、一般的に有用な機能を提供するモジュールを、LoadModuleディレクティブにより有効化しています。ただし、システムの構成によっては、利用しないモジュールもあると考えられます。 それらのモジュールを有効なままにしておくことによって、脆弱性の影響を受ける可能性が高まりますので、セキュリティ強化や、無駄なリソースの消費を避けるためにも、できる限り不要な機能は無効化してください。
定義情報ファイルにおいて、有効になっている機能 (モジュール) を、無効化するための手順は次の通りです。定義情報ファイルの変更後は、変更を反映するためにWebOTX Webサーバの再起動が必要です。
例) mod_cgid モジュールを無効化する場合LoadModule cgid_module /opt/WebOTX/WebServer24/modules/mod_cgid.so変更後 ： 行頭に # を付けてコメントアウトします。
#LoadModule cgid_module /opt/WebOTX/WebServer24/modules/mod_cgid.so
WebOTX Webサーバでは、定義情報ファイル (httpd.conf) 中のDirectoryディレクティブで指定したディレクトリに対して、OptionsディレクティブでIndexesを指定しない場合、ディレクトリインデックス表示機能が「無効」 (ディレクトリ一覧を非表示) になります。
この機能を「有効」にした状態で、http://<host_name>/ にアクセスした場合、DirectoryIndex ディレクティブで指定したファイル (例えば、index.html) が対象ディレクトリに存在しなければ、ディレクトリ内のファイル一覧が表示されます。これにより、ファイルやディレクトリ構成等を暴露することになり、セキュリティ上問題となる可能性があります。
httpd.con中の既存の Options ディレクティブを変更する場合や、新たに Directory ディレクティブを追加する場合は、上記の点にご留意ください。
WebOTX Webサーバのディレクトリインデックス表示機能は、対象 Directory ディレクティブ内の Options ディレクティブで Indexes オプションを指定するかどうかによって、有効 / 無効を切替えます。また、+ や - 付きで指定した場合は、親ディレクトリの設定に対してマージされます。+ を付けると追加され、- を付けると削除されます。
なお、Directory ディレクティブ内に、Options ディレクティブの指定が無い場合、ディレクトリインデックス機能は無効となります。
ディレクトリインデックス表示機能を有効にする場合の定義例は、次の通りです。
<Directory "/opt/WebOTX/domains/domain1/docroot"> Options Indexes … </Directory> <Directory "/opt/WebOTX/domains/domain1/docroot/spec"> Options -Indexes … </Directory>
詳細は、[ リファレンス > 設定 > HTTPサーバ > WebOTX Webサーバ設定方法 > ディレクトリ一覧表示機能の無効化 ] を参照してください。
WebOTX Webサーバには、そのベースとなっている Apache HTTP Server のマニュアルも含まれており、既定の定義情報ファイル (httpd.conf) では、http://<host_name>/manual で、マニュアルへのアクセスが可能となっています。 ただし、システム本番運用開始後は、セキュリティ観点で「不要なページを公開しない」という考え方から、当該マニュアルを非公開、あるいは、公開を制限することを検討してください。
Apache HTTP Serverマニュアルを非公開にするには、WebOTX Webサーバの定義情報ファイル (httpd.conf) 内のマニュアルに対するAliasMatchディレクティブをコメントアウトします。変更例は次の通りです。
#AliasMatch ^/manual(?:/(?:ja|da|de|en|es|fr|ko|pt-br|ru|tr|zh-cn))?(/.*)?$ "<WebOTXインストールディレクトリ>/WebServer24/manual$1"
なお、公開を制限する方法については、[ 特定クライアントに対するアクセス制御 ] を参照してください。
また、WebOTX Webサーバの定義情報ファイル (httpd.conf / ssl.conf) において、Directory ディレクティブで定義しているディレクトリに、公開すべきではない、不要なファイルが存在しないことを確認してください。
WebOTX Webサーバが生成するエラードキュメントのフッタや、クライアントへのレスポンスの Server ヘッダには、既定では、次のような製品名やバージョンに関する情報が含まれます。
WebOTX_Web_Server/2.4.xx (Win64) OpenSSL/1.x.x Webserver_Plugin/1.2.x.x
Webサーバの正確なバージョン情報が含まれていることで、その脆弱性を狙った有効な攻撃を特定しやすくなります。そのため、バージョン情報を非表示にすることを検討する必要があります。
WebOTX Webサーバの設定ファイル (httpd.conf) に、ServerTokens ディレクティブの指定を行うことで、バージョン情報を削除し、製品名のみにすることが可能です。ただし、WebOTX Webサーバの製品名そのものを削除することはできません。
ServerTokens ProductOnly
本章では、WebOTX上で動作するアプリケーションに関するセキュリティ対策を説明します。
ロールとは、ユーザ/グループが持つ役割の事です。Webアプリケーションの配備記述子(web.xml, nec-web.xml)でアクセス制限したいURLにロールを割り当ててロールとユーザ/グループのマッピングを指定することで、特定の個人やグループのみにアクセスを限定する事ができます。また、アクセス制限するURLには拡張子指定やディレクトリ配下全てのパターンも指定することができるためアクセス可能領域を細かく限定することが可能です。
ロールの定義内容と相関関係は以下のとおりです。
| web.xml 配備記述子要素 | 説明 | |||
|---|---|---|---|---|
| web-app | servlet | security-role-ref | role-name | アプリケーションのコード上で使用しているロール名を指定します。本設定とrole-link をマッピングすることによって、コードの実装を変える事無く正しいロールにリンクさせることが可能となります。 |
| role-link | アプリケーションのコード上で使用しているロール名にマッピングするロール名を指定します。[web-app > security-role > role-name]に合致するロール名が定義されている必要があります。 | |||
| security-constraint | web-resource-collection | web-resource-name | アクセス制限設定の名称を定義します。 | |
| url-pattern | アクセス制限の対象となるURLパターンを指定します。これによって特定のURLについてのアクセス制限が可能となります。web-resource-collection要素配下に複数指定可能です。 | |||
| http-method | アクセス制限の対象となるHTTPメソッド種別を指定します。web-resource-collection要素配下に複数指定可能で、指定が無い場合は全てのメソッドが対象になります。 | |||
| auth-constraint | role-name | アクセス制限するURLへのアクセスを許可するロール名を指定します。[web-app > security-role > role-name]に合致するロール名が定義されている必要があります。 | ||
| security-role | role-name | Webアプリケーションで利用する全てのロール名を定義します。 | ||
| nec-web.xml 配備記述子要素 | 説明 | ||
|---|---|---|---|
| nec-web-app | security-role-mapping | role-name | 認証ユーザまたはグループに対応付けるロール名を指定します。[web-app > security-role > role-name]に合致するロール名が定義されている必要があります。 |
| principal-name | [role-name] に対応付ける認証ユーザ名を指定します。security-role-mapping 要素配下に複数指定可能です。 | ||
| group-name | [role-name] に対応付ける認証ユーザが所属するグループ名を指定します。security-role-mapping 要素配下に複数指定可能です。 | ||
配備記述子の作成方法や設定項目の詳細については [ アプリケーション開発 > Webアプリケーション > プログラミング・開発ガイド > Webアプリケーションのデプロイ > web.xmlデプロイメント記述子 ] をご覧ください。
Webアプリケーションでは、web.xmlの<security-constraint>要素で、Webアプリケーションのリソースへのアクセスを制御できます。
しかし、Servlet 3.0未満の古い仕様に準拠したアプリケーションサーバではこの制御が十分ではなく、<security-constraint>要素で指定していないHTTPメソッドでリソースにアクセスする事が可能です。
これに対処する設定がServlet 3.0仕様で追加されたました。TomcatやWebOTX V9以前のバージョンからWebアプリケーションをV10.11に移行する場合は次に説明します設定を追加してください。
例えば次のように定義する事で、/resource配下へGETメソッドでアクセスする際にadminロールによる認証が必要となります。
＜security-constraint＞
＜web-resource-collection＞
＜web-resource-name＞Protected Area＜/web-resource-name＞
＜url-pattern＞/resouce/*＜/url-pattern＞
＜http-method＞GET＜/http-method＞
＜/web-resource-collection＞
＜auth-constraint＞
＜role-name＞admin＜/role-name＞
＜/auth-constraint＞
＜/security-constraint＞
しかし、この設定では<http-method>要素で指定していないPOSTメソッドやPUTメソッドで/resource配下にアクセスすると、認証の必要なくアクセスが可能です。
<http-method>要素で指定したメソッド以外のメソッドでのアクセスを防御するには、次の通り<http-method-omission>要素で拒否したいHTTPメソッドを指定します。<auth-constraint>要素は子要素なしで指定します。
＜security-constraint＞
＜web-resource-collection＞
＜web-resource-name＞Protected Area - Deny methods＜/web-resource-name＞
＜url-pattern＞/resouce/*＜/url-pattern＞
＜http-method-omission＞POST＜/http-method-omission＞
＜http-method-omission＞PUT＜/http-method-omission＞
＜/web-resource-collection＞
＜auth-constraint/＞
＜/security-constraint＞
上記設定を行う事で、<http-method>要素で指定したメソッド以外のメソッド(上記の例ではPOSTメソッドとPUTメソッド)でのリソースにアクセスした場合は403エラー(Forbidden)となります。
Express、およびStandardのエージェントプロセス上で動作する業務アプリケーションでログを出力する場合、次の方法があります。
javax.servlet.ServletContext#log(java.lang.String msg) やjavax.servlet.ServletContext#log(java.lang.String message, java.lang.Throwable throwable)を利用する方法です。この方法で出力したログは、エージェントプロセスに配備した場合は ${INSTANCE_ROOT}/logs/agent.logに、プロセスグループに配備した場合はプロセスグループのログに出力されます。
アプリケーションが独自にLog4jモジュールを同梱してそれを利用してログを出力した場合は、エージェントプロセスに配備した場合もプロセスグループに配備した場合もLog4jの設定で指定した場所に出力されます。
いずれの方法も、システムの情報やアプリケーションの稼働情報、お客様が入力した情報などを出力する可能性があり重要な情報となります。これらのファイルの出力場所やアクセス権限については十分配慮してください。
WebOTX ASがサポートするServlet/JSPのAPIは次をご覧ください。[ リファレンス ＞ Java EE ＞ JavaTM Platform, Enterprise Edition (Java EE) 7 ]
agent.logについては [ 構築・運用 ＞ ログ ＞ WebOTXのログについて ＞ ドメインを構成するサービスについて ] をご覧ください。また、プロセスグループのログについては [ プロセスグループ上で動作する業務アプリケーションのログ出力 ] をご覧ください。
ログの出力情報、最大ファイルサイズやログレベル、ローテーションの設定変更については、[ 構築・運用 ＞ ログ ＞ WebOTXのログ ＞ 設定一覧 ＞ WebOTX AS ログ設定一覧 ] をご覧ください。
Standard のプロセスグループ上で動作するアプリケーションの標準出力や標準エラー出力は、サーバアプリケーショントレースとして出力します。 また、JavaVMが出力する標準出力（GCログ、フルスレッドダンプ、など）は、サーバアプリケーショントレースおよびシステムトレースに出力します。 これらの情報は、アプリケーションの稼働情報を確認する重要な情報となります。さらに攻撃者による不正侵入や不正操作などの検証にも利用できます。
アプリケーションが出力する情報が出力されます。アプリケーションの実装に依存しますが、稼働情報を確認することができます。
プロセスグループの起動情報、JavaVM で発生した障害情報を検証することができます。
プロセスグループのログの利用手順については以下をご確認ください。
また、プロセスグループは多重度を設定することができるため、プロセスグループ上からファイルにログ出力を行う場合は以下を参照してください。
SQLインジェクションとは、アプリケーションのセキュリティ上の不備を利用してアプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃手法のことです。
以下は、アプリケーションの入力チェックに不備があり、SQL文として意味を持つ文字をそのまま受け入れてしまう場合の例です。
不正なデータとして、「' OR '1'='1」という文字列が入力されると、作成されるSQL文は「name='user1' AND password=''」と常に真となる
「'1'='1'」のOR条件となり、結果的にpersonテーブルのすべてのレコードが選択されるという、アプリケーションが想定していない結果となってしまいます。
以下で、Webアプリケーションでの対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
OSコマンドインジェクションとは、アプリケーションの入力パラメータにOSのコマンドを挿入することで、アプリケーションに 想定外のOSコマンド実行させ、任意のファイルの読み出し、変更、削除、パスワードの不正取得などを行う攻撃手法です。
以下で、Webアプリケーションでの対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
ディレクトリトラバーサル攻撃とは、ファイル名やディレクトリ名に相対パス指定を用いることで、
プログラムが意図していないファイルやディレクトリにアクセスする攻撃です。
例えば、ファイル名に「../」など、上位のディレクトリを意味する文字列を用いることにより、
公開を意図していない親ディレクトリにアクセスします。
以下で、Webアプリケーションでの対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
セッション管理の脆弱性は、セッションIDを盗用されるセッションハイジャック、
第三者の用意したセッションIDを使用させられるセッションフィクセイション(セッションの固定化)
といった、悪意ある第三者がセッションIDを用いて利用者になりすます攻撃です。
以下の図はセッションハイジャック、セッションフィクセイションの流れをあらわしたものです。
利用者がログインして得たセッションIDを盗聴などにより取得します。攻撃者は取得したセッションIDを 用いてWebサイトにアクセスすることで利用者になりすます事が可能になります。
以下に、セッションハイジャック対策の例を説明します。
攻撃者がターゲットWebサイトから有効セッションIDを取得し、何らかの方法で利用者に利用させることで セッションIDと利用者のログイン情報を結びつけさせます。攻撃者はそのセッションID を用いてターゲットWebサイトにアクセスすることで利用者になりすます事が可能になります。
以下に、セッションフィクセイション対策の例を説明します。
WebOTXではセッションIDのCookieを盗聴から守るために暗号化(https)通信でのみ送信されるように セッションIDのCookieにセキュアオプションを設定できる機能を提供しています。
nec-web.xml配備記述子にcookieSecureプロパティを設定します。nec-web.xml配備記述子は予めアプリケーションのWEB-INFディレクトリに配置した上で配備します。
[nec-web.xml配備記述子の設定例]
<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
<context-root>example</context-root>
<session-config>
<cookie-properties>
<property name="cookieSecure" value="true"/>
</cookie-properties>
</session-config>
</nec-web-app>
Servlet3.0よりweb.xml配備記述子に<secure>要素を定義することで、セキュアオプションを設定することができます。web.xml配備記述子は予めアプリケーションのWEB-INFディレクトリに配置した上で配備します。Servlet2.4以前の場合はnec-web.xmlのcookieSecureプロパティで設定してください。
[web.xml配備記述子の設定例]
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app version="3.0">
:
<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>
:
</web-app>
WebOTXではFORM認証でログインが成功した際にセッションを再作成して、ログイン前のセッションを使い続けることを防ぐ機能を提供しています。 全てのWebアプリケーション、もしくはWebアプリケーション毎にFORM認証時のセッション再作成を設定します。
otxadmin> set server.web-container.property.auth_form_changeSessionIdOnAuthentication=true
<?xml version="1.0" encoding="UTF-8"?>
<nec-web-app>
:
<property name="auth_form_changeSessionIdOnAuthentication" value="true"/>
:
</nec-web-app>
Webサイトで非公開とすべき情報を取り扱う場合や、利用者本人にのみデータの変更や編集を許可することを 想定する場合には、アクセス制御が必要です。 しかし、個人情報を閲覧する機能にアクセスするにあたり、他人に知られうる情報の入力だけで個人情報を 閲覧できてしまうのは、アクセス制御機能が欠如していると言えます。
また、複数の利用者の存在を想定する場合には、アクセス制御に加えて、 どの利用者にどの操作を許可するかを制御する認可処理が必要となる場合があります。
以下で、アクセス制御欠如と認可処理欠如それぞれに対する対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
クロスサイトスクリプティングは、ユーザの入力データを処理するWebアプリケーションや、Webページを操作する
JavaScriptに存在する脆弱性を悪用し、ユーザのPC上で不正なスクリプトを実行させる攻撃です。
Webアプリケーションが、ユーザからのリクエストに含まれるスクリプトに相当する文字列を、
当該リクエストへのレスポンスであるWebページ内に実行可能なスクリプトとして出力してしまい、
これによりWebサイトを閲覧したユーザ環境で、出力されたスクリプトが実行されてしまいます。
以下の図は、クロスサイトスクリプティングの脆弱性の有無による動作の違いを説明するものです。
このWebサイトでは、入力したデータがWebアプリケーションによって処理され、そのまま確認画面として表示されます。
脆弱性がないサイトでは、入力したスクリプトが単なる文字列として処理され、そのまま確認画面に表示されます。
その一方で、脆弱性があるサイトでは、入力したスクリプトが実行され、アラートがポップアップ表示されてしまいます。
脆弱性のあるサイトでは入力データのチェックが適切に行われていないため、このようにスクリプトを入力すれば、
クライアント環境で様々な処理が実行できることになります。
このことを応用すれば、以下の図のようにして、悪意のあるWebサイトのリンクをクリックさせ、 最終的にクライアント環境で不正なスクリプトを実行させることで、ターゲットWebサイトでのユーザの ログイン情報などを盗むことが可能になります。
以下で、Webアプリケーションでの対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
クロスサイトリクエストフォージェリとは、Webアプリケーションのユーザ認証やセッション管理の不備を突いて、
Webアプリケーションに対する不正な処理要求をサイトの利用者に行わせる手法です。
以下の図のように、ユーザがクロスサイトリクエストフォージェリの脆弱性があるWebサイトにログインした状態で、
悪意のあるWebサイトに仕掛けられたリンクをクリックすることで、ユーザが知らないうちに、Webブラウザが保持している
情報が付与されたリクエスト(以下の図では注文確定情報)が自動送信されてしまいます。
罠にかかったユーザがログインしたセッションで攻撃が行われるので、ユーザの権限で可能な範囲の操作が攻撃者に実行させられてしまいます。
以下で、Webアプリケーションでの対策の例を説明します。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
クリックジャッキングは、複数のWebページを重ね合わせてレイヤとして表示する機能と、重ね合わせたレイヤを
透明にできるというWebブラウザの機能を利用したものです。
フレーム機能を用いて、透過指定した標的サイトを
攻撃用のWebサイト(攻撃者サイト)の上に重ね合わせます。ユーザは攻撃者サイトに対して操作を行っているつもりが、
その操作は実際には標的サイトに対して行われており、ユーザが意図しない設定変更などが実行されます。
クリックジャッキングは,Webページの重ね合わせや透明化といった正当な機能を利用したものであるため、
現時点では根本的な対策はないといえます。
対処療法的な対策として、重ね合わせたWebサイトの透明化の禁止や、重ね合わせたWebサイト上でのクリックの無効化が考えられますが、
Webサイトの使用性を低下させてしまいます。
また、新たな対策として、標的となりうるWebサイトに「外部サイトのフレームからの表示を拒否する」という意味のHTTPレスポンスヘッダ
X-FRAME-OPTIONSを指定するという方法があります。ただし、古いバーションのブラウザはX-FRAME-OPTIONに対応していないことが
あるので、注意が必要です。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
メールヘッダインジェクションとは、ユーザがフォームに入力したデータをもとにメールを送信するWebアプリケーションにおいて、
不正なメールヘッダを混入させることにより、意図しないアドレスに迷惑メールを送信するなど、メール送信機能を悪用した攻撃手法です。
例えば、次のような仕様のメール送信アプリケーションを想定します。
Toアドレス： to@aa.bb (固定) Fromアドレス： フォームから入力
ここで、Fromアドレスに入力する文字列によっては、次のようなメールヘッダが作成され、 意図しないアドレス(user@xx.yy)にまでメールが送信されてしまう可能性があります。
To： to@aa.bb From： from@ss.tt Bcc： user@xx.yy
メールヘッダインジェクションへの対策としては、次のようなものがあります。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
HTTPヘッダインジェクションとは、HTTPを使って通信するシステムにおいて、動的にHTTPヘッダを生成する機能の不備を突いてヘッダ行を挿入することで不正な動作を行なわせる攻撃手法のことです。
例えば、リクエストパラメータに次の画面へのURLが含まれるような場合(http://{host}/{AP}/{Servlet}?url={url})、悪意のある者がURL部分を改ざんしてリクエストパラメータに「url={url}改行コード{別のヘッダ}」のようにコードを仕込まれたとします。HTTPヘッダにおいて改行コードはヘッダの区切りとなります。このため、この場合意図しない{別のヘッダ}をHTTPレスポンスヘッダに設定されてしまう可能性があります。もしSet-Cookieヘッダを仕込まれた場合、セッション固定攻撃に利用される可能性があります。
また、HTTPにおいて改行コードが2つ連続した場合、それは空行を意味しHTTPヘッダとHTTPボディの区切りとして機能します。先ほどの例で「url={url}改行コード改行コード{悪意のあるこーど(Scriptなど)}」のようなコードを仕込まれた場合、ブラウザは悪意のあるコードを実行してしまう危険性があります。これは、クロスサイトスクリプティング等の別の脆弱性につながる可能性があります。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。上記のようにリクエストに含まれるヘッダの内容をレスポンスに設定するようなアプリケーションは、アプリケーションの処理において改行コード(CRLF)やHTMLの文法上特殊な意味を持つ文字("<" ">" "&" """ など)を"%0D%0A" "<" ">" "&" """ などの無害な文字にサニタイジングしてください。
ウェブアプリケーションの機能を複数の利用者が同時に利用したときに、予定外の処理結果が生じる場合があります。このような欠陥は一般に「レースコンディション脆弱性」と呼ばれます。レースコンディション脆弱性によってセキュリティ上の防御が緩む瞬間があるアプリケーションがあった場合，この欠陥により、利用者の秘密にすべき情報が第三者に閲覧される被害が生じる可能性があります。この被害は、攻撃者がいなくても偶然に発生する場合もあれば、 攻撃者が大量のアクセスをすることで意図的に引き起こされる場合もあります。
この脆弱性を排除するには、ソースコードレビューによってレースコンディションが起きえない構造にプログラムが記述されていることを確認する方法や、大量のアクセスを同時に発生させて異常が発生しないことを十分に確認するテストを行うなどの対策方法が考えられます。
WebOTXでは、本脆弱性への対策についての機能を特に提供していません。アプリケーションでの対策を実施してください。
アプリケーションからWebOTX外部のサービス(Webサービス、メールサービス、ネーミングサービス等)を利用する場合は、SSLを利用したセキュアなプロトコル(HTTPS, POP3s, IMAP4s, SMTPs, LDAPS等)を用いてサービスにアクセスする事で通信内容の機密性と完全性が保障されます。
アプリケーションからSSLを利用する場合には、利用するサービスのサーバが利用するサーバ証明書またはそのルート証明書をドメインのトラストストアにインポートする必要があります。
利用するサービスにアクセスするための証明書を取得してインポートします。
多くのルート証明書はJDKのトラストストアファイルに含まれているため、基本的にはそれを利用します。
もし、ルート証明書がJDKに含まれていないような場合は、CA(認証局)のサイトからダウンロードしてドメインのトラストストアにインポートするか、サーバ証明書をインポートする方法もあります。
> ${JAVA_HOME}/bin/keytool -importkeystore -srckeystore "${JAVA_HOME}/jre/lib/security/cacerts" -destkeystore "${INSTANCE_ROOT}/config/cacerts.jks" -srcstorepass changeit -deststorepass changeit
-----BEGIN CERTIFICATE-----
MIID9jCCAt6gAwIBAgIQZIKe/DcedF38l/+XyLH/QTANBgkqhkiG9w0BAQsFADCB
lDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8w
〜
KIYkM2oBLldzJbZev4/mHWGoQClnHYebHX+bn5nNMdZUvmK7OaxoEkiRIKXLsd3+
b/xa5IJVWa8xqQ==
-----END CERTIFICATE-----
> ${JAVA_HOME}/bin/keytool -importcert -alias ${任意の名称} -trustcacerts -storepass changeit -file ${ルート証明書のファイル名} -keystore "${INSTANCE_ROOT}/config/cacerts.jks"
> ${JAVA_HOME}/bin/keytool -importcert -alias ${任意の名称} -trustcacerts -storepass changeit -file ${サーバ証明書のファイル名} -keystore "${INSTANCE_ROOT}/config/cacerts.jks"