通信の安全性

1.SSL通信による通信データの暗号化

インターネットを使ったサービスの中には、通信途中で第三者に盗み見られたり改ざんされる可能性があるものがあります。ABCD PartnersのWebサービスは、通信のすべてをSSLを用いてデータを暗号化してあるので、第三者が内容を確認することができません。

サーバー環境

1.高度なセキュリティと信頼性を持つデータセンター

ABCD PartnersのWebサービスは、Amazon Web Services(以降、AWS)のデータセンターを利用しています。 AWSはAmazon社が提供するデータセンターサービスで、同社が長年の大規模データセンターを運用した経験をもとに設計・構築・運用されています。 非常に高い信頼性を持つ認証と認定を受けており、多数の豊富な実績があります。

2.高度なセキュリティと信頼性を持つデータセンター

AWSのサーバーは独立した電源、空調、ネットワーク環境を持つ、異なるデータセンターにまたがって配備されています。 例え特定のデータセンターでハードウェアの物理的な障害やネットワーク障害が発生したとしても、待機している他のデータセンターのサーバーへと自動で切り替わり、運用を継続することができます。

3.安心のバックアップ体制

データベースのデータは常にバックアップされており、万が一、弊社がデータを消失させる事故を発生させたとしても、過去の状態にもデータを復元することができる体制をとっております。さらに、通常の運用サーバーとは全く異なる系統の専用サーバーへと、バックアップデータを保管しています。バックアップデータの保管にはAmazon S3を使用しており、複数の施設にまたがって多重に格納されることで、付与された1年に対して99.999999999%という極めて高い耐久性を持つよう設計されています。
その他Amazon Web Servicesのセキュリティ詳細についてはAWSセキュリティセンターをご覧ください。

ウェブアプリケーションのセキュリティ実装 チェックリスト

1.SQLインジェクション
  • [根本的解決]

✓ 対応済  SQL文の組み立ては全てプレースホルダで実装する。
✓ 対応済  SQL文の構成を文字列連結により行う場合は、アプリケーションの変数をSQL文のリテラルとして正しく構成する。
✓ 対応済  ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない。

  • [保険的解決]

✓ 対応済  エラーメッセージをそのままブラウザに表示しない。
✓ 対応不要 データベースアカウントに適切な権限を与える。

2.OSコマンド・インジェクション
  • [根本的解決]

✓ 対応済  シェルを起動できる言語機能の利用を避ける。

  • [保険的解決]

✓ 対応済  シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

3.パス名パラメータの未チェック/ディレクトリ・トラバーサル
  • [根本的解決]

✓ 対応済  外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
✓ 対応済  ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。

  • [保険的解決]

✓ 未対応  ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する。
✓ 未対応  ファイル名のチェックを行う。

4.セッション管理の不備
  • [根本的解決]

✓ 対応済  セッションIDを推測が困難なものにする。
✓ 対応済  セッションIDをURLパラメータに格納しない。
✓ 対応済  HTTPS通信で利用するCookieにはsecure属性を加える。
✓ 対応済  ログイン成功後に、新しくセッションを開始する。
✓ 対応済  ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認する。

  • [保険的解決]

✓ 未対応  セッションIDを固定値にしない。
✓ 未対応  セッションIDをCookieにセットする場合、有効期限の設定に注意する。

5.クロスサイト・スクリプティング
HTMLテキストの入力を許可しない場合の対策
  • [根本的解決]

✓ 対応済  セッションIDを推測が困難なものにする。
✓ 対応済  ウェブページに出力する全ての要素に対して、エスケープ処理を施す。
✓ 対応済  URLを出力するときは、「http://」や 「https://」で始まるURLのみを許可する。
✓ 対応済   要素の内容を動的に生成しない。
✓ 対応済  スタイルシートを任意のサイトから取り込めるようにしない。

  • [保険的解決]

✓ 対応済  入力値の内容チェックを行う。

HTMLテキストの入力を許可する場合の対策
  • [根本的解決]

✓ 対応済  入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する。

  • [保険的解決]

✓ 対応済  入力されたHTMLテキストから、スクリプトに該当する文字列を排除する。

全てのウェブアプリケーションに共通の対策
  • [根本的解決]

✓ 対応済  HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行う。

  • [保険的解決]

✓ 未対応  Cookie情報の漏えい対策として、発行するCookieにHttpOnly属性を加え、TRACEメソッドを無効化する。

6.CSRF (クロスサイト・リクエスト・フォージェリ)
  • [根本的解決]

✓ 未対応  処理を実行するページを POST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
✓ 未対応  処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
✓ 対応済  Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する。

  • [保険的解決]

✓ 未対応  重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。

7.HTTPヘッダ・インジェクション
  • [根本的解決]

✓ 対応不要 ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する。
✓ 対応不要 改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。

  • [保険的解決]

✓ 対応不要 外部からの入力の全てについて、改行コードを削除する。

8.メールヘッダ・インジェクション
  • [根本的解決]

✓ 対応済  メールヘッダを固定値にして、外部からの入力はすべてメール本文に出力する。
✓ 対応済  ウェブアプリケーションの実行環境や言語に用意されているメール送信用APIを使用する。
✓ 対応済  HTMLで宛先を指定しない。

  • [保険的解決]

✓ 未対応  外部からの入力の全てについて、改行コードを削除する。

9.アクセス制御や認可制御の欠落
  • [根本的解決]

✓ 対応済  アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の秘密情報の入力を必要とする認証機能を設ける。

  • [保険的解決]

✓ 対応済  認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。