aaaiiuie

学習(備忘録)のため運用

情報処理安全確保支援士 3.6 HTTP及びWebアプリケーションの脆弱性と対策

情報処理安全確保支援士

多くの組織がWebサイトを持つようになり、Webページ上でユーザーからの入力データを受け付けるためのWebアプリケーションが広く利用されている。ここではHTTPとウェブアプリケーションの脆弱性と対策について解説する。

3.6.1 HTTPとウェブアプリケーションの仕組み

HTTPはWebページにアクセスするためのプロトコルとしてSMTPとともにもっとも広く利用されている。 現在インターネットを使用している組織の中でウェブサイトを持たないところは皆無に等しいはずである。多くの組織が独自のWebページを開発し、広く一般に公開している。また、そうしたWebページの中には単なる情報発信に止まらず、ウェブアプリケーションによって利用者の入力データを受け付けて処理したり、商品やサービス販売したりしているケースも珍しくはない。 第二章で開設したように、近年ウェブアプリケーションの脆弱性をついた攻撃が増加し続けており、ウェブサーバの背後にあるデータベースから個人情報が盗まれる事件などもの発生している。そうした事件の原因となっているのがHTTPプロトコル自体の脆弱性とウェブアプリケーションの脆弱性である。中でも、セッション管理の脆弱性はHTTPの仕様、ウェブサーバ実装及び設定、ウェブアプリケーションの仕組み及び実装に関係しており、複雑である。そのため、ここでは次に示すように、はじめにセッション管理の脆弱性について取り上げ、続いてそれ以外の脆弱性について取り上げる。

  1. セッション管理の脆弱性薬性
  2. HTTP（プロトコル）の仕様による脆弱性
  3. Webサーバの実装や設定不備による脆弱性
  4. ウェブアプリケーションの仕様による脆弱性

これらの中で、３のウェブサーバ（OS・ミドルウェア）の実装面の脆弱性については、ソフトウェアの脆弱性情報を随時確認し、便だから提供される修正プログラム（バッチ）を適用することで対処する。 また、設定不備については脆弱性検査で発見し、対処する必要がある。

一方、１、４についてはウェブアプリケーション固有の脆弱性であり、存在に気づかなければいつまで経っても改修されることはない。その結果、重大な脆弱性を内在したまま、サイトが公開され、サイバー攻撃によって大きな被害を受ける可能性がある。対処方法としては、新規開発したウェブアプリケーションを本番運用する前に脆弱性検査を実施し、見つかった脆弱性を確実に改修することである。

Webサイトの脆弱性と対処方法

3.6.2 セッション管理の脆弱性と対策

セッション管理の脆弱性

1.4.7で述べたように、HTTPではURL指定によるWebページの閲覧や、リンクをクリックすることによる別ページへの遷移、ログイン処理の実行などの各リクエストが単発で完結するため、その連続性や状態を管理することができない。そのため、ウェブアプリケーション側で各セッションを管理するための識別情報（セッションID）を生成し、クライアントとやりとりする必要がある。 セッション管理の脆弱性には次のようなものがある。

１ パケット盗聴によってセッション管理情報が盗まれる可能性がある。

クエリストリング、hiddenフィールド、クッキーのいずれの手段を用いても、HTTPで通信していれば盗聴される可能性がある。

２ セッションIDが推測、改竄され、他者に情報などが漏洩する可能性がある。

セッションIDに単純な文字列を仕様していると、例えHTTPSを仕様している場合であっても、セッションIDが推測され・改竄されてしまう可能性がある。

３　詳細なセッション管理情報をウェブサーバとクライアント間でやりとりしていることにより、他社に情報などが漏洩する可能性がある。

GETメソッドでクエリストリングを使用している詳細なセッション管理情報をやりとりしているような場合には特に危険である。

４　Refererのログから他のウェブサイト管理者にセッション管理情報をが漏洩する可能性がある

３と同様に、GETメソッドでクエリストリングを使用して詳細なセッション管理情報をやりおtりしているような場合には、特に危険である。

５　hiddenフィールドの改竄により、不正な処理を実行されてしまう可能性がある

hiddenフィールドには計算に用いられる定数などがセットされている場合があるが、HTMLを保存することによって、内容を改竄することは容易である。そのためhiddenフィールドのあたいが改竄され、不正な処理が実行されてしまう可能性がある。

６　XSSの脆弱性により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある

7　クッキーの属性設定の問題により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある。

  • secure属性が設定されていないと、HTTP通信でもクッキーが送出され、盗聴される危険性が高まる。
  • 有効期限が必要以上に長く設定されていると、クライアント側の問題によってクッキーが悪用される危険性が高まる。
  • 有効期限の設定が適切でないと、関係のないサーバやディレクトリにアクセスする際にもクッキーが創出され、悪用される危険性がある。

8 ウェブサーバで[URL Rewriting 機能]が有効になっていると、意図的なセッション管理情報をクエリストリングにセットして使用することができる可能性がある

  • クッキーにセットされたセッション管理情報をクエリストリングとして送ることができる可能性がある
  • この脆弱性により、セッションフィクセーションが行われる可能性がある。

9 セッションかりのバグにより、本来認証を必要とするWebページに認証プロセスを減ることなくアクセスされる

セッション管理にバグがあると、URLの直接指定や、検索エンジンからの査証によって本来は認証を必要とするページに直接アクセスされてしまう可能性がある。

セッション管理の脆弱性への対策

  • 重要な情報を取り扱うWebページではHTTPS(TLS)によって通信する
  • 重要なセッション管理情報は全てウェブサーバ側で管理し、クエリストリング、クッキー、hiddenフィールドにはセッションの識別情報（ID）しか含めないようにする
  • セッションIDには十分な長さをおった乱数やハッシュ値を用いる（GETメソッドを使用している場合は特に重要）
  • 重要な情報を取り扱うWebページではPOSTメソッドを持ちちてセッション管理情報を隠蔽し、GETメソッドではデータを渡せないようにする。ただし、POSTメソッドではウェブサーバのアクセスログに入力データが記録されないため、SQLインジェクションXSSなどによる侵害が発生した際には原因究明や追跡が困難になる可能性がある。そのため、POSTメソッドを使用すrばあいにはウェブアプリケーション側で受け取ったデータの内容をロギングするようにするのが望ましい
  • クッキーの有効期限は可能な限り短く、有効範囲は可能な限り狭く設定する
  • HTTPSでアクセスするウェブページでは、必ずクッキーを「secure属性あり」に設定する
  • HTTPでアクセスするWebページとHTTPSでアクセスするWebページをまたがってセッション管理を行う必要がある場合は、二つのクッキーを発行し、一方を「secure属性なし」にしてHTTPのページで使用する。もう一方を「secure属性あり」にしてHTTPSのページで使用するようにする。
  • 入力データに含まれるメタキャラクタのエスケープ処理確実に行い、XSSの脆弱性を残さない
  • ウェブサーバの「URL Rewriteing機能」を無効に設定する
  • 認証を必要とするページが直接アクセスされることがないようにセッション管理を確実に行うとともに、そのようなページが検索エンジンやキャッシュに登録されないように設定する（ <meta> タグを用いて設定する）
  • セッション管理を自社で開発せず、アプリケーションサーバなどに実装されている機能を使用する（それらの機能にも脆弱性があるため、十分な評価・検証が必要）
  • ログイン後に新たなセッションIDを発行するようにする
  • ウェブアプリケーションファイアウォール（WAF）を用いてセッション管理の税薬性ついた攻撃を遮断する
    ⇨実際にはWAFでロジック系の攻撃を防ぐのは困難
CSRFのイメージ
CSRFの対策

3.6.3 HTTP（プロトコル）の仕様による脆弱性と対策

HTTPの仕様による脆弱性

セッションに関する脆弱性以外のHTTPの仕様上の脆弱性を次に示す。

1 HTTPでは通信データが平文でネットワーク中を流れるため、パケット盗聴によって重要な情報が盗まれたり、改竄されたりする可能性がある。

2 Basic認証の脆弱性により、パケット盗聴によって認証情報が盗まれる危険性が高い

  • HTTPの基本機能であるBasic認証では、入力された認証情報がBASE64エンコードされネットワーク中を流れる
  • BASE64はバイナリデータをテキストデータに変換する方式であり、エンコードされたデータを復元することが容易である
  • ベーシックに賞ではHTTPリクエストのたびに認証情報が送出される
  • 上記の理由からHTTPでBasic認証を行なっている場合にはパケット盗聴によって認証情報を盗むことは容易である。

3 Basic認証ではウェブサーバで認証情報を管理する必要があるため、漏洩などの危険性が高まる

  • 認証情報の一元管理ができず、管理が煩雑になる
  • 上記により漏洩の危険性も高まる

HTTPの仕様による脆弱性への対策

  • 重要な情報を取り扱うWebページではHTTPSによって通信する
  • HTTPのBasic認証は曲ryくしようせず、認証用の入力フォームを用いる（フォーム認証）かチャレンジレスポンス方式とMD5の採用によって認証情報が秘匿化されるHTTPダイジェスト認証を用いる
  • 認証を行う画面では必ずHTTPSを使用する
  • ベーシック認証では認証後もHTTPリクエストのたびに認証情報が送出されるため、全てHTTPSを使用する必要がある
  • フォーム認証では認証情報はウェブサーバで管理せず、データベースなどを用いて管理する

3.6.4 Webサーバの実装や設定の不備による脆弱性と対策

Webサーバの実装や設定の不備による脆弱性

セッションに関する脆弱性以外でWebサーバの実装や設定不備による脆弱性を次に示す。

1 ディレクトリに関する雨設定不備によりディレクトリトラバーサル攻撃（2.8.7項記載）を受けたり、ディレクトリ山椒によって機密情報にアクセスされたりするか脳死絵がある

次のような脆弱性により、URLの直接指定や、検索エンジンからの参照によって機密情報にアクセスされたりする可能性がある。

  • ディレクトリのアクセス圏の設定不備
  • ディレクトリ参照が許可されている
  • デフォルトページなどが置かれていない

2 エラーメッセージの出力設定不備により、機密情報が漏洩する可能性がある

Webサーバが詳細なエラーメッセージをクライアントに返す設定になっていると機密情報の漏洩につながる可能性がある。

HTTP のヘッダー情報からWebサーバプログラムの種類やバージョンが知られてしまう可能性がある

デフォルト設定ではWebサーバプログラムの名前やバージョン情報などをHTTPヘッダにセットして送出するようになっているため、ポートスキャンなどによって、それらの情報が知られてしまうことになる。

4 Webサーバプログラムの種類、バージョンによってBOF攻撃をウケる脆弱性がある

一般的に利用されているWebサーバプログラムにはBOF攻撃を受ける脆弱性のほか、数多くの脆弱性が報告されている（特に旧バージョンの製品は危険である）。

5 コマンドやメソッドの設定不備により、コンテンtぬの改竄や管理情報の漏洩などにつながる可能性がある

次のような問題が想定される　

  • PUTメソッド（WebサーバにHTMLなどのコンテンツをアップロードする機能）が使用可能になっていると、不正なコンテンツが書き込まれる可能性がある。
  • TRACEメソッド（クライアントがWebサーバに送信した内容をHTTPヘッダーも含めてそのまま返す機能）が使用可能かつクロスサイトスクリプティングの脆弱性があると、HTTPヘッダーに含まれるクッキーや認証情報が取得さてしまう可能性がある。
  • Webサーバの管理者用に用意されたコマンドが有効になっているか、適切な制限がかけられていないため、Webサーバのアクセスログや利用状況などが不正に閲覧される可能性がある。

Webサーバの実装や設定の不備による脆弱性への対策

  • Webサーバプログラムの馬０ジョンを最新歌詞、バッチを適用する
  • 不要な機能やコマンドを無効にするか、使用可能な範囲を制限する
  • ディレクトリのアクセス権を適切に設定する
  • 全てのディレクトリにデフォルトページを奥
  • ディレクトリ参照を禁止する（デフォルトページを置かない場合）
  • クライアントに詳細なエラーメッセージを送らないように設定する
  • HTTPヘッダにWebサーバプログラムの詳細情報を含めないよう設定する
  • IPSを用いてOSやWebサーバプログラムの脆弱性をついた攻撃を遮断する

3.6.5 Webアプリケーションの仕様や実装による脆弱性と対策

Webアプリケーションの仕様や実装による脆弱性と対策

セッション管理に関する脆弱性以外でWebアプリケーションの仕様や実装による脆弱性を次に示す。

1 XSSの脆弱性により、クライアント環境で悪意のあるスクリプトが実行されてしまう可能性がある

  • クッキーの不正取得に限らず、クライアント環境でのデータの改竄者破壊などが行われる可能性がある。
  • 動的に生成されてクライアント環境に送られるWebコンテンに不正な入力フィールドを挿入させることなどにより、フィッシング詐欺に悪用される可能性がある

2 SQLインジェクションの脆弱性により、データベース上のデータが不正に取得・改竄されたり、データベースが破壊されたりする可能性がある

ユーザーの入力データをもとにSQL文を編集してデータベースにアクセスする仕組みになっているWebページにおいて、入力データチェックが適切に行われていないと、不正なSQL処理が事項される可能性がある。

3 OSコマンドインジェクションの脆弱性により、Webサーバ上で任意のファイルを読出し、変更、削除、パスワードの不正取得などが行われる可能性がある

ユーザーの入力するデータを元に、OSのコマンドを呼び出して処理するWebページにおいて、入力データチェックが適切に行われていないと、不正なコマンドが実行される可能性がある。

4 HTTPヘッダインジェクションの脆弱性により、クライアントに不正なデータが送られる可能性がある

ユーザーの入力データを元にHTTPメッセージのレスポンスを生成するWebページにおいて、改行コードを混入させることで、任意のヘッダーフィールドやメッセージボディを追加したり、複数のレスポンスに分割したりする攻撃が行われる可能性がある。

5 メールヘッダインジェクションの脆弱性により、不正なメールが送信される可能性がある。

ユーザーの入力データをもとにメールを送信するWebページにおいて、改行コードを混入することで、任意のメールヘッダを追加し、意図していないアドレスに迷惑メールなどが送信される可能性がある。

Webアプリケーションの仕様や実装による脆弱性への対策

  • WebアプリケーションからDBサーバへのリクエストの処理にはバインド機構を優先的に用いる（SQLインジェクション対策）
  • ユーザー入力データを処理するWebアプリケーションにおいて、入力データの中にスクリプトやコマンドとして意味を持つ文字が存在した場合には、HTMLを生成する際、もしくはコマンド発行する直前に、それらに対するエスケープ処理を行う
  • DBサーバ（RDBMS）の設定により、WebアプリケーションからDBに対するクエリを必要最小限の権限のみを持つアカウントで処理するようにする（SQLインジェクション対策）
  • Webアプリケーションの中でOSコマンドの呼び出しが可能な関数を極力使用しないようにする（OSコマンドインジェクション対策）。
  • Webアプリケーションファイアウォールを用いてWebアプリケーションの脆弱性をついた攻撃を遮断する。

次のページに主なプロトコルの脆弱性と対策についてまとめた一覧を示す。

主なプロトコルの脆弱性と対策