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.
Related
I have built up a login on my website where I set a $_SESSION['user'] variable if the login was successful.
Now I protect all the content for logged in users by
if(!isset($_SESSION['user'])) {
header('Location: login.php');
}
This means that if there hasn't been a successful login, you directly come back to the login page.
Now my question: Is this secure? Couldn't a $_SESSION['user'] variable have been set by another website?
This is correct. This is the way generally used by most websites using PHP.
The $_SESSION is a super global variable that is only managed by your server.
What happens:
You call session_start()
A cookie named PHPSESSID (or anything that you name it in php.ini) with a cryptographically secure value will be generated.
PHP declares a variable called $_SESSION, which is internally stored with association to the generated cookie value.
Why it cannot be changed by other websites:
The value of $_SESSION is only stored internally. Not even the client knows its value. It only holds a cookie for session ID, but it doesn't even know what that session ID means, nor what other people's session ID should be.
This session ID cookie cannot be stolen or modified by other websites. By default, the cookie path is set to your own domain, and the client should only send it to you. (If the client wants to send to other websites, it's leaking its own credentials and it is none of your responsibility but the bug of the client browser)
Unless you are running other websites on the same server, this won't be a problem (under normal circumstances).
As a side note, please be reminded that you should add a return; statement after using header("Location: index.php");. This is a common source of bugs, and in this context, it may expose your server to danger, because even though your browser won't display the content after it received the Location header, your server is actually still sending the data that should be generated for the user as if he has logged in.
TL;DR: if you have a script that should not send any data if client is not logged in, not adding the return; statement after header("Location: ..."); will make the server still send the data, but normal browsers will not display it (because it redirects), but if there is someone who tries to view the data sent (using methods as simple as curl without adding the -L option) will easily see them.
What you have done so far is fine and seems not vulnerable, and no attacker setting session variable from other site doesnt effect yours, but take care how you handle session once a session is created. Also generate random session tokens on each login and also change session tokens when passwords are changed.
In general a session itself can be considered safe. The problem is that is possible to steal a session allowing a hacker to have total access to whatever is in that session.
Since PHP stores the session ID as a cookie, a hacker can steal the session simply by using XSS.
Maybe have a look here for further information: Is this a safe use of Session Variables?
You're not likely to face this problem unless there's another login page on the same server. Say, login of admin and front end users.
If you want to strengthen your session and other security components, you could refer to this:
PHP Session Security
No.
Your website creates an unique hash and file on the server machine for the session and the hash is stored in the users browser as a cookie so when it hits your webserver, it could know which file exactly to read.
If any other website sets the same key to the $_SESSION variable it will be only for its hash, which your server wont read.
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
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'm new to PHP, I've read a lot of tutorials about cookies and sessions but I don't understand some things clearly:
The session values are stored on the server, only the session id is stored in the users computer. Right?
Can I make a session that never expires, that is never deleted from the server and to save the session id in a cookie ? If yes than how ? (please provide me some code)
It`s not good to store data like passwords in cookies because cookies are not secure ? Right ?
It`s possible for a hacker to create a cookie with a session id of an another user ? Can a hacker guess the session id of a session or worst, the list with each session id ?
For a good login system (used for forums or websites where the user have some data) that can remember an user is better to use cookies, sessions or a combination of both with session id stored in cookies ?
Please provide me some code about how could I store the session id in a cookie and than how I can access a session if I know the session id
Thanks!
Let's see...
right
session that never expires ? Not quite a good idea :
your served would get filled with old, useless, sessions
Instead, you should store some data in a long-lasting cookie ; and use that cookie to re-create the session (auto-connecting the user, for example) when the user comes back later
cookies are not secure indeed : they are stored unencrypted, and go through the network unencrypted (unless you use HTTS).
If your hacker can get the session id of another user (by reading his cookies, typically), yes, he can access his session
I would use both : anyway, if using a session, you need a way to store its identifier.
storing the session id in a cookie ? PHP will do that for you, if configured properly ;-)
Yes, PHP sessions are stored on the server.
You don't want to do that. It's a waste of disk space.
No, it's not good because cookies are stored unencrypted and in plaintext and you should never send a plaintext password back to the user.
If he knows the session id then he might be able to take over a session (tieing sessions to the user's IP helps against that). That's one of the resons why XSS is a dangerous thing.
Use a session and store the userid in it. There's no need to use a separate cookie if you already have the sessionid cookie.
Use session_set_cookie_params() if you want to change the session cookie settings; e.g. to make it permanent.
When a low-privilege non-administrator user logs into my web app successfully, I am storing the following data in the $_SESSION array:
$_SESSION = array(
'user_id' => 2343, // whatever their user_id number is from the DB
'allow_admin' => false, // don't give them access to admin tools
'allow_edit' => false, // don't let them edit stuff
);
Is there any way that they could manipulate the $_SESSION array to give them Admin or Edit access, apart from somehow editing the session files in /tmp? (The above code is the only place where those items are added to $_SESSION)
The contents of the session are only visible and modifiable on the server side.
They could only be modified in an "unauthorized" way if your application or server contains some vulnerability.
You should also be aware of such things as session fixation attacks, where an attacker forces a particular session id onto an unsuspecting user, who when logs in and elevates that session's privileges, allowing an attacker to share that session.
One approach to mitigating these is to regenerate the session id whenever you change privilege levels of the session.
See also this question:
PHP Session Security
If you want to avoid javascript reading your cookies and man in the middle attacks, you need to use a server with https and set the session cookie to only be transported over https.
session.cookie_secure specifies whether cookies should only be sent over secure connections. Defaults to off. This setting was added in PHP 4.0.4. See also session_get_cookie_params() and session_set_cookie_params().
session.cookie_httponly Marks the cookie as accessible only through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. This setting can effectively help to reduce identity theft through XSS attacks (although it is not supported by all browsers).
To secure admin privileges better for someone leaving his computer unguarded for a few mins, you should have a timer on last (admin) login. If that time is more then x timeunits away, the user has to login again to use admin rights.
Shorter sessions are also more secure then longer ones.
Server
Sessions are stored on the server. A user could change session data if they have direct access to the directory where sessions are stored. A solution to this is to secure the directory. And make sure you don't have a hole in your php code where you allow the user_id to be set by a $_POST or $_GET.
Client
But on the client side manipulating sessions is possible by hijacking someones session_id. This will let the hijacker pose as that user. And send request on their behalf.
There is also Cross-Site Request Forgery. This is when a hacker tricks a user into sending requests for him. By making him click on a link for example. You could combat this with tokens. A token is a generated string that is put in the $_SESSION array and in every HTML form as a hidden field. When the user submits a form the values are checked against each other. And every time the user requests a new page the token changes. This way an attacker must try to predict the token, which is pretty hard depending on how you make the token.
The links will also show examples on these attacks.
If you don't provide such access in your script there isn't much users can do about that. So your session data should be pretty secure. The only thing user can do is to manipulate session cookie or session id passed in the URL but it's unlikely that he will find an existing session id of another user.
Not unless you've left a security hole somewhere (such as allowing users to add/change $_SESSION data somehow).
As far as i know, no, unless user guess your session id and replaces it in his cookies. You should add additional IP-check at least server-side to prevent this.