セッションIDを固定する攻撃
攻撃者が自分の知らないcookieをわざわざ盗み取る代わりに、
標的のcookieを攻撃者が知っているcookieのセッションIDに固定してしまうという攻撃方法もあります。詳しくは後述のセッション固定攻撃の記述を参照してください。
- どのように固定するのか？
- 知っているcookieとは何か？
推測や盗用以外に、セッション管理の不備を狙ったもう一つの攻撃手法として、「セッションIDの固定化（
Session Fixation）」と呼ばれる攻撃手法があります。悪意ある人があらかじめ用意したセッションIDを、何らかの方法（脚注1）で利用者に送り込み、利用者がこれに気付かずにパスワードを入力するなどしてログインすると起こりうる問題です。悪意のある人がこの攻撃に成功すると、あらかじめ用意したセッションIDを利用し、利用者になりすましてウェブサイトにアクセスすることができてしまいます。
- センションの固定化を英語でSession Fixationと言う
- 知っているcookieとは
悪意ある人があらかじめ用意したセッションIDだった - なんらかの方法で利用者に気づかないように悪意のあるセッションIDを送り込みなりすますことができる
- ログインするときセッションIDは切り替わらないのか？
- どのような方法でセッションIDを送るのか？
3.利用者が悪意のある人に送り込まれたセッションIDを使ってログインする
4.悪意のある人用のセッションIDが利用者のIDでログインした状態になる
5.あらかじめ取得したセッションIDでアクセスし、利用者になりすます
セッションIDのお膳立てでは、特定のWebサービスで有効なセッションIDを攻撃者が用意し、それを正規ユーザーに使わせることで正規ユーザーになりすますことができます。このセッションIDのお膳立てこそ、セッションID固定化攻撃であり、事前に用意したセッションIDをあなたに使わせることで成立するのです。
セッションIDの管理原則としては、セッションIDはWebサーバー側で発行します。発行したセッションIDをブラウザに渡し、Webサーバーにアクセスするたびに与えられたセッションIDをブラウザが返すことでユーザーを識別し、管理しています。しかし、
Webサーバーの中には、ブラウザ側で発行したセッションIDを使用可能とする機能を有効化しているものもあります。セッションID固定化攻撃では、この機能を悪用するのです。まずは攻撃者が生成したセッションIDを含んだURLなどを正規ユーザーに送りつけます。
正規ユーザーがそのURLからログインすると、同じセッションIDを使って攻撃者も正規ユーザーと同じようにサイト内を徘徊することが可能となるのです。
- 自分のセッションIDと攻撃者のセッションIDをどう見分けるのか？
ハッシュ化されてたりして見分けること出来ないと思う。
- 攻撃者のセッションIDでログインしたら攻撃者のマイページが表示されないのか？
攻撃者は利用者にセッションIDを強制するために、正規サイトからセッションIDを取得する必要があります。
ここで取得するセッションIDは正規サイトにアクセスした際に生成されるセッションIDです。
セッションの固定化ではログイン前後でセッションIDが変わらないことが前提のため、攻撃者はログインする必要はありません。
Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim’s browser use it.
-
it doesn’t assign a new session ID, making it possible to use an existent session ID.、 ログインするときは新しいセッションIDを持たず既存のセッションIDを使用することができるからセッションを使って攻撃者がログインできる
この攻撃では、ブラウザ上のユーザーのセッションIDを攻撃者が知っているセッションIDに密かに固定しておき、ユーザーが気付かないうちにそのセッションIDを強制的にブラウザで使わせます。この方法であれば、セッションIDを盗み出す必要すらありません。攻撃方法は次のとおりです。
- 攻撃者は有効なセッションIDを生成します。攻撃者はWebアプリケーションの
ログインページ（つまりセッション固定攻撃の対象ページ）を開き、レスポンスに含まれるcookieからセッションIDを取り出します（図の1と2を参照）。- 攻撃者はセッションが失効しないよう、定期的にWebアプリケーションにアクセスしてセッションを維持しておきます。
- ここで攻撃者は、標的ユーザーのブラウザでこのセッションIDを強制的に読み込ませます（図の3を参照）。
通常は同一オリジン（same origin）ポリシー制限によって、外部ドメインから標的ユーザーのcookieを変更できないので、攻撃者はWebサーバーのドメインを経由してJavaScriptを標的ユーザーのブラウザに送り込んで読み込ませる必要があります。クロスサイトスクリプティング（XSS）によってJavaScriptコードの注入（インジェクション）に成功すれば、攻撃は完了です。セッションIDの例: 。XSSとインジェクションの詳細については後述します。- 攻撃者は、この
JavaScriptが仕込まれたページに標的ユーザーを誘い込みます。標的ユーザーがブラウザでページを開くと、そのユーザーのセッションIDが攻撃者の仕込んだセッションIDと差し替えられます。- 標的ユーザーのブラウザでは、仕込まれたセッションIDでのログインはまだ行われていないので、Webアプリケーションはユーザーに認証を要求します。
- 認証が完了すると、標的ユーザーと攻撃者は同じセッションを共有した状態になります。このセッションは有効なものとして扱われ、標的ユーザーは自分が攻撃されたことにも気付きません。
- Webサーバーの`ドメインを経由してJavaScriptを標的ユーザーのブラウザに送り込んで読み込ませるとはどうやるのか？
リンク先のURLに「javascript:」等から始まる文字列を指定された場合に、スクリプトを埋め込まれてしまう可能性があります。
このためにリンクからスクリプトが読み込まれる
- オリジンとは？
- 同一オリジン（same origin）ポリシー制限とは？
- javascriptを使ってセッションIDを書き換える
対策
ログイン後にセッションIDを再発行すること
ログインが成功したタイミングで新たに別のセッションIDを再発行し、そのセッションIDを使用するようにします。
これによりログイン後は、攻撃者が用意したセッションIDは使えなくなりますので、なりすましを防止することができます。
ウェブアプリケーションによっては、ユーザがログインする前の段階（例えばサイトの閲覧を開始した時点）でセッションIDを発行してセッションを開始し、そのセッションをログイン後も継続して使用する実装のものがあります。しかしながら、この実装はセッションIDの固定化攻撃に対して脆弱な場合があります。このような実装を避け、ログインが成功した時点から新しいセッションを開始する（新しいセッションIDでセッション管理をする）ようにします。また、新しいセッションを開始する際には、既存のセッションIDを無効化します（脚注3）。こうすることにより、利用者が新しくログインしたセッションに対し、悪意のある人は事前に手に入れたセッションIDではアクセスできなくなります。
セッションIDに変わる「しるし」を用いて対策する
セッションIDの再発行ができない場合、セッションIDとは別に、ログイン成功時に推測困難な秘密情報（しるし）を作成します。
そしてCookieへ格納します。
この秘密情報とCookieへ格納した値が一致するかを確認することで、なりすましを防止することができます。
セッションIDとは別に、ログイン成功時に秘密情報を作成してCookieにセットし、この秘密情報とCookieの値が一致することを全てのページで確認する（脚注4）ようにします。なお、この秘密情報の作成には、前述の根本的解決 4-(i) の「セッションIDを推測が困難なものにする」と同様の生成アルゴリズムや、暗号処理を用います。
ただし、次の場合には本対策は不要です。
上記根本的解決 4-(iv)-a の実装方法を採用している場合
セッションIDをログイン前には発行せず、ログイン成功後に発行する実装のウェブアプリケーションの場合