Lets say the client logs in successfully and the server ( Apache / PHP ) creates a session, where is stored the userid:
$_SESSION['userid'] = $UseridFromTheDB
What does this line exactly?
Stores the userid on server-side memory
Stores the userid on client-side cookie
Both 1. and 2.
I think the 3. is the correct, because I did not used any else code to make the session on server and make the cookie on client.
So as I said all I have to do to use $_SESSION global variable and it will make the magic for me. It will store the session variable in the memory on server-side and it will make the Set-Cookie header, so the userid will be stored on clien-side as a cookie.
So my question is, what if I modify the userid on client-side? For example if I see 100 as an userID and I will modify it to 101, then the next request will be made with userID 101, right?
The server will give me the content, which belongs to 101 userID?
It stores the session both in the server-side memory and client-side cookie.
No. The session information (e.g. all the variables) are stored in a file on the server only by default. The cookie is called PHPSESSID and is merely a unique ID that points to one of the files on the server. The name of this cookie can be changed by changing the session.name option in PHP's runtime configuration, so it may have a different name per website.
These files are stored in the tmp/ directoy of the server by default. Unless you have access to the folder that these files are stored in (a massive security flaw), there is no way to get access to them.
When I create a PHP-file with the contents below:
<?php
session_start();
$_SESSION['userid'] = 1;
$_SESSION['username'] = 'user1';
It created a cookie in my browser with the name: PHPSESSID and this content:
11j9etj85pfnq36h15qb9mu60v
This corresponds with a file called sess_11j9etj85pfnq36h15qb9mu60v in the tmp/ folder of my XAMPP install. This file has the contents below, which as you can see contains the variables present in the $_SESSION global.
userid|i:1;username|s:5:"user1";
What if I modify the userid on client-side?
How? Unless the website has a major security flaw that allows you to execute PHP code, or does something ridiculous like setting the $_SESSION['userid'] based on a form input, you have no way to modify it.
You could copy the session ID from one browser's cookies to another, but this is a whole other issue and not related to the session security. It may not even work if the website checks the user-agent and IP-address of the connection and logs you out if they don't match the information that the session was originally started in.
For example if I see 100 as an userID and I will modify it to 101, then the next request will be made with userID 101, right?
No, since the session is not based on a variable within it. You would need to correctly guess a PHPSESSID to hijack another user's session. Again, unless the website has a major security flaw, there is no way for you to change variables in the $_SESSION superglobal. Most somewhat-modern web frameworks like Laravel encrypt the session cookie and make the length longer than the default length, making it even more impossible to guess one.
Related
We want to use sessions instead of cookies for keeping track of a few things. However, when I close my browser, and I reopen a page to echo a session var, it doesn't exist (which is how it is suppose to be). Is it possible to prevent this from happening with some magic or anything?
This is not a duplicate question, all I see are people wanting to destroy sessions, I want to do the opposite and retain the session for as long as possible.
Any knowledge would be appreciated.
The right way of doing this is with a database, you can mimic or control php sessions and store them in a database instead of in a file ( as normal ). Then once you have control of the data you can base renewing session via the ip address or better yet by login.
So say a user logs in and then you need to store some data, you store that in the session but php will store it in your database table ( when configured correctly ). Latter the user comes back, initially any visitor would get a fresh session, however once they login you would be able to retrieve the past session they had. You generally don't have much control on if or when a client will delete expired cookies.
This topic is too extensive to put just a few pieces of example code but I did find this small article on the topic.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
The guts of it is to use this function, session_set_save_handler
http://php.net/manual/en/function.session-set-save-handler.php
Once you have control of the data you can do whatever you want, however I would caution you about relying only on the IP address and it would be preferable to use a login system for something like this to prevent serving the session up to the wrong visitor.
You cannot reliably control what happens on the client side, even using a separate cookie would not be reliable and would have the disadvantage of storing data on the client where it could be accessed instead of keeping it on your server. Sessions are controlled by cookies but the data in them remains on your server, the cookie just identifies the client.
As a side note, I personally dislike using sessions at all. It may be possible to store what you need in the url, then it can be bookmarked. The classic example would be input for a search form ( via $_GET ) or for paging purposes. There is nothing wrong with doing this if it's not secure data. The problem with sessions is if the data is for a page such as my "classic example" or for paging you get only one session, so you would only be able to have one set of search data at a time, in the url you could have several sets of search data open at once. That said it does largely depend on what you need to save or persist.
Reset the session cookie manually.
$lifetime=60*60; // duration in seconds
session_start();
setcookie(session_name(),session_id(),time()+$lifetime);
You can use session.gc_maxlifetime and session_set_cookie_params, i.e.:
// server should keep session data for AT LEAST 1 Year
ini_set('session.gc_maxlifetime', 3600 * 24 * 365);
// each client should remember their session id for EXACTLY 1 Year
session_set_cookie_params(3600 * 24 * 365);
session_start();
Note:
You can also change the session options globally by editing php.ini -
Session configuration options
PHP sessions use session cookies. Browsers have their own ways of dealing with them but they all consider them to be trash if you close the browser.
Session cookies are not and can not be made persistent. If you need persistent cookies, just use a regular cookie to save a user identification code that your server would recognize, and save their session information in a database or flat file indexed on that id code.
Note that accumulating sessions on the server progressively causes important performance and security concerns.
Note on other answers: All of them mention ways to extend the session cookie expiration which will not overcome the regular behavior when you close your browser window.
PHP will start a new session if a browser is closed and reopened.
The old session file is still kept in the session save directory, but a new session is started.
What does php look for in the browser to know that it must start a new session?
I guess what i am really asking is, what exactly does session_start() do under the hood
To simply answer your question, it looks for a cookie called PHPSESSID and if no cookie is supplied in the request, a call to session_regenerate_id is made to initialize the cookie value.
The cookie is then persistently used throughout the lifetime of the browser.
Unless other settings apply, this is a stripped down version of the default behavior.
The cookie containing the session id is set without an expiry by default. This means it will expire when the browser is closed. So the session will be lost at that point since the client won't have the old session ID anymore.
All you want to know is already written here: http://www.php.net/manual/en/function.session-start.php
session_start() creates a session or resumes the current one based on
a session identifier passed via a GET or POST request, or passed via a
cookie.
When session_start() is called or when a session auto starts, PHP will
call the open and read session save handlers. These will either be a
built-in save handler provided by default or by PHP extensions (such
as SQLite or Memcached); or can be custom handler as defined by
session_set_save_handler(). The read callback will retrieve any
existing session data (stored in a special serialized format) and will
be unserialized and used to automatically populate the $_SESSION
superglobal when the read callback returns the saved session data back
to PHP session handling.
Basically, PHP writes a special file in the file system (usually in the /tmp directory) and gets the data from there.
The session ID (PHPSESSID) is saved in a cookie in the users browser. If none is found/one is invalid it creates one. The image below may be of some help in understanding what you want to know (it's from Chrome).
Once PHP gets this session ID, it looks for the corrisponding session which is stored in the session save_path (normally /tmp on unix machines). It then gives you the ability to access the information stored in that session file using the $_SESSION superglobal.
The cookies are stored only if there is nothing outputted on the PHP page prior to the session_start() call. If there is something being outputted, the cookie is not stored and you need another method(as mentioned, SQLite or MySQL) to store those UNIQUE values and recognize and separate each user.
I'm setting up a script that my local pub will use to show users slide shows of images, menus, etc. My URL will accept a key(uuid), from which my script will query the database for the content associated with the key based on a company_id. The site will then just rotate through images via javascript or jquery.
Before serving out the content, I would like to make sure that the session or user is authenticated meaning that there is a valid company_id associated.
I've always used $_SESSION variables for web sessions. Since there will be no real need to time out a session, would there be any flags I can set in php.ini to never time out? Or would it be more beneficial to use cookies for this type of work?
Thanks.
You are probably better off using a cookie to store a login token for the user with a distant expiry date, so they are auto-logged in. Preserving $_SESSION indefinitely would cause session files to pile up on your server wasting resources on the filesystem. Instead, a cookie can hold some token (non-guessable value) that is associated with the user in your database. Basic information can be retrieved from the database then when the user returns.
When you call session_start() the script will try and set a cookie in the users browser containing the session id, there is no need to manually set one holding a "non-guessable value" since that is what the session id is supposed to be anyway.
You can change session.cookie-lifetime in the ini file (maybe even with ini_set()) to prevent the cookie timing out at the end of the session.
Preserving $_SESSION will not cause session files to pile up indefinitely. By keeping the session alive the same file will be re-used over and over again (since it is named after the session id), and PHPs built in session garbage collector will clear up dead sessions anyway.
While in general it is a bad idea to make sessions last forever, since it's your local pub, I doubt anyone is going to try and hijack their session. (and even if they did, all they'd get is what's for sunday lunch, right?) :)
Edit:
You could also periodically regenerate the session id, to add a bit more security.
I know that sessions are server side, so, it is possible to save a session even if the browser is closed?
For example save a session for one day.
Please do not suggest "cookies", in this case must be implemented sessions.
thanks
They are saved already (see your php.ini file for the session path)... In fact, the real issue lies in garbage collecting them.
If you want to store them longer, edit your php.ini file or, define a custom session handler:
http://www.php.net/manual/en/function.session-set-save-handler.php
session_set_cookie_params I think is what you are looking for. If you are storing the session in a cookie, this will allow you to set the lifetime of that cookie. So the user can come back anytime within that time frame and still have their original session.
Side Note
Give this a read for more about session lifetimes etc.
How do I expire a PHP session after 30 minutes?
php_value session.gc_maxlifetime 86400
You can set the above in .htaccess or modify session.gc_maxlifetime in php.ini
This defines how long PHP will have a session file for the user on the server before garbage collection (the example above will allow the server to maintain the sessions for 1 day), however sessions generally do rely on a session id cookie so if the browser is reset or clears the cookie the user won't re-attach to their web session (you are actually setting a session ID cookie to use sessions in most cases even if you don't realise it.)
You can create a database and store there the sessions and on client side just store $_SESSION['id'] wich is the id of the session in the database. But this will become a headache when you will have to store more and more variables in the session.
Like Gumbo said, pass it in the URL. But how I like to solve this is, instead of passing the SESSION_ID through the Url, just make it a hash, or encoded data.
Then whenever this user comes to your page. you can check in your headers if this hash/encoded-data is still in the valid time frame, and if this 'anonymous' user has permissions for thay zone.
THE DOWNSIDE: If this user passes around this link, anyone could access the data
THE UPSIDE: Extremely portable, and easy to implement
Store the SESSION_ID in a database bound to the users IP. whenever this user logs back in, start the session via setting the SESSION_ID with session_id
THE DOWNSIDE: A lot more work, and if the users ISP changes their generated IP regularly this won't work
THE UPSIDE: Even if he erases the SESSION_ID cookie you will be able to continue the session
there are many ways to do this but beign an artisan you could:
make an script that save each session for your users inside a file
OR
go to PHP.ini and change the session life time
OR
use the session_set_save_handler function more info here
Does anyone know how PHP maps session IDs to $_SESSION arrays? In other words, given session ID x, where does PHP pull the values from to populate the $_SESSION array?
And given a session ID and the url it came from, is there any possibility of someone being able to gain access to the values in the $_SESSION array?
By default, PHP uses the files session handler. These files are stored based on the session.save_path setting, but defaults to the system's temp directory (a highly insecure location, consider changing it)
This session handler stores each session as a serialized PHP array in a file named with the session ID.
If you can find out a session ID prior to it being cleaned up by the session garbage collection routine, it can be hijacked, as PHP does not internally do any sanity checks. You may wish to do your own by storing the user's IP address in the session and comparing it to their current IP, clearing the session if they don't match.
session.gc_maxlifetime controls how many seconds a session will be considered valid. After this point, the session has a small chance of being deleted every time a request occurs. Default is 1440 seconds (or 24 minutes).
By default, this chance is 1%, but can be altered by adjusting the session.gc_probability and session.gc_divisor values (they default to 1 and 100 respectively).
There are other session handlers as well, such as the ones included with the memcache or memcached extensions. There was once one based on the libmm shared memory library, but I believe that has been discontinued.
Session info is stored on server filesystem. There's configuration parameter session.save_path in php.ini. Some info about sessions security is given here: http://www.php.net/manual/en/session.security.php
Session data is usually stored in temporary files on disk (see the session.save_path setting) and the filename reflects the session ID.
In general, yes, if someone gets hold of another user's session ID and sends it along with his own request, he will gain access to that user's session. One way of solving this is to bind sessions to IP addresses and invalidate the session when a request arrives from a different address.
No, there is no possibility!
...unless your code or the code of any component used is insecure.
With the default implementation of sessions (which can be replaced by a custom one if needed) the data is stored in local files. Your server receives the session ID from the client in a cookie, finds the corresponding local file on your server and populates data into $_SESSION.
Gaining access to this data requires file-level access on the server, which is not impossible, unless your server is secure enough.
You can also write your own session handler to save the session to a database.
Also, if you want to make it harder to pin down the session ID, regenerate the session ID at strategic times (on privilege elevation, etc) -- or as often as you want.
Pass session_regenerate_id() the argument True to destroy the old session data.