I have a question regarding session hijacking in PHP. I have been reading about it this morning and I have a few questions that just weren't answered clearly in the documentation I read.
Can a user change their session on my website? i.e. if they have a session of X when the login, can they change that session to Y, or Z, if they so choose?
I thought that sessions were set by the browser and they couldn't be changed, but all of this session hijacking stuff I've been reading has put some doubt in my mind.
The term "session" is overloaded to mean different things on the server and in the browser. Browser sessions are at best tenuously connected to server sessions. "Session hijacking" refers to server sessions.
Server-side, a session has an ID (which is passed between the client and server), content (stored on the server) and potentially other properties, such as last access time. The session ID is usually passed as a cookie. In PHP the default name for the cookie is "PHPSESSID". If cookies aren't available, PHP will (optionally) use a query string parameter of the same name ("PHPSESSID"). This cookie (or query param) can easily be changed and therefore the session identifier can be changed too.
The contents of a session (i.e. containing the login state of a user) cannot be changed by the client, the data is stored on the server and can only be changed by a PHP script on that server. Note that in a shared-hosting environment (shared by other services or users), the sessions can be overwritten if using the default session storage directory (/tmp). To protect against that, either use a database through session_set_save_handler() or set a custom session directory using session.save_path with the proper directory permissions set (preferably 700 which means that only the owner (the PHP user) can read and write to it).
To protect against session hijacking, you must have other ways to identify the user against a session. This can be a user agent, IP address or another cookie. The previously mentioned methods are just workarounds, best way to protect against stealing of the session cookie is by using HTTPS if a session is involved. Do not forget to set the httponly flag to true using session_set_cookie_params()
Client-side, "session" is again overloaded and used in various contexts (e.g. session managers, which restore open pages when a browser is opened, session cookies and sessionStorage). We can try to combine these meanings (into what is by no means a standard one) by saying a browser session consists of a collection of views and their associated data. (By "view" I mean roughly tabs in tabbed browsers and windows in non-tabbed browsers; the DOM window object exposes a view to JS.) Each view has a history, a current page and page data. Page data for pages in the same domain is shared between views in a session; if two pages are in different domains or different sessions, they don't share data. Exiting the browser closes all open session(s), possibly saving part of the session(s) (e.g. histories, current pages, sessionStorage) so that a session manager can re-open them. Session cookies are cookies that are discarded when a session is closed; in other words, session cookies are non-persistant. Though a session cookie may hold a session ID, the two concepts are orthogonal (sense 4; session cookies can hold things other than session IDs, and session IDs can be stored in persistant cookies).
Whether two different views are in the same collection depends on the browser. For example, one browser may consider a session to consist of all tabs within a single window; separate windows are separate sessions. IE8 lets users create new sessions via the "New session" menu item. Otherwise, new windows and tabs are opened in the same session. Privacy modes also create new sessions.
In summary, browser sessions are indeed set by the browser, though it provides users various means of controlling browser sessions: creating new sessions, changing the history and current page in a view by browsing, saving and restoring sessions. A user could even change session data by editing sessions saved on disk, though this isn't a feature afforded by the browser. None of this has anything to do with session hijacking. Server sessions are created and managed by the server, but users can (attempt to) switch server sessions by changing the session ID their browser passes back to the server, which is the basis for session hijacking.
See also PHP Session Fixation / Hijacking.
A user can change his session at any time. It's just a random string stored in a cookie in the users browser, and therefore it is very simple for the user to change it.
As the actual content of the session is stored on your server, you could for instance store the user's ip address, user agent or similar to make it harder to steal sessions from each other, by checking if this information still matches each time a new http request is made.
No actually user can not change the actual session value at your website but can change the session id that is used to track the session this session id is stored on client browser by your website usually name "PHPSESSID" in cookie which are also known as session cookie. When a session is started on a site it stores the unique id corresponding to that session in the respective client browser in form of cookie named as "PHPSESSID". So if user is able to get PHPSESSID of any other user and it can replace his PHPSESSID with the victims PHPSESSID and it will result in session hijacking.
I am using PHP context here.
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
Hi I would like to know the difference between a php session and a cookie
The main difference being that session data is stored on the server, while cookie data is stored on the client. Therefore, a client can easily modify the cookie contents, but will have to work way harder to modify the session contents.
Cookies are a means to store information in the end-user's browser, so that the server can track the end-user.
Sessions are also implemented by using cookies, but the actual data is not in the browser; rather, it is stored in the user's session record on the server. In the case of sessions, cookies are used to identify a particular end-user's session identifier on the server records. Hence, they are a more secure way of storing user information.
A cookie is a ~piece of data stored on the client side.
Data stored in session is stored on the server side, and the various sessions are identified by cookies.
There are session and Cookies, both are used to store values or data. But there are some key differences between session and cookie: a cookie stores the data in your browser and a session is stored on the server. Cookie data is available in your browser up to expiration date and session data available for the browser run, after closing the browser we will lose the session information.
A cookie is often used to identify a user. A cookie is a small file that the server embeds on the user's computer. Each time the same computer requests a page with a browser, it will send the cookie too.
A session variable is used to store information about, or change settings for a user session. Session variables hold information about one single user, and are available to all pages in one application.
A cookie is an unique information that the user sends to the web server with each request in order to identify him. This unique id could be used to store information about this specific user on the server (session).
Cookies will only expire on expiry time or if you explicitly clean cookie / cache of your browser. Cookies will retain into the system even after you open your browser next day.
Cookies are stored on client's system so they are less secure.
Session will expire on its expiry time or if the browser has been closed. As session is stored on server so it is more secure.
So for a login module, a combination of session and cookie should be used
Cookies stored client side but session stored server side.
cookies is without sign out of the your email account and close it. once again can not enter username and password but your email account is open.
session is close the webpage once again open to starting page appier
best example to illustrate the difference bet. Session and Cookies is:-
when you Login as a member in any Site it Creates Sessions until you log out...
that is Session..
and Cookies when you browse websites the are stored on your computer's Main Memory that is Cookies
i-e Session is Server side
and cookies is Client side
We got three differences in general. The key difference would be cookies are stored in client side and sessions are stored in server side. The second difference would be cookies can only store strings. We can store our objects in sessions. Storing objects in sessions were really useful according to my experience. Another difference was that we could be save cookie for future reference, but session couldn’t. When users close their browser, they also lost the session.
PHP Sessions
PHP has built-in functions to save session variables. The variables are stored in state files. These state files need not be explicitly created and managed. The following are the steps for saving and retrieving values of session variables.
The setcookie() command must be issued before any printed output occurs because the cookie must be written as part of the HTTP header. PHP automatically parses any HTTP_COOKIE string into an associative array $_COOKIE. The value of the cookie can be retrieved from the cookie thus:
$_COOKIE["some_var"]
Cookie: A key/value pair that is stored by the user's browser and is available in the superglobal $_COOKIE array available in PHP. The cookie request is initiated with an explicitly defined expiration date. For example:
setcookie('cookieName', $some_value, time()+3600, "/", ".example.com")
On the next server request, $_COOKIE['cookieName'] will be available. If you use a browser tool to look at the cookie, it will have an expiration date.
Session Cookie: Identical to the above but defined without an expiration date. If you use the same browser tool it will say that the cookie expires at the end of the session; which is ultimately when you close your browser. For example:
setcookie('cookieName', $some_value);
PHP Session: a server side mechanism that will associate a bunch of data with a session id. Every time a session is invoked, it serializes/unserializes it. This could be more data than just a single key/value pair that a cookie supports, but the way of associating this data with a user is by creating a cookie (regular or session as described above) in their browser that contains the session id. This way, the right data can be retrieved for a given user based on the value of that cookie.
Both are super global, i.e, they can be used anywhere in the site.
Differences between sessions and cookies:
Cookies are stored in the browser (client side) while sessions are stored in the server (host).
Cookies are remembered till they are deleted while sessions are deleted when the user closes the tab/browser (depending on the browser).
Cookies can be seen by the user while sessions cannot.
Due to the reasons above, I would recommend to not store sensitive data in cookies and store the data that is to be remembered even after the user has left in cookies.
Cookie - Stored data in browser and will work on browser related and client side only...For example if you are trying to log in gmail account with username and password,After entered login successful if you close the current tab and after sometime opening same page the login page won't come it will open directly with login details..This is cookie..
Session - Stored data in server side for example same as cookie example after entered login details you will get notification as successful once you close the browser then open after some time it will ask again login details(more example shopping also)
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 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.
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.