Can PHP sessions be edited like cookies? Or they're stored on the webhost?
The session key is stored in the client's browser, while the data is stored on the server.
When the user makes a request on the server, their session key is sent across the network and the values associated with their key are retrieved from the specific session file on the server and are made accessible via $_SESSION.
It it possible to hijack another user's session if the key is intercepted, which is why you should have specific values in the session which associate to the user's computer/network connection (IP address, for example).
Session data cannot be edited by the user, as they are stored on the server. The user can, however, start a new session and ditch whatever session data he previously had. Also, you should be aware of portential security issues, such as session fixation.
Usually they're stored in the /tmp directory of a webserver if the host isn't careful. This can be changed with session_save_path(), it's something I do with all of my PHP applications that use sessions.
This works like below:
Browser requests page, submitting your SID or Session ID with help of a cookie or with the URL.
Server finds cookie files inside the session_save_path() and unserializes the array
You access that info with PHP
Alas, the only thing the client knows is the session's ID, but that can be hijacked, for example by using cookie stealers, or other Cross Site Scripting methods. If I, for example, got your SO session, SO wouldn't know better than I was you. Unless they also check my IP or something like that.
Related
The administrative control panel for a site I am building needs a login script. The active users are stored in a mysql table, but once a user is authenticated, should I store the token as a session or a cookie? Which (if either) is more secure?
Sessions, definitely. They're stored on the server. Cookies are stored on the client side and can be easily edited by the user.
A session is nothing more than a server side cookie in the sense that the data is stored on the server. The client still gets a cookie, for PHP it's (PHPSESSID or something like that) which is just a number identifying the session.
Some advantages of using sessions is that you don't have to pass the data with every request and that the client can't 'mess' with it.
Also, in PHP you can implement your own session storage mechanism, so you're not tied to any session size limit, but that's probably well outside of your scope :P (session_set_save_handler, see PHP.net for more info).
I need to transfer the user session across servers. ie. If user logged in server1 and if the user exists in server2 , then I have to transfer the user session details to server2. For this I used the following technique
From server1, redirect user to http://server2/auth_from_server1.php?sessionid=12345
On server2 (internally, in the PHP code of auth_from_server1.php), do a request to http://server1/secret/check_session_id.php with the sessionid, 12345.
On server1, in the implementation of check_session_id.php, validate the ID and return OK, FAILURE, and session related data you want to pass, such as username, ...
On server2, when the call returns with OK, store the transferred session data, and give the user a cookie and session for this server.
But when the call back function call the auth_from_server1.php the value in session id is null. I tryed to check the sessionid as
if(isset($_SESSION['sessionId']))
echo 'true';
else
echo 'false';
But $_SESSION['sessionId'] is null. In login page I am setting the value for session id as
$_SESSION['sessionId'] = session_id();
Thanks in advance....
Wouldnt it be easier to just store session data in a shared directory?
Alternatively you can store it in a database.
I would suggest writing a custom PHP session handler or using a prebuilt session handler like ShareDance. You can store session information in a MySQL database shared amongst the two machines, a SQLite file, etc.
There are many benefits to using PHP's built in ability to get/set session data by using session_set_save_handler() namely, that all calls to get or set from $_SESSION will work in your application code without any additional modification.
More information can be found here:
http://php.net/manual/en/function.session-set-save-handler.php
A tutorial on writing custom session handlers (old but still relevant) is here:
http://devzone.zend.com/article/141
When server 2 calls server1/secret/check_session_id.php it has to submit the session ID like server1/secret/check_session_id.php?sessionid=12345 and in check_session_id.php you have to call session_id($_GET['sessionid']) before session_start().
Another opportunity could be sharing the filesystem.
Since PHP puts the session in the filesystem, you could share the filesystem (sshfs for example) on both servers.
the setting for changing the destination directory in the php.ini is
session.save_path
This problem can quickly get out hand when you start adding more and more severs to the problem. One of the best solutions that I have found is to store the session on a database and share that database with the servers. Redis typically works great for this. Here is a great guide to get started with redis
I think to store an id of a user in DB is the most appropriate way to do this.It is an error proof way.
Cheers
I'm making a forum for learning mostly but hopefully it will have a couple of users some day.
What im wondering is should you use sessions or cookies for user authentication?
A cookie is a short piece of arbitrary data that the server sends through a header; the client stores it locally and sends it back on the next request. This mechanism can be used to maintain state from one request to the next even though HTTP itself is a stateless protocol. Cookies have two disadvantages: They offer only very limited amount of space (4 kB), and because they are sent back and forth in plain, a malicious client can fiddle with the contents before sending it back to the server, effectively making cookie data untrusted.
A session is a file on the server, identified by a unique ID which is sent back and forth between client and server so that the server can identify the client. The most popular way of sending the session ID is through the cookie mechanism, but it is also possible to pass the session ID through the URL (this is why you often see links that contain the URL parameter 'phpsessid'). This solves the two problems with cookies mentioned above: A file on the server can be as large as required, and the client cannot access the data other than through your own scripts.
Authentication is typically solved using cookie-based sessions; once authenticated, a new session is created, and the user ID is stored in it, and when logging out, the session is cleared and a new session ID is generated. Alternatively, you could store username and password in the session, and check them on every request.
Use a session.
A session is identified by a cookie, true, but not the same as storing user auth info in the client cookie, which is bad for security. A session cookie stores a guid or a hash in the cookie, then identifies the session (either database or file system based, depending on your server's php settings) based on that.
I recommend you store the primary key from your user table, not any other info, then look up the user info every time - this allows you to change their validation status, or security level on the fly while they are logged in; otherwise they will have to log out and back in before your administrative changes take effect for them - IE. you can't boot them.
Also, don't store the username/password, because that requires a less efficient query than by the indexed primary key (even if they are indexed as well).
They are essentially the same, working hand-in-hand. When you create a session..say through PHP, a cookie is created to store the session id too. On the other hand, you would create another cookie if you want to implement a "Remember Me" option to prevent your users from logging in every time.
I'm not a PHP expert, but Session and Cookie are related. In other programming languages you have the option of creating "Cookie based session" or "Cookie-less session". I'm not sure about PHP though so maybe you are referring to different concepts.
I feel using session is much more safe and easy then using cookies. The reasons are as follows:
1) In cookie we can only store a single piece of information, whereas in a session we can store as many information as we want.
2) Being stored on hard disk of user, cookies can be played with. Being a person interested in hacking, I have done that and gathered useful information about the user. Sessions cannot be used for such a thing.
If its a small amount of data (just one variable), I would use a cookie. Here is the code...
setcookie("cookie name", "cookie value or variable name", time+ 3600, "\");
this code sets a cookie that is readable for any of your webpages. It also will delete its self in one hour.
You can also see if the cookie exists like this (to see if it has deleted its self).
if (isset($_COOKIE['cookiename']))
{
}
to collect a value from a cookie...
$value = $_COOKIE['cookiename']; //makes a variable for this cookie for your program
I save some important info in $_SESSION, not in $_COOKIE. So, my question, is it dangerous? Or is it protected from malicious users trying to edit it and I'm fine?
Thank you.
By the way, is it possible also to edit $_COOKIE? I heard yes, but if yes, then how?
$_SESSION is stored server-side. The best a hacker could do would be substitute another user's session for the existing session, but the hacker could not insert arbitrary data into $_SESSION. $_COOKIE is, however, stored client-side, so a hacker can insert arbitrary data into the cookie, by just editing the cookie.
By default, the $_SESSION is already backed by a cookie with the name phpsessionid (so that the server is able to identify the client and associate it with one of the sessions in server's memory). If a hacker knows the cookie value of someone else and copies it in its own cookie with the same name on the same domain/path, then the hacker has access to the same $_SESSION. The cookie value is however long and random enough to minimize the risks the session being hijacked within half a hour (the default session timeout).
If you're worried about people altering sessions (session hijacking) look into session_regenerate_id()
$_SESSION is stored on your webserver, so it's not possible to directly alter it via the web. Of course, your PHP application can update $_SESSION, so it still might be possible for an attacker to trick your application into doing something to $_SESSION that it shouldn't - it all depends on the specifics of your application.
$_COOKIE is stored on the user's browser, which means that the user has the power to change their own cookies.
One of the main uses for cookies is authentication. A user logs in and information is stored in $_SESSION. A cookie (stored in $_COOKIE) records the session id of the user so that your application knows which session belongs to the logged-in user.
Yes Hacker can hijack the session you can use session_regenerate_id() , or stole it
look
if you are admin and you logged in ,( session is in the server )
hacker have it via xss = > will make cookie in his pc with this session and log , change the pass or add admin , besore the end of the session
cookie can stole too ,
look this code
setcookie("admin","admin_log",time()+3600);
if hacker know the code like opensource he can log as
make cookie by firefox addons as the cookie name and value
Cookies are sent via the user-agent every time a page is requested. The user-agent doesn't need to be a browser. It could be a small shell script. Even if it is a browser, there's an "edit cookie" extension for Firefox.
$_COOKIE contains information that the client sent to your web server. Most commonly this is the contents of browser cookies but t could contain ANYTHING, so don't trust it.
I am interested in knowing how session management and cookies work in PHP. I want to know their underlying mechanism, like how the browser interacts with the cookies, and how the cookies are used to validate the session data in the server.
Is there any web resources that allow me to learn that?
In PHP in particular, the standard way sessions work is that PHP generates a random session ID, and puts it in a cookie. (By default called PHPSESSID) This cookie is handled by the browser by saving it locally on the user's machine, and is sent with every request to the domain it belongs to.
This session ID is then used to refer to a data store on the server machine, by standard located in /tmp/ on an apache install on linux. This is where everything in the $_SESSION array is stored between requests.
As you may notice, this is only as safe as the cookie is, as there is no real authentication between the user and server that the user is the "real" owner of the session ID. This means that so-called "session hijacking" is possible by sniffing the cookie and inserting the cookie with the session ID on the attacker's machine. This can be used to take over an account on a webpage, and browse around it just as if you were the original user, because to the server you are.
There's also an alternate, even more unsafe, way of keeping the session alive that PHP supports. This is done by sending the session ID as a GET variable with every link. As you may notice, this means that if a user simply copy-pastes one of these links, he will be giving away all his credentials. =)
Further information could be found in the PHP manual.
From PHP’s Session Handling manual:
A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
This unique id is a big random number that is stored on the server side to match it next time the client makes a new request. It typically goes into the /tmp directory.
A cookie is a bit of data that's associated with a HTTP address.
I.e.
1/ Browser requests www.google.com
2/ www.google.com response includes setting a cookie
3/ From this point on and as long as the cookie is valid (there's an expiry time associated with it), each subsequent request made by the browser to www.google.com/anything includes the cookie above
For details: http://en.wikipedia.org/wiki/HTTP_cookie
A cookie permits creating a session in the otherwise stateless HTTP protocol in the sense that it allows a client-server conversation to be isolated from other clients interacting with the server.