Is PHP sessions the same as cookies? I ask this because I'm writing a privacy policy and the site uses PHP sessions, MySQL, JQuery and CSS. If Session are not the same should I change or leave the cookies name?
Here is what I have so far.
Cookies - The Website uses "cookies," a technology that stores a small amount of information on a user's computer to permit the Website to recognize future visits using that computer. Cookies enhance the convenience and use of the Website. For example, the information provided through cookies is used to recognize you as a previous user of the Website (so you do not have to enter your personal information every time), offer personalized content and information for your use and otherwise facilitate your Website experience.
PHP sessions are stored, by default, in a temp directory on the webserver. The session id is stored in a cookie called PHPSESSID. By default, these are not tracking cookies and don't have to be persistent (e.g. they expire whenever you close your browser). So they are safe to use even in websites that have enforced privacy regs.
For instance, I worked for a major branch of the U.S. military and we used _SESSION's all the time, despite the U.S. government forbidding a great many types of cookies.
To make a session cookie non-persistent:
// Make the session cookie last for 24 hours.
ini_set('session.cookie_lifetime', 86400);
Sessions are stored in the server, and after an previusly set ammount of time, it dies, or in other words, its deleted. Sessions do not need permission from the user to create, as a matter of fact, php initializes a session for each new web request that arrives from an ip to the server.
Cookies, on the other hand, are data stored in the browser's data folder, and every user needs to authorize the site to use them, and of course, they are not shared, meaning that IE and Firefox cannot share a cookie.
An example would be to login in this site and next time you point your browser it will remember your credentials, but if you try to open it with IE, it won't know who you are, hence the fact that they don't share data.
Hope it helps
Best of luck!
Related
I'm currently working on a new website for a client that stores personal information and credit card info on the site. As such, security is a big concern for me. This is the first site I've built that has sensitive information on it, and so I'm not very familiar with the whole subject.
The site manages users using sessions. However, I'm finding it hard to keep the sessions secure. I want to implement a User Agent check that checks the browser every time a page is loaded. This way, when I copy the session ID into a manually-created cookie on my 'attacker' browser, the server will detect the user agent change (from Chrome to Firefox) and reject the session.
My question is, if I do implement this check to run EVERY time a page is loaded, do I run the risk of logging out my legitimate user? Is there any reason that the true user would change their user agent between pages? And if so, how likely is this to happen? Likely enough that I should abandon this approach entirely, or is it an acceptable risk?
EDIT: The cookies are set to expire as soon as the browser is closed. Also, the user agent that is set upon login is stored in the session and is hashed after a salt is appended to it.
Yes, the user-agent string can change. Session cookies often last longer than an individual browser session. If a user upgrades their browser (very common these days with the auto-updaters in Chrome and Firefox) then a different version will appear in the user-agent string.
In addition, some plugins are reported in the user-agent string, causing it to change if a user installs one.
Your user-agent string check doesn't really offer any additional security. I don't recommend it.
In my login code on my website, if the password & username are correct, I set a cookie to keep the user logged in.
I just heard from a user that he doesn't accept cookies automatically through his browser, and that that prevents him from logging in. That rhe cookie is not set.
Is there an easy way to counter that?
Tell me if you need the code I use.
It is possible to get this to work but often a real pain if you're using complex javascript/ajax.
In short, instead of storing the session id in a cookie, you embed it at the end of every link.
so
http://example.com/somepage.php
becomes
http://example.com/somepage.php?SessionId=ABC123
Unfortunately, while PHP can do this for you in some cases, it doesn't help with links you build yourself in javascript - and it only takes clicking a single link without the id to effectively log the user out
See this page for more information
As mentioned by Quentin in the comments, if you're not using a cookie to identify the browser which created the session, it's possible that sharing a link would share the session. This could be mitigated but not prevented by checking IP address/user agent but this would likely fail in large corporate environments with NAT and standard browsers
I am in need of session variable must be exist even after browser closed or system shutdown.
But in my page it will not support session scope between browsers that is at first i signin with firefox while i login with chrome browser it comes to login page . Why these happen . Please any body help me to solve this problem.
Thanks and Regards,
Alagar Pandi.P
alagar.pandi#gmail.com
Session scope between browsers is not possible. Sessions are identified by a token, which must first be given to the user, and then passed back later by the browser in some form. Generally this is done with cookies, although it can also be done by appending the token to URLs as the visitor browses around the site.
Since web browsers are separate pieces of software with their own methods of handling cookies, you cannot share cookies between browsers, and therefore you cannot share cookie-based sessions. It is possible to copy-and-paste a URL from a web site that contains a session token into another browser and continue the session there, but most sites use cookies, so this is not often possible, and it certainly doesn't accomplish what you would like to do.
What you ask is generally considered impossible, but also usually not an issue. On the plus side, it is also a process generally understood by most users. Users do not expect to log in to a site with one browser, and then boot up another and still be logged in.
session expiry between browser and
after browser or system shutdown ?
Neither after browser close nor system shutdown
Session is expired when its get timeout on server side, and it depends on each web server settings, for example, after 20 mintues.
Cookies are the only way to track users. They can either be persistent or not. If a cookie is persistent it is stored in the user's computer as a file and has an expiration date but only the browser that created it will be able to access it again. There's no way to achieve cross-browser cookies.
Then you should use. Client side cookies rather than session variables.
Session exists only until the browser close or system shutdown.
If you still want to proceed with session variable, then store the session value in the DB and whenever the login page loads check the db if the user hasn't signed out manually, if yes then show him main page otherwise show hime the login page.
This question already has an answer here:
What are cookies and sessions, and how do they relate to each other?
(1 answer)
Closed 5 years ago.
When i create a session variable where is saved username and password, how does it works internally? Same question about regular cookies where information is saved. Which type of information are included in coookie and session? What is the difference between them?
The best article on sessions and cookies I ever found is
http://shiflett.org/articles/the-truth-about-sessions
To sum it up a cookie is a file on the client's computer. You can store whatever in it (objects, text...). A session object can be stored in a cookie in the same way you can store some text. Keep in mind that session != cookie because sometimes you can store a session object in the database.
But still, you'll have to read up some documentation, I think.
Seen on wikipedia:
In computing, a cookie (also tracking
cookie, browser cookie, and HTTP
cookie) is a small piece of text
stored on a user's computer by a web
browser. A cookie consists of one or
more name-value pairs containing bits
of information such as user
preferences, shopping cart contents,
the identifier for a server-based
session, or other data used by
websites.
It is sent as an HTTP header by a web
server to a web browser and then sent
back unchanged by the browser each
time it accesses that server. A cookie
can be used for authenticating,
session tracking (state maintenance),
and remembering specific information
about users, such as site preferences
or the contents of their electronic
shopping carts. The term "cookie" is
derived from "magic cookie", a
well-known concept in UNIX computing
which inspired both the idea and the
name of browser cookies. Some
alternatives to cookies exist; each
has its own uses, advantages, and
drawbacks.
Being simple pieces of text, cookies
are not executable. They are neither
spyware or viruses, although cookies
from certain sites are detected by
many anti-spyware products because
they can allow users to be tracked
when they visit various sites.
Most modern browsers allow users to
decide whether to accept cookies, and
the time frame to keep them, but
rejecting cookies makes some websites
unusable. For example, shopping carts
or login systems implemented using
cookies do not work if cookies are
disabled.
Generally, session data is stored on the server, and it uses a tracking cookie to attach a user with the data. Cookies on the other hand are set directly in the user's browser.
One key difference: Session variables generally can't be seen by the end user, but cookies can(with the right browser plugin)
Also, if you have multiple front-end web servers, cookies will be sent to all front end servers, but session data is not shared between them without extra work.
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.