セッションCookieを盗む保護
セッションCookieが盗まれないようにWebサイトを保護する方法を探しています。これらは、広く知られている/使用されていることがわかっているコントロールです。
- HTTPS Everywhere
- 安全に作成されたランダム文字列のみをCookie値に使用します
- セッションCookieをSecureおよびHttpOnlyとしてマークする
- ログイン時にセッションCookieを変更する
Tomcatバグトラッカー で見つけた提案を使用して議論しています。セッションストアごとに、次の追加情報を保存します。
- SSLセッションID
- HTTPユーザーエージェント
- リモートIPアドレス
各リクエストで、3つの保存された値のうち2つがセッションでキャプチャされた値と一致することを検証します。このようにして、3つのうちの1つは、ユーザーに影響を与えることなく、さまざまな理由で変更できます。通常のユーザーがリクエストごとに複数を変更することはほとんどありません。
これは、セッションCookieに対する適切な追加防御のように見えますか？
サイト開発者の観点からは、以下を使用する必要があります。
- SSLを採用：サイト全体でSSLを使用します。
- すべてのCookieに
secureフラグを設定します。これにより、SSL接続でのみ送信されます。 - HSTSをオンにします。
これにより、SSL経由でのみセッションCookieにアクセスできるようになり、盗聴や中間者攻撃から保護されます。
このサイトでSSLをサイト全体で検索して、これを行う方法に関する多くのリファレンスを見つけてください。
HTTPユーザーエージェントやリモートIPアドレスを確認する必要はありません。これらはセキュリティをあまり追加せず、特定のシナリオでの正当な使用を妨害します。 SSLセッションID（SSLセッションバインディング）をチェックすることは、セキュリティの観点からは問題ありませんが、構成するのが少し面倒で、私にとっては優先度が高くありません。他の防御策は問題ありません。
その他のアドバイス：
XSSを介したCookieの盗難が懸念される場合、最善の防御策は、WebアプリケーションでのXSSバグを回避するための標準的な方法を使用することです。多くの優れたリソースについては、OWASPを参照してください（コンテキスト依存の出力エスケープを使用する必要があります）。
「セッション固定」をタグとして言及しますが、それはまったく異なる脅威です。セッション固定に対する防御は、セッション固定に対して脆弱ではないフレームワークを使用することです。最近のほとんどのWebアプリケーション開発フレームワークは、追加の作業を必要とせずに、これを処理します。
安全なWebアプリケーション開発プラクティスに従ってください。 OWASPには、これに関する多くの優れたリソースがあります。
@Rookのアドバイスを注意深く読み、それに従ってください。
実装2/3検証は正常に機能します。私はこれをテストしていないか、それが実行可能な方法かどうかさえ知りませんが、リクエストごとにセッションキーが変化するような「変化するキー」を実装して、攻撃ウィンドウを下げることもできます。