I would like to save some POST data in my PHP session, like so.
$_SESSION['items'] = $_POST;
I plan on carrying this data through a couple more pages before saving it in the database. The type of data is text, so it can be anything, including SQL injection.
I will sanitize the data before saving it in my database, but only after it's been saved in the session for a little while.
My question is if saving UNsanitized raw POST data in the session presents a security concern, even if it will be sanitized later.
Thanks.
It's safe to store unsanitized user data in a session, so long as you sanitize it before you use it. The only exception to this I can think of is if you're using a database session handler that expects you to sanitize data before storing it in the session.
With that said, I would argue that there is a security concern here. PHP programmers are wired to look at $_POST and think unsafe. The same isn't true (or isn't as true) for $_SESSION. You, or someone working with your application, might at some point decide they need to do something with a session variable and assume it has already been sanitized.
In general, I think it is best to sanitize data as soon as you receive it.
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
The input originated from user input, but it's already been sanitized.
Better to be safe than sorry or just over-kill?
$_SESSION is basically the equivalent of your code making a text file for every user (identifying different users by magic, for explanation's sake), and storing some variables in that text file. Except for your code or something else on your server, nothing should be modifying the $_SESSION. So, if you make a habit of sanitizing everything before storing it in $_SESSION, you don't have to sanitize it again.
I have a site, where the username is stored in a session variable when they are logged in, I am wondering is it safe to make queries off of the value stored in this session variable?
yes, session are stored on server side.
instead of saving user name, you can save user id (int), so that it takes less space on
server. Remember that you should handle CSRF, and Session hijacking
Yes it is save. However, always escape any input that goes into a query (the best way is a bound parameter). Never trust any variable explicitly, especially if you can't see directly where it comes from (meaning unless you can scroll up and see $foo = 'bar';). So the better method is to just not trust everything, and you'll be safer in the end...
Sessions work by storing a session ID in a cookie sent to the user machine and storing all actual variables on the server. As such, your main worry is that the user will be able to find out the session ID of another user and pretend to be them; i.e., session hijacking.
Given that, you aren't really worried about SQL injections here as much, so you should be OK so far as making queries off the variables stored in the session. However, you should be worried that data can be viewed by someone other than the intended recipient. If you take precautions against hijacking, then you should be OK.
It depends.
If the pages in your site that are using the session are protected by encryption (HTTPS), then that mitigates the risk of session hijacking due to sniffing network traffic (the cookie containing the session id is protected.)
However, if you're on a shared host, the session file is typically stored in a central location and trusting unencrypted session data does entail some risk.
You could encrypt the session data, or you could develop a custom session storage as outlined in the link below:
Trick-Out Your Session Handler
But, no matter what you do or how much you trust your session data, you should use prepared statements or stored procedures to protect the integrity of your SQL statements, preventing SQL injection.
in fact, it's safe to use ANY variable in the SQL query, As long as you're following syntax and safety rules.
And data source has nothing to do here. No matter if it's session or a file, or an RPC request or POST data. All data is equal for the query and should be processed always the same way.
I know it's hard to understand but it's very important too, so, at least try it.
I'm creating a multi-step survey and want to store the data in $_SESSION before writing everything to a database. Is there anything I should be doing to the data before storing it there from a security perspective?
Assuming you're on the regular file-based sessions, then you don't have much to worry about from an injection vulnerability view. PHP will take care of the mechanics of read/writing the session file, using serialize() and the like. Stuff whatever you want into $_SESSION and it'll magically be there on the next page invocation.
However, from the broader security perspective, anything that goes into the session file IS readable by anything else running under the same web server instance (e.g. the apache user ID). So it's not somewhere you could store sensitive data, let along things like credit cart/cvv numbers.
well, to avoid problems recovering the data, i suggest you to use a name for the session and use an array exclusively for the post data, kinda:
$_SESSION['postData'] = $_POST;
Its fairly safe to throw whatever you want in the session without sanitizing it. You could though, since you're going to anyways, sanitize it before putting it in the session so its ready to go into the database, then you can sleep more soundly.