セッションをセキュアにするための要件を学ぼう
Web アプリケーションでは、セッションを利用してユーザーのログイン状態を管理することが多いです。 セッションの管理は、セッションIDと呼ばれる一意の識別子を使って実現されます。
このレクチャーでは、セッション管理におけるセキュリティ上の要件について学びます。 どのような攻撃方法があり、どのように対策をするべきかを理解しましょう。
目次
このレクチャーで話すこと
セッションハイジャックを防ぐために、セッション管理では以下の点に注意する必要があります:
- セッションIDを推測が困難なものにする
- セッションIDをURLパラメータに格納しない
- HTTPS通信で利用するCookieにはsecure属性を加える
- ログイン成功後に、新しくセッションを開始する
- セッションIDを固定値にしない
- セッションIDをCookieにセットする場合、有効期限の設定に注意する
セッションハイジャックとは何か
セッションハイジャックとは、攻撃者がユーザーのセッションIDを盗み、そのセッションIDを使ってユーザーのセッションを乗っ取る攻撃です。 セッション ID が盗まれてしまうと、攻撃者はユーザーと同じ権限でアプリケーションを利用できてしまいます。 Web アプリケーションを開発する際は、セッションハイジャックを防ぐための対策を講じる必要があります。
セッションハイジャックへの対策
セッションハイジャックを防ぐために、セッション管理で注意するべきポイントをまとめます。
セッションIDは推測が困難なものにする
セッションID は 1, 2, 3, … というように、推測が容易なものにするべきではありません。 連番など、攻撃者から推測が容易なものにすると、セッションハイジャックのリスクが高まります。
このため、実際の Web アプリケーションでは、ランダムに生成された文字列をセッションIDとして利用することが一般的です。
セッションIDをURLパラメータに格納しない
セッション ID は、リクエストの度にサーバーに渡す必要があります。 このときの セッションID の受け渡しには、Cookie を使いましょう。
Cookie 以外の方法として、セッション ID を URL パラメータに格納する方法が考えられます。 しかし、URL パラメータを使う方法では、攻撃者がリクエストした URL を見ることでセッション ID を盗むことができてしまいます。
HTTPS 通信で利用する Cookie には secure 属性を加える
セッション ID を Cookie に格納する場合、HTTPS 通信でのみ利用するようにしましょう。 Secure 属性は、Cookie が HTTPS 通信でのみ利用されるようにするための属性です。 HTTPS 通信は、通信経路上での盗聴を防ぐことができます。
ログイン成功後に、新しくセッションを開始する
ログイン前とログイン後でセッション ID を変更することで、セッション固定化攻撃を防ぐことができます。 セッション固定化攻撃とは、攻撃者がログイン前のセッション ID を盗み、ログイン後にもそのセッション ID を使ってログインする攻撃です。 この攻撃への対策は、ログイン成功後にセッション ID を変更することで実現できます。
セッション ID を固定値にしない
セッション ID は、ユーザーごとに固定の値を使うのではなく、ログインするたびに新しい値を生成するようにします。 固定値のセッションIDが盗まれてしまうと、いつでもそのIDでログイン状態をつくれてしまい危険です。
Cookie に保存したセッション ID の有効期限に注意する
Cookie にセッションIDを保存するときには、有効期限を不要に長くしないようにしましょう。 不必要に長期間有効なセッション ID は、セッションハイジャックのリスクを高めます。
一方で、むやみに短い有効期限はユーザーの利便性を損なうため、適切なバランスを取る必要があります。
まとめ
このレクチャーでは、安全なセッション管理について学びました。 セッション管理の不備は、セッションハイジャックのリスクを高めます。 以下の対策をしてセキュアなセッション管理を実現しましょう:
- セッションIDを推測が困難なものにする
- セッションIDをURLパラメータに格納しない
- HTTPS通信で利用するCookieにはsecure属性を加える
- ログイン成功後に、新しくセッションを開始する
- セッションIDを固定値にしない
- セッションIDをCookieにセットする場合、有効期限の設定に注意する