I'm using session in Laravel app which has login function.
Session is stored in DB.
My app session generates session Name "laravel_session".
Maybe, it is default Name.(I checked it in chrome debugger.)
I thought it can cause session fixation.
So, I use session->regenerate() after Login process.
However, it generate "laravel_session" again. Is it working?
I checked sessions table after session->regenerate() and I found column "id" is changed.
There's a huge difference between session_name() (which names the cookie) and session_id() (which should be a random, unpredictable value).
Your session name is public knowledge. It's the session ID that needs to be secret.
(Think of it as a key => value pair.)
Anyway, the point of session_regenerate_id(true); and the use_strict_mode configuration directive is to mitigate session fixation issues. You should always regenerate session IDs when the user changes their level of privilege (logging in, logging out, etc.).
Laravel already contains built-in protections against sesssion fixation, and a built-in function for you to do it yourself:
https://laravel.com/docs/5.6/session
Laravel automatically regenerates the session ID during authentication if you are using the built-in LoginController; however, if you need to manually regenerate the session ID, you may use the regenerate method.
$request->session()->regenerate();
Related
I ned to set a session per every user, so when the user log ou from his account and login again in another account the old session will not be shown but the new that related to his new account will be shown
I am using the normal method in laravel to do it
Session::put('key', 'value');
But the problem as explained is that the session will br shown in all user using this computer
Session ids are supposed to be non-guessable. You're going to have to resolve (attempted) duplicates serverside. If you search through every existing session for a match then your not going to be able to scale this / its going to be very slow. That means you need an access path to the session data based on the username AS WELL AS the session id.
There are lots of solutions to this. I don't think any of them are exposed directly in Laravel.
You need to deal with maintaining the mapping directly in the session management - so you will need a custom session handler. The session handler deals with serialized data - so you need to think about how the username is resolved within the session handler. You could put it in the session and deserialize the data again the handler, or read the value from a global variable. Or you could write a prototytype of the session into a database with the sessionid as the primary key and the username as an indexed lookup before the session close handler is called.
Another approach would be to store the session as the username rather than using the session id. You still need to protect the username though and avoid session fixation, hence you would need to explicity generate the session id using a mechansim where only you can recover the username from it, e.g.
$data=array($username, openssl_random_pseudo_bytes(16));
$sessionid = encrypt(serialize($data), $your_secret_key);
(You still need to write your own session handler for this).
I have some questions about the mechanism of session in code igniter framework:
1. isn't it exactly like working with a cookie? because what I have seen is that all the session data is send back as a cookie to the browser. so when another request is made then all the data is sent back with the cookie session.
2. the session data is sent back to the browser. even though it is encrypted, I can still identify all the session items, so isn't it easy to change the encrypted value of that item to an encrypt value, like changing an item called loged_in from false to true
3. when saving session data in a database, is the session data automatically deleted?
4. why is it written in code igniter documentation that "Session IDs can never be updated, they can only be generated when a new session is created". so when regenerating the session id in the cookie session how will we be able to compare it to the session id that is stored in the database?
The Session class does not utilize native PHP sessions. CI session library generates cookie when you initialize session in CodeIgniter. So actually sessions in CodeIgniter is a Cookie.
Setup Encryption Key on your config.php file and I'm sure that will resolve an issue you are having. Even CI session document says - "Even if you are not using encrypted sessions, you must set an encryption key in your config file which is used to aid in preventing session data manipulation."
I personally never tried DB Session but YES CI deletes expired sessions stored in DB. CI Documentation says - "The Session class has built-in garbage collection which clears out expired sessions", which explains pretty much about this question.
CI has taken care of this situation. When regenerating session id, CI replaces old session id stored in DB with new session id. If you can take a look in to Session library; check for sess_update() method for more details and you can see how CI is updating new session id in DB.
Hi I have a security related question I allow users to login and register my question is when a user logs in my script just sets the session no cookies so is it safe to only rely on sessions not on cookies? or I use both the cookies and sessions?
PHP sessions use cookies to track the ID of the session. Thus, it is safe, because you actually are using cookies.
It's worth noting that you should try to prevent session-hijacking - you can do this by validating the IP of the user among other things in your $_SESSION object.
Edit
I suggest you read this. Quote:
The session_start( ) function generates a random Session Id and stores
it in a cookie on the user's computer (this is the only session
information that is actually stored on the client side.) The default
name for the cookie is PHPSESSID, although this can be changed in the
PHP configuration files on the server (most hosting companies will
leave it alone, however.) To reference the session Id in you PHP
code, you would therefore reference the variable $PHPSESSID (it's a
cookie name; remember that from Cookies?)
Note: stores it in a cookie
I'm going to use Codeigniter's session data for my login system, but first I wanted to understand them, so I read the user guide, and from what I understand, Codeigniter's session data are just cookies.
Is this true? which means if the user disables cookies he wont be able to login to any website using Codeigniter's session data?
quoted:
The Session class stores session information for each user as serialized (and optionally encrypted) data in a cookie
So that means I should create my own native PHP session data to make users who disable cookies able to login my website? or Codeigniter's session data are not just cookies?
Yes, the CodeIgniter's inbuilt session class does use cookies, however, even the standard Sessions in PHP need cookies.
Thus, no matter which route you go, CodeIgniter Session, or the standard Session, either ways if the user does not have cookies enabled, Sessions won't work.
The advantage of CodeIgniter's Session class is it automatically encrypts the data as well to prevent cookie tampering, plus allows you to authenticate the cookie against a database.
Sessions in CodeIgniter or any other application using HTTP protocol are best kept track of using cookies. Normally, the session data itself is not stored using cookies, but a key to access this data is, whether the actual session data is stored in server's filesystem or in a database.
PHP allows to set session ID through cookies, POST or GET, but it is preferable to always use cookie or you will be opening doors to session fixation using ini_set('session.use_only_cookies', true). Practically everybody do have cookies enabled.
I have never wanted to allow a user to stay logged in for any length of time so I never saw a use for a "remember me" feature. I started thinking about how it's done though and would like some clarification.
I'm currently storing my sessions in a database. What has always perplexed me was how, even though I do not explicitly set a cookie, one is placed in my browser. I'm a little confused because a session is a session and a cookie is a cookie. I don't see how a session sets a cookie.
I'd also like to know if, simply setting another session variable in the session array to keep the user logged in, would be sufficient or would I still need to set a cookie?
In order to pull the session data back from your database a key is needed. This is called the Session ID.
The session ID needs to be stored somewhere. Either as part of the URL string that the client posts back or, more commonly, in a cookie on the client. When the request is posted, session reads the value from the cookie and knows which record to pull back from session storage.
This happens automatically.
The only reason to use session is if the data you want to keep is greater than 4KB (browser limitations); or if the time required to pull the data from your server is greater than reading it from session storage.
If the amount of data you are storing is less than 4KB I would highly recommend you just set that in the cookie to begin with. I generally store things like the user id, user first name, and a couple other attributes. Bear in mind that it is trivial to inspect a cookies value, so this information should be encrypted prior to going to the client.
Another thing is if the query time to pull the data you need from the original source is small, then elect to do that instead of placing it in session. That way you only get it when you actually need it instead of with every single page load.
What has always perplexed me was how, even though I do not explicitly set a cookie, one is placed in my browser.
A session handler has to identify which session belongs to which user.
The vast majority of session libraries do this by setting a cookie.
(Is) setting another session variable in the session array to keep the user logged in would be sufficient or would I still need to set a cookie?
Most session libraries set session cookies. These are cookies without a specified expiry time. They expire when the browser closes and are not sufficient to implement a "Remember Me" feature (which is expected to persist across browser restarts, so must have an explicit expiry time).
Explaining the relationship between Cookie and Session:
PHP uses Cookie to uniquely identify the session for each user. That's the only more reliable way because cookie is sent each time you request a file from the server. Using the token in the cookie, which is also the Session identifier, PHP will look up the tmp directory to see if the session exists. If the session exists, the variables are loaded from the correct file and you will be able to access the variables on that session.
Therefore, cookies store the session identifier which is required to identify which user uses which session. This is also how Session Hijacking come about, when people can change the session identifying cookie to use another person's session identifier.
The underlying PHP session implementation sets the cookie. You can alter this and have the session ID value passed in the query string, but I don't recommend it. You don't use the cookie, PHP does. It references the session ID value stored in the cookie to perform lookups to session data.
I'd also like to know, if simply setting another session variable in the session array to keep the user logged in would be sufficient or would I still need to set a cookie?
As soon as the user closes the browser, the session is killed and the cookie is deleted. I don't believe any mechanism exits to persist the session value, and for good reason.