Menu
According to the standard 2.4 documentation, the security.yml config file allows for the following configuration option:
session_fixation_strategy: none | migrate | invalidate
source: http://symfony.com/doc/current/reference/configuration/security.html
However, I fail to find any details in the official documentation (or elsewhere) on what this option actually does, or how it works in practice.
So, if I set this option to either "migrate" or "invalidate", how will this affect session handling in my system? For example, if I set it to "invalidate", would this mean that a context-local session is invalidated when the user navigates to a different security context?
860
The session fixation attack is not a class of Session Hijacking, which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.
Session Fixation exampleThe malicious attacker connects to the web server. The web server generates a SID (1234) and issues it to the attacker. The attacker then crafts a malicious URL containing the SID and uses various techniques (i.e – phishing) to trick the victim into clicking the URL.
“ - Session fixation is an attack where the attacker provides a user with a valid session identifier. It's similar to session hijacking, but reversed. Instead of stealing a user's session ID, the attacker gives the user a session ID, one that the attacker controls.
In short:
In detail:
None strategy: Nothing is (supposed to be) done in the default session implementation, thus the session is maintained from one context to the other.
Migrate strategy: "Migrates the current session to a new session id while maintaining all session attributes." (The session storage should regenerate the current session.) "Regenerates id that represents this storage. This method must invoke session_regenerate_id($destroy) unless this interface is used for a storage object designed for unit or functional testing where a real PHP session would interfere with testing. Note regenerate+destroy should not clear the session data in memory only delete the session data from persistent storage." Thus the session is retained from one context to the other.
Invalidate strategy: "Clears all session attributes and flashes and regenerates the session and deletes the old session from persistence." Thus the session is regenerated from one context to the other.
It was not revealed by your question what kind of session data you are trying to fetch.
But in any case, no separate session is generated for different security contexts:
http://symfony.com/doc/current/reference/configuration/security.html#firewall-context
Security (authentication) related data is stored under a separate key (based on the firewall name). So for example if you have a firewall with a name 'main', the authentication token will be stored under '_security_main', if you have a firewall (a separate context) with a name 'foo', the user and related token data will be stored under '_security_foo', etc.
So besides ->getToken ->getUser (etc.) the rest of the session variables will be available in different contexts provided you use the 'none' or the 'migrate' session strategies.
Take a look at the session interface for details (quotes are from these files) vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/SessionInterface.php
And the default implementation: vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Session.php
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
