I am creating a social/blogging platform and I have storing their User ID in a session so I will echo the ID out of the session onto the page.
Can a person edit the session the take an identify of another user?
It depends on the method of setting the $_SESSION variable you use - check this related question for a bit more clarification.
A session is just a cookie with an identifier.
When I visit your site, you're webserver will create a session with the identifier XA7i9 for me (just an example) which my browser will store as a session cookie. Now, my browser is going to send XA7i9 with every request. When you store something inside $_SESSION, it will never leave your server.
However, if I tamper the session cookie and can guess your session identifier, say b8a76, your webserver might think I'm you. It depends on your implementation.
This question on Stackoverflow might be of interest you.
User can't edit your session variables if you do not allow him to do so.
He could stole SESSID of another user
Be aware of register_globals directive for PHP.ini
A user can intercept another user's session cookie value, change their own cookie to that user's, and take over their session. The only way to prevent this is to use SSL on your pages. This is the same reason that Facebook enabled users to select an 'always use HTTPS' option last year.
Related
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
Today I had skype interview for a job as PHP developer, one of the questions asked was about Cookies and PHP Sessions.
The question was, can PHP session be set and read, used, if Cookies are disabled in users Browser?
I told them not, beacuse PHP Sessions by default depends on setting a session cookie. When PHP session starts, new session Cookie is set with default name PHPSESSID, and that cookie holds value of that session id, for example: ftu63d8al491s5gatuobj39gk7
Then on apache server in tmp folder file sess_ftu63d8al491s5gatuobj39gk7 is created and it holds content of that session, for example: test1|s:12:"SessionTest1";test2|s:12:"SessionTest2";
They told me that's not true, and that you can use PHP Sessions even if user disables cookies in his browser.
Then I told them that you can do that, but then session id would be passed through URL as GET variable. And that's not secure and you must set it up in php.ini.
They were talking how you can use PHP Sessions even if Cookies are disabled in browser. And what if we are building web shop, and some granny uses our web shop and disables cookies and she joust don't care. And that PHP Sessions are great because you can use them even if user disables Cookies. I was like wtf, wtf wtf?!?!
I made test with two files, index.php starts session and sets session variables. And then session.php tries to read that session variables.
This is how it looks:
index.php
<p>This is where I start and set php sessions.</p>
<?php
session_start();
$_SESSION['test1'] = "SessionTest1";
$_SESSION['test2'] = "SessionTest2";
?>
<p>This is a link, that starts new HTTP Request, and tries to read session set on this page:</p>
<p>Read Session</p>
session.php
<?php
session_start();
var_export($_SESSION);
?>
<p>Back</p>
Now, if you enable cookies in your browser, visit index.php, and the visit session.php , session would be printed out.
But, if you clear your browser history and cookies, and then visit index.php, and then visit session.php, you would see empty array right?
So basically my question is, am I right?
Can you use PHP sessions if you disable cookies in your browser?
And do PHP Session mechanism by default, depends on setting a session COOKIE?
Update:
I was going mad about this, so I called back the guy I was talking with. And asked him, can PHP session work without cookies by default? The guy said "yes". Then I told him he is wrong and he said: "yes, yes, if you say so..." and start laughing. Then I told him, ok if PHP session can work without setting cookie, how would server know current user/browser session id, if its not stored in a session cookie? (I wanted to see if he knows that session id can be passed as GET variable) And he was quiet for at least 20s, and told me that he is a System Administrator, and that I should ask that the Developer guy. And that he is 43 years old and has huge experience of 13 years in the bussines (he started with 30? wtf?), but he trusts me on this one. And I explained him how Session work and that you can use it without Cookie but then session id is passed as GET variable, and told him I told them that on interview, but they ware telling me no, no no... :S
So basically, the guy didn't have a clue about PHP and PHP Sessions, and yes he was the one that asked me about sessions telling me that PHP Session can work without cookie, even when I told him it cant be done, and that there is a way to use PHP Sessions without cookies but it won't work by default. He was like, no no no...
At the end he told me that he was thinking that sessions can work without cookies because he, as System Admin on his servers, can never see sessions in tmp folder?!?!?
Anyway, those guys suck at PHP, there is no way I will accept job offer from them, and after all this I dont think they will offer me a job anyway...
Thanks for all the comments!
"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. "
Sessions: Introduction
If session.use_cookies = 1 (Cookie enabled.)
If session.use_cookies = 0 (Cookie disabled.)
If session.use_cookies = 1 then session stores the sessionId into cookie. Calling session_id() get the stored sessionId from cookie and saved data into session array will be found on all the pages. If session.use_cookies = 0 In this case session does not store sessionId into cookie and you will get each time a new sessionId using session_id() and data stored into session on other pages will not be found on another pages.
Yes session will work when cookies is disabled.
But first apache check php configuration settings.
Like:
--enable-trans-sid
and
--enable-track-vars
if these value are set true the session will passed by POST automatically.
If "--enable-trans-sid" and "--enable-track-vars" values are set to FALSE, we need to pass session id by using the SID constant.
< a href="index.php?<?= SID ?>" >Navigate from here< /a >
Need to set php.ini
ini_set("session.use_cookies", 0);
ini_set("session.use_trans_sid", 1);
So basically my question is, am I right?
Mostly. In the real world: YES.
Can you use PHP sessions if you disable cookies in your browser?
You CAN use PHP sessions without cookies, as long as the browser identity is obtained somehow and yields a unique value (and this value is passed to the PHP session layer):
session ID in GET (which is the "standard" PHP way if cookies are not allowed, and the "other" way you described). This value is then propagated automatically by PHP, e.g. added to all A HREF's and so on. Where it is not propagated because the automagical link recognition failed (e.g. complex URL built in Javascript), it is your responsibility to provide accordingly.
Or - and here we're not in Kansas anymore:
passed among the nonces with Auth Digest (this is a dirty trick, and of course requires that the whole site is behind an Auth-Digest access authentication scheme. And you can no longer use a "dummy auth" (i.e. http://welcome:guest#www.example.com ) because some browsers, e.g. Internet Explorer, do not support them anymore for security reasons)
recognizing the browser some other way ("fingerprinting") (this is normally(1) suicidal)
Use LSO (Local Shared Objects) to generate a random UUID if it's not there already, and store it so that it can be retrieved on subsequent accesses.
other ways ( see http://en.wikipedia.org/wiki/Evercookie )
(1) if you were in a LAN where you can trust the IPs, you could associate a "session" to the user IP. You might enforce a strict "no cookies" policy in a small firm and still have user sessions without resorting to _GET/_POST for your session ID.
You are right, Session cannot work without cookies.
To illustrate this try doing the following actions.
Login To Gmail.
After login disabled the cookies.
Refresh the page.
You will be redirected to the login page again as the server cannot identify the session.
Now again enable the cookies.
Refresh the page. (Note: Don't click on login button).
You will be automatically redirected to the Gmail inbox.
Hence, we can say without cookies session will not work.
Also, If you are trying to login into the gmail( taking as example you can take any website) with diabled cookies then it will message as "Your browser has cookies disabled. Make sure your cookies are enabled and try again."
If it was me, I would say "Yes"
Since you could store session in form / url somewhere to passed to next page (very bad idea). So, based on his question "can PHP session be set and read, used, if Cookies are disabled in users Browser?"
Then, it should be yes. It can read and used.
However, If user close browser, then it's gone, and that's it. (since that guy didn't ask about this part)
Yes.. It will Work
1.PHP will pass one GET parameter in URL with the name PHPSESSID but it can be changed session.name in php.ini file.
2. It add one hidden input in forms with same name.
You will need to put the session ID in the URL. You will need to make a change in your php.ini file so if you are on a shared host you will need to contact them to see what they will do for you.
// tell the PHP we want to use cookies from the session
ini_set('session.use_cookies', '0');
ini_set('session.use_only_cookies', '0');
ini_set('session.use_trans_sid','1');
session_start();
// then pass the session ID in the URL(inspect, navigate the network refresh the page you will see in the headers your session ID)
I am trying to understand security when it comes to session cookies in php. I've been reading a lot about it, but I still lack the specifics. I need the basics, someone to show examples.
For example: Do I place session_regenerate_id() before every session cookie? What more shall I think about. I am asking about specifics in code - examples if possible.
Thank you very much.
I am using 4 session cookies after logging in.
SESSION "site_logged_in" = true
SESSION "site_user_nr" = the number of the user to access user_table_nr
SESSION "site_user_id" = the user's id to use when changing data in tables
SESSION "site_user_name" = the name of the user to display on page
When I check if the user has access, I check if all 4 cookies are set, and if site_logged_in is set to true.
Are there better ways? Do I have the completely wrong idea about this? Can users easily be hacked?
In fact you need to have only one session in your website. When you call session_start() session is being created on server and user automatically gets session cookie. Think like session is a some sort of container that placed on the server, you can put whatever you want in that container. However session cookie is just a key to access that container on the server.
It means that you can safely put some data in the $_SESSION and only the user that have cookie with matching session id can read it.
About users being hacked. Yes they can be hacked as long as you don't use HTTPS connection, because cookies and all other data is being transferred in clear text, so if someone intercept users cookie he can access the data stored in the session.
Always use a security token for logging users. This security token could be generated by using crypt(). After logging users in, change the security token periodically until they log out. Also keep the server backup of all the session variables including the security token (in a database). This would also help you to track user login history.
One more personal suggestion: Never use any data from the database as session variables without encrypting it with any of the hashing functions or functions like crypt().
The session information is stored server-side. What you should check is that they're logged in, and that they exists/can log in (in case of deletions/bans).
As you're checking they exist/can log in, you can pull the other information from the database such as name, nr and so on. All you really need is a key called 'logged_in_user' or something that stores the ID of the logged in user. As Alex Amiryan said, the cookie can be copied, so you might also want to store the IP address of the last accessing view in the session, so you can try to ensure security.
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 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.