外部リンク: » Session fixation
HTTP session management is core of web security. All of mitigation should be adopted to make sure session security. Developer should enable/use applicable settings appropriately.
セッションモジュールは、セッションに保存した情報を見ることができる のがそのセッションを作成したユーザーだけであることを保証することが できません。セッションの完全性を積極的に守るには、そのセッションに 紐づく値に応じた追加措置が必要です。
セッションに運ばれるデータの重要性を評価し、必要な保護策を講じてください。 この対策は、通常は何らかの犠牲を伴うもので、ユーザーの利便性を損なうことになります。 例えば、単純なソーシャルエンジニアリングからユーザーを守るためには session.use_only_cookies を有効にする必要があります。 この場合、ユーザー側でクッキーが常に有効となっていなければならず、 有効でない場合はセッションが動作しなくなります。
存在するセッションIDが第三者に洩れる手順は何種類かあります。 洩れたセッションIDにより、第三者が特定のIDに関連する全てのリソー スにアクセスできるようになります。まず、セッションIDがURLにより伝 送される場合です。外部サイトにリンクを張っている場合、外部サイト のreferrerログにセッションIDを含むURLが保存される可能性があります。 第二に、よりアクティブな攻撃者がネットワークのトラフィックをモニ ターしている可能性があります。セッションIDが暗号化されていない場 合、セッションIDはネットワーク上を平文テキストで伝送されます。 解決策はサーバー上にSSLを実装し、ユーザーにSSLを必ず使用させることです。
Since PHP 5.5.2, session.use_strict_mode is available. When it is enabled and save handler module supports it, uninitialized session ID is rejected and new session ID is created. This protects attack that force users to use known session ID. Attacker may paste links or send mail that contains session ID. e.g. http://example.com/page.php?PHPSESSID=123456789 If session.use_trans_sid is enabled, victim will start session using attacker provided session ID. session.use_strict_mode mitigates the risk.
Even though session.use_strict_mode mitigates risk of adoptive session management, attacker can force users to use initialized session ID which is created by attacker. All attacker has to do is initialize session ID prior to attack and keep it alive.
Session ID cookie could be set with domain, path, httponly, secure attributes. There is precedence defined by browsers. By using the precedence, attacker can set session ID that could be used permanently. Use of session.use_only_cookies will not solve this issue. session.use_strict_mode mitigates this risk. With session.use_strict_mode=On, uninitialized session ID will not be accepted. Session module creates new session ID always when session ID is not initialized by session module. This could result in DoS to victim, but DoS is better than compromised account.
session.use_strict_mode is good mitigation, but it is not enough mitigation for authenticated session. Developer must use session_regenerate_id() for authentication. session_regenerate_id() must be called prior to set authentication information to $_SESSION. session_regenerate_id() makes sure new session contains authenticated information stored only in new session. i.e. Errors during authentication process may save authenticated flag in old session.
Calling session_regenerate_id() function could result in personal DoS like use_strict_mode=On. However, DoS is better than compromised account. Session ID should be regenerated when user is authenticated at least. Session ID regeneration reduces risk of stolen session ID, thus is should be called periodically. Developer should not rely on session ID expiration. Attackers may access victim's session ID periodically to prevent expiration. Developers must implement their own expiration feature for old sessions.
Note that session_regenerate_id() does not delete
old session by default. Old authenticated session may be available
for use. If developer would like to prevent old authenticated session to
be used by anyone, developer must destroy session by setting
delete_old_session to TRUE. However,
immediate old session deletion has unwanted side effect. Session
could be vanished when there are concurrent connections to web
application and/or network is unstable. Instead of deleting old
session immediately, you may set short term expiration time in
$_SESSION by yourselves. If user accesses to obsolete
session(expired session), deny access to it.
session.use_only_cookies and proper use of session_regenerate_id() could cause personal DoS. When this is the case, you may ask users to remove cookies and warn users that there could be possible security issues. Attackers may set malicious cookies via vulnerable web application (i.e. JavaScript injection), vulnerable/malicious browser plugins, etc.
Developers must not use long life session ID for auto login as it increases risk of stolen session. Auto login should be implemented by developer. Use secure one time hash key as auto login key using cookie. Use secure hash stronger than SHA-2. e.g. SHA-256 or greater with random data from /dev/urandom or like. If user is not authenticated, check the one time auto login key is valid or not. If key is valid, authenticate user and set new secure one time hash key. Auto login key is long lived authentication key, this key should be protected as much as possible. Use path/httponly/secure attributes of cookie to protect. Developer must implement feature that disables auto login and removes unneeded auto login key cookie for users.