Format of $_POST variables into prepared statement

PHP
1

HI,
this is probably a dumb question but if i am inserting data using mysqli and prepared statements do i need to do anything to the $_POST variables

eg

$name = $_POST['name'];
$stmt->bind_param("s",$name);

Or can i just do

$stmt->bind_param("s",$_POST['name']);

Every example i see uses an example that just has $something = ‘something’ so i haven’t seen an example using $_POST or $_GET etc.

I am guessing there is no problem either way but just wanted to check.

thanks

2

I see no difference between the two ways you posted, other than you would normally do some validation on the data before sending it to the database.

3

cool thanks. Yep got some validation stuff beforehand. I guess it might be neater to specify the top way, but then it also introduces more risk of error when copying between the variable and the bind. maybe i’ll do the lower as shorter amount of code and just put up with it looking (to my eyes) slightly more ugly.

thanks :slight_smile:

4

That said, I’ve read comments where people only ever use internal variables to post into queries, and never $_POST or $_GET on the basis that if they make a habit of not using the globals, they can never miss out the validation steps - if they miss those steps out, the internal variable will be blank.

5

ah that seems like it could be a good little additional fail safe. Might have a play and see how best to do it and keep it neat.

thanks

6

Your script is still open to injection. You should always filter you inputs, even before prepared statements:

filter_input(INPUT_POST, 'name');
7

AFAIK prepared statements “filter” for String and Int data types.
Those are good, but rarely enough by themselves.

8

That’s because you MOVE the data out of the $_POST or $_GET when you VALIDATE or SANITIZE it. That way you know that while $_POST and $_GET can contain anything at all (tainted) , all your other variables will contain values that are known to be acceptable values for those fields to contain (untainted).

While using bind eliminates the possibility of SQL injection by keeping the SQL and data separate, it doesn’t eliminate the possibility of filling the database with meaningless invalid junk.

These are things you should be doing in order to ensure that the data your script is processing are meaningful. Any security they provide is simply a side effect of what you need to have in place for the script to work.

9

Hi,
thanks for all the replies. Just to be sure …

Using prepared statements i am safe (as much as i can be) from SQL injection? yes?

From what i understand though if i don’t check the variables script could be inserted into the database which, whilst not affecting the sql on the way in, could do something if outputted? yes?

I am assuming there is no point doing mysqli_real_escape_string on the variables?

many thanks

10

It’s not just that script could be inserted, it’s that invalid data could go there too, which could cause you problems further down the line as you then try to use that data. For example if a user tries to enter an email address that isn’t in a valid format, it’s better to deal with that while they’re entering it than to accept it and have to deal with it every time you try to use that address.

11

Not a problem doing that already (could always do more/better though). So telephone numbers are numeric, email must contain @ and a . etc

Doing all this server side so they can’t bypass JS. Also using HTML5 form elements now so there is a double layer to minimize rubbish. So html5 email field with required gives a message before the form is submitted and then if it gets past that and is still malformed my validation throws it back and gives a message.

Hopefully will stop a lot of the rubbish getting through and will just have to evolve if i see anything getting around that.

thanks

12

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.