サーバへの接続・セッションハイジャックの仕組み②Webサーバ編
情報セキュリティ第四弾：セッションハイジャック②
１．会員制サイトへのアクセスの流れ
２．会員制サイトへのなりすましアクセスの流れ
３．セッションID盗聴に至った脆弱性が考えられるポイント
http通信を行っている
セッションIDの推測・偽装が簡易
セッション管理情報が観測可能
クロスサイトスクリプティング（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ヘッダ等の記事を作成しようと思います。
ぜひ、ご覧ください。( *´艸｀)