SE学習帳...φ(。_。；)：SSブログ

	ブログをはじめるログイン

2013年12月16日｜ 2013年12月18日｜2013年12月20日ブログトップ

セッション管理の脆弱性と対策　 [情報セキュリティ]

セッション管理の脆弱性

HTTPでは、URL指定によるWebページの閲覧や、リンクをクリックすることによる別ページへの遷移、ログイン処理の実行などの各リクエストが単発で完結するため、その連続性や状態を管理することができません。そのため、Webアプリケーション側で各セッションを管理するための識別情報(セッションIDなど)を生成し、クライアントとやり取りする必要があります。

パケット盗聴によってセッション管理情報が盗まれる可能性がある(HTTPの場合)
クエリストリング、hiddenフィールド、クッキーのいずれの手段を用いていたとしても、HTTPで通信していれば盗聴される可能性がある
セッションIDが推測・改ざんされ、他者に情報などが漏洩する可能性がある
セッションIDに単純な文字列を使用していると、たとえHTTPSを使用している場合でも、セッションIDが推測・改ざんされてしまう可能性がある
詳細なセッション管理情報をWebサーバとクライアント間でやり取りしていることにより、他者に情報などが漏洩する可能性がある
GETメソッドでクエリストリングを使用して詳細なセッション管理情報をやり取りしている場合には、特に危険である
Referrerのログが他のWebサイト管理者にセッション管理情報が漏洩する可能性がある
GETメソッドでクエリストリングを使用して詳細なセッション管理情報をやり取りしている場合には、特に危険である
hiddenフィールドの改ざんにより、不正な処理を実行される可能性がある
hiddenフィールドには計算に用いる定数などがセットされている場合があり、HTMLを保存することにより内容を改ざんすることは容易である。そのため、hiddenフィールドの値が改ざんされ、不正な処理が実行されてしまう可能性がある
XSSの脆弱性により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある
クッキーの属性設定の問題により、クッキーにセットされたセッション情報が盗まれ、悪用される可能性がある
- セキュア属性が設定されていないとHTTP通信でもクッキーが送出され、盗聴される危険性が高まる
- 有効期限が必要以上に長く設定されていると、クライアント側の問題によりクッキーが悪用される危険性が高まる
- 有効範囲の設定が適切でないと、関係のないサーバやディレクトリにアクセスする際にもクッキーが送出され、悪用される危険性が高まる
WebサーバでURL Rewriting機能が有効になっていると、意図的なセッション管理情報をクエリストリングにセットして使用することができる可能性がある
- クッキーにセットされたセッション管理情報をクエリストリングとして送ることができる可能性がある
- この脆弱性により、セッションフィクセイションが行われる可能性がある
セッション管理のバグにより、本来は認証を必要とするWebページに認証プロセスを経ることなくアクセスされる
セッション管理にバグがあると、URLの直接指定や、検索エンジンからの参照によって、本来は認証を必要とするページに直接アクセスされてしまう可能性がある

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

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