ウェブアプリケーションとセキュリティ実装

[安全なウェブサイトの作り方](https://www.ipa.go.jp/files/000017316.pdf)の自分用のまとめです。

# ウェブアプリケーションとセキュリティ実装
## SQLインジェクション
データベースと連携したウェブアプリケーションの多くは、利用者からの入力情報を基に SQL 文（データベースへの命令文）を組み立てている。ここで、SQL 文の組み立て方法に問題がある場合、攻撃によってデータベースの不正利用をまねく可能性がある。


### 発生しうる脅威
- データベースに蓄積された非公開情報の閲覧
  - 個人情報の漏えい 等
- データベースに蓄積された情報の改ざん、消去
  - ウェブページの改ざん、パスワード変更、システム停止 等
- 認証回避による不正ログイン
  - ログインした利用者に許可されている全ての操作を不正に行われる
- ストアドプロシージャ等を利用した OS コマンドの実行
  - システムの乗っ取り、他への攻撃の踏み台としての悪用 等

### 根本的解決
- SQL 文の組み立ては全てプレースホルダで実装する。
- SQL 文の組み立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンの API を用いて、SQL 文のリテラルを正しく構成する。
- ウェブアプリケーションに渡されるパラメータに SQL 文を直接指定しない。

### 保険的解決
- エラーメッセージをそのままブラウザに表示しない。
- データベースアカウントに適切な権限を与える。


## OS コマンド・インジェクション
ウェブアプリケーションによっては、外部からの攻撃により、ウェブサーバの OS コマンドを不正に実行されてしまう問題を持つものがある。このような問題を「OS コマンド・インジェクションの脆弱性」と呼び、問題を悪用した攻撃手法を、「OS コマンド・インジェクション攻撃」と呼ぶ。

### 発生しうる脅威
- サーバ内ファイルの閲覧、改ざん、削除
  - 重要情報の漏えい、設定ファイルの改ざん 等
- 不正なシステム操作
  - 意図しない OS のシャットダウン、ユーザアカウントの追加、変更 等
- 不正なプログラムのダウンロード、実行
  - ウイルス、ワーム、ボット等への感染、バックドアの設置 等
- 他のシステムへの攻撃の踏み台
  - サービス不能攻撃、システム攻略のための調査、迷惑メールの送信 等

### 根本的解決
- シェルを起動できる言語機能の利用を避ける。

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


## パス名パラメータの未チェック／ディレクトリ・トラバーサル
ウェブアプリケーションの中には、外部からのパラメータにウェブサーバ内のファイル名を直接指定し
ているものがある。このようなウェブアプリケーションでは、ファイル名指定の実装に問題がある場合、
攻撃者に任意のファイルを指定され、ウェブアプリケーションが意図しない処理を行ってしまう可能性が
ある。

### 発生しうる脅威
- サーバ内ファイルの閲覧、改ざん、削除
  - 重要情報の漏えい
  - 設定ファイル、データファイル、プログラムのソースコード等の改ざん、削除

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

### 保険的解決
- ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する。
- ファイル名のチェックを行う。


## セッション管理の不備
ウェブアプリケーションの中には、セッション ID（利用者を識別するための情報）を発行し、セッション管理を行っているものがある。このセッション ID の発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッション ID を不正に取得され、その利用者になりすましてアクセスされてしまう可能性がある。

### 発生しうる脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
  - 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理 等
- ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
  - 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み 等
- ログイン後の利用者のみが閲覧可能な情報の閲覧
  - 非公開の個人情報を不正閲覧、ウェブメールを不正閲覧、コミュニティ会員専用の掲示板を不正閲覧 等

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

### 保険的解決
- セッション ID を固定値にしない。
- セッション ID を Cookie にセットする場合、有効期限の設定に注意する。

## クロスサイト・スクリプティング
ウェブアプリケーションの中には、検索のキーワードの表示画面や個人情報登録時の確認画面、掲示板、ウェブのログ統計画面等、利用者からの入力内容や HTTP ヘッダの情報を処理し、ウェブページとして出力するものがある。ここで、ウェブページへの出力処理に問題がある場合、そのウェブページにスクリプト等を埋め込まれてしまう。

### 発生しうる脅威
- 本物サイト上に偽のページが表示される
  - 偽情報の流布による混乱
  - フィッシング詐欺による重要情報の漏えい 等
- ブラウザが保存している Cookie を取得される
  - Cookie にセッション ID が格納されている場合、さらに利用者へのなりすましにつながる
  - Cookie に個人情報等が格納されている場合、その情報が漏えいする
- 任意の Cookie をブラウザに保存させられる
  - セッション ID が利用者に送り込まれ、「セッション ID の固定化」 攻撃に悪用される


### 根本的解決
1. HTML テキストの入力を許可しない場合の対策
  - ウェブページに出力する全ての要素に対して、エスケープ処理を施す。
  - URL を出力するときは、「http://」や 「https://」で始まる URL のみを許可する。
  - <script>...</script> 要素の内容を動的に生成しない。
  - スタイルシートを任意のサイトから取り込めるようにしない。
1. HTML テキストの入力を許可する場合の対策
  - 入力された HTML テキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する。
1. 全てのウェブアプリケーションに共通の対策
  - HTTP レスポンスヘッダの Content-Type フィールドに文字コード（charset）を指定する。

### 保険的解決
1. HTML テキストの入力を許可しない場合の対策
  - 入力値の内容チェックを行う。
1. HTML テキストの入力を許可する場合の対策
  - 入力された HTML テキストから、スクリプトに該当する文字列を排除する。
1. 全てのウェブアプリケーションに共通の対策
  - Cookie 情報の漏えい対策として、発行する Cookie に HttpOnly 属性を加え、TRACE メソッドを無効化する。
  - クロスサイト・スクリプティングの潜在的な脆弱性対策として有効なブラウザの機能を有効にするレスポンスヘッダを返す。

## CSRF（クロスサイト・リクエスト・フォージェリ）
ウェブサイトの中には、サービスの提供に際しログイン機能を設けているものがある。ここで、ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう場合がある。このようなウェブサイトにログインした利用者は、悪意のある人が用意した罠により、利用者が予期しない処理を実行させられてしまう可能性がある。

### 発生しうる脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
  - 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理 等
- ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
  - 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み 等

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

### 保険的解決
- 重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。

## HTTP ヘッダ・インジェクション
ウェブアプリケーションの中には、リクエストに対して出力する HTTP レスポンスヘッダのフィールド値を、外部から渡されるパラメータの値等を利用して動的に生成するものがある。たとえば、HTTP リダイレクションの実装として、パラメータから取得したジャンプ先の URL 情報を、Location ヘッダのフィールド値に使用する場合や、掲示板等において入力された名前等を Set-Cookie ヘッダのフィールド値に使用する場合等が挙げられます。このようなウェブアプリケーションで、HTTP レスポンスヘッダの出力処理に問題がある場合、攻撃者は、レスポンス内容に任意のヘッダフィールドを追加したり、任意のボディを作成したり、複数のレスポンスを作り出すような攻撃を仕掛ける場合がある。

### 発生しうる脅威
- クロスサイト・スクリプティング攻撃により発生しうる脅威と同じ脅威
- 任意の Cookie 発行
  - Set-Cookie ヘッダを注入された場合、任意の Cookie が発行され、利用者のブラウザに保存される可能性がある。
- キャッシュサーバのキャッシュ汚染
複数のレスポンスに分割し、任意のレスポンスボディをリバースプロキシ等にキャッシュさせることにより、キャッシュ汚染30（ウェブページの差し替え）を引き起こし、ウェブページの改ざんと同じ脅威が生じる。この攻撃を受けたウェブサイトにアクセスする利用者は、この差し替えられた偽のウェブページを参照し続けることになる。

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

### 保険的解決
- 外部からの入力の全てについて、改行コードを削除する。


## メールヘッダ・インジェクション
ウェブアプリケーションの中には、利用者が入力した商品申し込みやアンケート等の内容を、特定のメールアドレスに送信する機能を持つものがある。一般に、このメールアドレスは固定で、ウェブアプリケーションの管理者以外の人は変更できないが、実装によっては、外部の利用者がこのメールアドレスを自由に指定できてしまう場合がある。

### 発生しうる脅威
- メールの第三者中継
  - 迷惑メールの送信に悪用される


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

### 保険的解決
- 外部からの入力の全てについて、改行コードを削除する。

## クリックジャッキング
ウェブサイトの中には、ログイン機能を設け、ログインしている利用者のみが使用可能な機能を提供しているものがある。該当する機能がマウス操作のみで使用可能な場合、細工された外部サイトを閲覧し操作することにより、利用者が誤操作し、意図しない機能を実行させられる可能性がある。

### 発生しうる脅威
- ログイン後の利用者のみが利用可能なサービスの悪用
  - 利用者が意図しない情報発信、利用者が意図しない退会処理 等
- ログイン後の利用者のみが編集可能な設定の変更
  - 利用者情報の公開範囲の意図しない変更 等

### 根本的解決
- HTTP レスポンスヘッダに、X-Frame-Options ヘッダフィールドを出力し、他ドメインのサイトからの frame 要素や iframe 要素による読み込みを制限する。
- 処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。

### 保険的解決
- 重要な処理は、一連の操作をマウスのみで実行できないようにする。

## バッファオーバーフロー
ウェブアプリケーションを含む、あらゆるプログラムは、指示された処理を行うためにメモリ上に自身が使用する領域を確保します。プログラムが入力されたデータを適切に扱わない場合、プログラムが確保したメモリの領域を超えて領域外のメモリを上書きされ、意図しないコードを実行してしまう可能性がある。

### 発生しうる脅威
- プログラムの異常終了
  - 意図しないサービス停止
- 任意のコード実行
  - ウイルス、ワーム、ボット等への感染、バックドアの設置、他のシステムへの攻撃、重要情報の漏えい 等

### 根本的解決
- 直接メモリにアクセスできない言語で記述する。
- 直接メモリにアクセスできる言語で記述する部分を最小限にする。
- 脆弱性が修正されたバージョンのライブラリを使用する。

## アクセス制御や認可制御の欠落
ウェブサイトの中には、運営者のセキュリティに対する認識のなさから、不適切な設計で作成されたウェブサイトが運用されていることがある。脆弱性関連情報として届出を受けた「アクセス制御」や「認可制御」等の機能欠落に伴う脆弱性についての対策を以下に記す。

### 根本的解決
#### アクセス制御の欠落
- アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワード等の
秘密情報の入力を必要とする認証機能を設ける。

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