I have an owncloud and a roundcube sharing the same session pool via a memcache server and I would like them to work with an unique session.
I changed the cookie session.name to have the same for owncloud and roundcube and I tried a lot of tricks: to pass the session id then the session name via url, to change the $_SESSION['user_id' in roundcube because owncloud has the same variable, to avoid the cookie creation in the session_init from roundcube, etc...
But, the roundcube session always erase the owncloud one which causes owncloud not to login anymore.
What is the trick ? Is there a method somewhere to do that ?
I use the 'RoundcubeLogin.class.php' to perform the login from owncloud to roundcube but it creates separate sessions for each.
why do you want to share the session? What do you want to achive?
If you're just wanting to avoid another login, you can use the same login for roundcube or owncloud and use the auto-login feature
Related
Steps to re-create the issue:
Login with Admin Credentials and copy the session cookie.
Open another browser, Login as another user, paste the session cookie of the admin. Refresh the page. Now, you'll be
logged in as Admin.
How to solve this issue? Any suggestions would be of great help.
Tried using the event subscriber to get the previous session before drupal loads the cookie session, but no luck with it.
This is not a problem, I mean, of course, Session Hijacking is a really big concern - but standard defences are fine.
These are the controls that I know are widely known/used:
Ensure HTTPS is used everywhere,
Only use a securely created random string for the cookie value,
Set the secure flag on all cookies. This will ensure that they are only sent over an SSL connection,
Change the session cookie on each new login attempt.
All of Drupal 8's cookies are secure by default.
The exception is BigPipe's no-JS cookie, see https://www.drupal.org/node/2678628 — but there are no security consequences there.
I know some very sensitive applications may also store - for each session - the following additional information:
SSL Session ID
HTTP User Agent
Remote IP Address
In my point of view, I wouldn't bother with checking the HTTP User Agent or the remote IP address. They don't add that much security and they will break legitimate use in certain scenarios. Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but could be painful to implement, the other defences are fine.
If your concern is Cookie Theft via XSS, the best defence is to use standard methods to avoid XSS bugs in your web application. See OWASP for plenty excellent resources.
You may find a lot of best practices to write secure code for Drupal 8 here: https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8
You may also find a pretty old discussion about this on Drupal here: https://www.drupal.org/project/drupal/issues/19845
Our Laravel 5.1 application has been using the "native" session driver setting (configured in the .env file). With it set this way, we were able to use the laravel url.intended behavior to redirect the user to the url they were attempting to access prior to being authenticated.
We had to change it to "cookie" because every time we use Amazon's Opsworks system to deploy a new build, users were logged out because their server-side session files were no longer available. Once we changed it to cookie, the users remain logged in even when we deploy a hotfix or new build.
However, with it set to cookie, the url.intended does not work at all. I tried hacking together some solution by adding a custom url intended node, but it just won't work. It seems like when the user attempts to access a url prior to being logged in, it sets the session info, but then the application redirects the user to the login page where it's getting nulled out.
I'm using Debugbar to look at the session vars and I'm going crazy. I'm already bald so I have no more hair to pull out.
Does anyone have any ideas?
We ended up setting up a Dynamo database at first and then transitioned to Redis on a common server. We have a load balancer and don't want sessions getting lost or corrupted by switching servers so all cache is now being stored in that common location.
As we know when we login to a system, they creates some type of sessions or cookies to keep track which user is logged in and further processing is based on sessionid or cookies.
Is it possible to get the session or cookies from virtual server and access website from some other location or browsers?
For example :- I have login credentials of a website abc.com, I logged in that website on remote server and get the sessionid or cookies created by website on remote server browser.
Next based on that sessionid or cookies without login to abc.com again I can access the whole features? Is it possible or not? If yes then how?
may be some type of session hijacking?
Note: I don't need it for hacking purpose.:)
thanks in advance.
I have a MediaWiki running on multiple AWS instances and login and registration is broken. The session.save_path is set to /tmp which is writeable and readable by anyone. I use Apache2 and PHP5 as well as MEMCACHED.
Whenever you try to login you either get informed that there is protection against session hijacking or that you have cookies off. These are the errors:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.
Wiki uses cookies to log in users. You have cookies disabled. Please
enable them and try again.
I use a shared cookiedomain in the format ".domain.tld" and the entire domain is behind CloudFlare and an Amazon ELB load balancer. All LocalSettings.php are the same and the Apaches have shared configurations.
Per Aaron Schulz, don't use the default session handling, it's disastrous.
As you have memcached enabled, add
$wgMainCacheType = CACHE_ANYTHING;
$wgSessionsInObjectCache = true;
in your LocalSettings.php and let us know if things improved (they definitely should).
I have a Symfony application which use a mysql database to store session data, and uses the SfGuard plugin to manage the authentication.
Despite that symfony allways save the authentication info in a cookie. Is there anyway i can disable cookies and store the authentication info in the database or in memory?
I might need in the future, to have a kind of single sign on feature, where the authentication state will persist between multiple applications, in different domains. Thats why I mostly want to eliminate the need to use cookies.
Thank you for your help.
You do not seem to understand how sessions work.
That cookie that gets sent to the cient is called the session id, and it's unique to the visitor. When he reqests a page from the server that cookie identifies the row in your session table where his data are - no data besides the ID is ever sent to the client.
Without that ID there's no way to pair a request to session data, that's why you could not log in anymore after disabling the cookies. The alternative to the cookie is to pass the session id some other way, like in the url - php can do that automatically, you just need to enable use_trans_sid in the php.ini.
Yes, you can store the authentication info in the database : See here how.