i have a login form, which is in login.php. after authorization i moove client to some.php file! so, from following two methods, which is better?
i can send information aboud user id e.t.c by GET
i can use SESSION - s for this
what is more preferred?
and two words about why i ask this question.
i hear somewhere that SESSIONs aren't good programing method, and it's not suggested to use them in such situations...
thanks
Sessions are indeed the preferred solution. You can't trust data sent in the querystring ($_GET, $_POST, $_COOKIE etc) because all of those can be changed by the user, but you can trust the that noone has tampered with the $_SESSION data since $_SESSION is stored on the server.
There's nothing inherently bad about sessions. In fact, in this situation I would store the userid in the session rather than passing it around in the URL. It'll be much cleaner, and more professional, IMHO. Storing trivial information in the session is fine.
$_SESSION might have its flaws, but using $_GET for this kind of thing is even worse.
If I understand the question right, then none. Use POST for this instead and then create SESSION upon logging in.
Let's say user comes to index.php where is login form. He fills in info and push "login". You send the data to login.php using POST. If the user name, password and whatever other information is correct, you create SESSION and redirect user somewhere else.
I would use SESSION if you want to store some information, that is based on the authentication success. Data in GET, POST variables is too easy to manipulate.
If you have to decide between $_SESSION and $_GET, then, for secure stuff, use $_SESSION. All the user can do with sessions is destroy them (by deleting the PHPSESSID cookie), but the user cannot manipulate them.
If you have to pass information once, $_SESSION is very good. You can store some data into the $_SESSION variable, change location via PHP (so the user cannot block the script by means of disabling JavaScript. Just use header('Location: '.$path);), use the $_SESSION content on the other page and the user does not have a time interval when he could destroy the session. This is safe.
The safest way would be to use SESSIONS because that would mean that only a token|identifier is stored on the client side, and all of the data represented by the token|identifier is stored on the server. Besides you can set expiry time for sessions too, that would make it more secure.
SESSION is the best solution . Which makes more secure one .User cant alter any of his data
Related
I've got a register form which works without issues, but recently it has been pointed out to me that it's a bad habit for UX , for example, if an account already exists, and I redirect the user back to the registration page, without re-populating the form he filled and only display an error message.
So I quickly figured out a nice way to fix this, if after the initial registration data checks out and an account with the respective e-mail already exists, I could just create a $_SESSION storing the $_POST data, and destroy it after re-populating the user's form.
Now my question is: are $_SESSION variables vulnerable to any type of attack, or I can go ahead and store the raw input data inside the $_SESSION, and escape it with htmlspecialchars() when re-populating the form ?
Variables in session are not vulnerable to attacks within the session. However, using those variables in other places may open up holes. For example, just because you put a get/post variable in session doesn't mean that it magically can be used directly in a query. It could still cause SQL injection issues. When considering stuff like this, you have to think about where the data originated. If it started from some sort of user input, consider it dirty.
The only place this might be a problem is if the data sent is really large and you are just blindly assigning $_SESSION['POST'] = $_POST;. There shouldn't be an issue with overflow or stuff like that. The problem will be more that php has to unserialize the data at the start of a request and reserialize at the end (typically only if a change has happened). This unserialize/serialize takes time (it may be quick, but still). I would suggest just assigning only the values you want to save.
It is hard to say exactly. But I am about 100% sure the answer is no they aren't really vulnerable. That is assuming that you can destroy the session almost immediately. In this case you would create the session, redirect the user back to the old page, check for session vars, set the vars in the correct location (which you could just do with plain text in this case) and then destroy session. The session would only be alive for about 10seconds.. a minute max? and noone would really have enough time to pull from the server. If they are listening to traffic already you are in more trouble this.
Had to move to answer because that was too long...
You may be able to do a check for user name with ajax BEFORE they ever submit however. That would be better. Don't allow them to submit if the email is already existent. Just submit based off keyup or something.
No, session variables are stored on the server through a variety of options such as saved to disk, shared through a redis or memcached store, and so on.
Even if this data were to be compromised I don't really see how sanitation would protect anything or mitigate the negative effects of such an attack.
If you really are worried about such a thing, you can destroy the temp session variable after you're done using it.
I have a quite simple question, which I'm asking because I'm unsure of the answer. I'm building an application where there is a multistep registration form. There are 7 steps and each one is on a different PHP page. I'm also validating the submitted form data once the client goes to the next page.
My questions is:
Is it secure to store all the Validated(only the validated) information in a Session variable and when they've finished with the registration, I'd write those session values into the Database. Is it secure to use sessions for this purpose? If not, how can this method be exploited?
I am also providing the option for people to go back to each step and change the values if they've mistyped something. In this case I would update the Session variables only. Is it safe too?
I'm currently using session_regenerate_id() to prevent Session stealing.
So basically will I be safe to store the data in Sessions temporarily, and then insert them to the database? Can a hacker change that Session data in the meantime, so what I'll insert into the DB will not be the same what I've saved into the session?
I hope you understand my question. Any help would be appriciated!
Yes, it is secure. Session data is stored on the server side, and cannot be manipulated by the client. The only thing the client holds is a session key, which allows the server to match a client up with the stored session vars for that client. As long as you're validating the information before storing them into $_SESSION, you can dump the session variables into the database at the end of the process.
Here is more information on sessions and security. The simple solution to any concerns with session stealing is to just use SSL.
I am also providing the option for people to go back to each step and change the values if they've mistyped something. In this case I would update the Session variables only. Is it safe too?
You will also be fine with this approach, again as long as you're re-validating the session variables.
if you protecting session ids for session stealing then go ahead, sessions are safe variables stored in server-side , every client has own session so if you sure to keep safe your session ids then no problem
I am using PHP $_SESSION variables with the login workflow of my website and I just wanted to make some clarifications. Much like Facebook, I want to store a secret code only known by the server which is used to sign each request that is sent to and from the server. My initial approach was to generate a random string and store that inside of a MySQL table, but then I learned about session variables. I know that session variables by default work by using cookies that store session names and id, correct? None of the actual data is stored on the user's computer? So if I wanted to implement:
# assume that $rand_string is not null and a string
session_start();
$_SESSION['secret'] = $rand_string;
there would not be any way for the user to decode the session cookies and determine the actual value of $rand_string, right? Just want to make sure the data is secure, otherwise I will revert back to the less smooth MySQL technique. I just like the thought of the easily accessed and managed session variables.
Session data is stored server-side.
Cookie data is stored client-side.
I would prefer doing the random stuff by generating a guid` function, because it will generate a unique identifier and will be more secure than a simple random:
# assume that $rand_string is not null and a string
session_start();
$_SESSION['secret'] = com_create_guid();
And yes, $_SESSION variables are stored on server side.
Yes, you are right, the user only knows about the session ID or something similar, just something to identify the session the user corresponds to.
The rest of the data is temporarily stored on the server.
There is no way for the visitor to get hands on the session data unless you have major bugs on your website which i don´t think you do.
What you say is correct. All data inside $_SESSION is accessible only on the server, but only as long as the session has not timed out.
Nonetheless you should be careful that session IDs which are stored in the cookie can be captured quite easily. See Sessions and Security for details.
I need a way to pass a variable between two page in a secure way.
I know that I can use POST / GET / Cookie / Session or hidden fields but I think none of these ways aren't secure enough because :
get can be seen in the url
cookies is a client side so it can be change from client
session can confront Session ID hijacking and ...
Now I want to know is there another ways better than these ways and if there isn't witch of these is the best way to pass variables in secure manner;
Session is the most secure method you have available.
Session id regeneration will help against session hijacking, but SSL via https will really protect against it.
BTW: If the session is hijacked and you're displaying user data to the client, it doesn't matter how you got the data to the second page, the hijacker will see it. If you're only using it server side, the hijacker won't see it.
Passing variable values between pages using session is most secure
and Regenerate the session id by session_regenerate_id whenever the security level changes (such as logging in). You can even regenerate the session id every request if you wish.
Good Read
PHP Security Guide: Sessions
since session is server side, its the most secure way to pass the variables
and to prevent session hijacking you can use session_regenerate_id function in php
the manual: http://php.net/manual/en/function.session-regenerate-id.php
but that doesn't means you always use sessions to pass variables
you still can use cookies, but encrypt the data before storing them in the cookies.
There is nothing wrong with using GET - as long as they are sanitised correctly... you can always combine get with a hash of the parameters to reduce the risk of it being tampered with, along with use of sessions to ensure they are also legitimate.
I currently use PHP sessions (without database saving) to identify users on a small website. However, I would like to make it more secure by saving session data to a MySQL database along with using a cookie with PHP.
I'm thinking of having a PHP script which I will include on every page which will:
Try to validate a session based on a database entry
Create a session if needed
Set special session variables I might need
Is this the best way to go about things? Am I missing anything in my script?
Session automatically try to use cookies for session ID.
The common practice is to store everything important into $_SESSION on login (and check only for privileges change).
If you want to make it more secure you may store $_SERVER['REMOTE_ADDR'] and $_SERVER['USER_AGENT'] into session and check them on each request.
The last thing I can think of right now is checking 'life time of session' manually.
Anyway I think that using https instead of http would bring you much more safety than reinventing sessions.
Storing each request/session into DB would make sense only if you needed to have special handling for parallel request.
That's a pretty big question. You want to do a bit of research on learning the tools I'll provide you for the job. I cannot write every detail about them here, but I'll try to get you pointed in the right direction.
check the user cookie to see if they have your session id variable set. if it isn't, start them a new session and offer a login perhaps.
if they have the cookie, check if it is a valid session id
if it is, load that session.
You'll need tools like setcookie, session_id(), $_SESSION, $_COOKIE. Making a users table is a whole other topic really.
I work with MVC's all the time that do just exactly what your referring to. Its a real piece of junk setting it up that way, but it can be useful in certain situations.
But the most important thing you should know is that when combining the login to an active session, it won't really make it more secure unless you use 2 session identifiers. is this what you want to do?
This would also be useful if you wanted to track where users log-in from. Gook luck!