情報セキュリティ第四弾：セッションハイジャック②

１．会員制サイトへのアクセスの流れ

２．会員制サイトへのなりすましアクセスの流れ

３．セッションID盗聴に至った脆弱性が考えられるポイント

1. http通信を行っている

2. セッションIDの推測・偽装が簡易

3. セッション管理情報が観測可能

4. クロスサイトスクリプティング（XSS）によるcookie情報の悪用

それでは、各脆弱性について詳細を説明します。

３．１．http通信を行っている

まず、http通信とhttps通信の違いはご存じでしょうか？
　http通信：平文でのやりとりを行っている
　https通信：http secureのことで、TLS(Transport Layer Security)というセキュリティプロトコルを使用して通信を行っている

３．２．セッションIDの推測・偽装が簡易

簡易となってしまう原因として下記があげられます。
・ユーザごとにセッションIDが固定
⇒ログインの度に同じものを使いまわすので、一度漏れると何度もセッションハイジャックされる

・ユーザIDの生成に日時、連番、ユーザID等が関連している
⇒下記のように、推測される可能性がある

３．３．セッション管理情報が観測可能

・URLにパラメータが載っていると通信ログのrefererヘッダにて確認されてしまう。
下記は、Google Chromeのブラウザディベロッパーツールで、Refererヘッダを通信ログで確認したものであり、Googleの検索トップページのURLへアクセスしていることが確認できる。
もし、セッションIDをURLに格納しているサイトの場合は、
Refererのステータスに「http://www.sample.co.jp/mypage.html?sessionid=12345」という感じで表示される。

３．４．クロスサイトスクリプティング（XSS）によるcookie情報の悪用

こちらは、クロスサイトスクリプティング（XSS）の仕組みの説明だけで、一つの記事となってしまうため、ここではさらっと述べます。

Webページ内を動的に操作するJavaScriptの脆弱性を悪用して、Cookieに設定されているセッション管理情報を盗む手法を用いる。

詳しくは、クロスサイトスクリプティング(XSS)の記事を別に作成予定です。

４．セッションハイジャックの被害

・情報漏洩
・ネットショッピング、オンラインバンキングなどの不正利用
・登録情報の改竄

５．セッションハイジャックへの対策

【クライアント】
・セッション管理がしっかりとしていそうなサイトを利用する
・WAFの導入でXSSの脆弱性に対応する

【サイト作成者】
・https通信を用いる
・セッションIDをURLに含めない
・セッションIDを難読なものにする
・同一ユーザのセッションIDを通信毎に変更する
・XSSの脆弱性があるフォームをなくす

次回は、XSS、Refererヘッダ等の記事を作成しようと思います。
ぜひ、ご覧ください。( *´艸｀)