Check out the documentation for the procedural use of mysqli_real_escape_string() here: http://php.net/manual/en/mysqli.real-escape-string.php . This function requires two parameters - the first one is “A link identifier returned by mysqli_connect() or mysqli_init()”, and the second one is the string.
// Change
$review_date = mysqli_real_escape_string($_POST['review_date']);
// TO
$review_date = $mysqli->real_escape_string($_POST['review_date']);
// Or better yet since there is no reason to escape when using prepared statements
$review_date = $_POST['review_date'];
And for the second problem, count the number of ? place holder characters in your sql. Does passing 5 parameters to a sql with 4 place holders make sense?
And for crying out loud, enough with that leading comma nonsense. At least wait until you can write a simple sql statement before trying to look like hip.
And for crying out loud, enough with that leading comma nonsense. At least wait until you can write a simple sql statement before trying to look like hip.
And posted same time…
So are you saying because we’re using a prepared statement there is no benefit using
There is no benefit in using either of those. The first is pointless as it is for when you jumble the SQL and code together - which you don’t do when you use prepare statements.
The second introduces a security hole because you then can’t tell if $review_date is a valid date or anything at all. If you are not going to actually validate $_POST fields before moving them to a new field then don’t move them and just reference the $_POST throughout your code as a reminder that the value hasn’t been validated.
Yes you should - and only move the valid value to the new field.
Note that escape and htmlspecialchars are NOT validation functions - they are for specific escaping and convert your input to JUNK if you run them as input functions - they are output functions to be run just before the data is output to the particular destination the function is for and where the data cannot be kept separate from the code.
Validation functions check that the value is valid for what the particular field is allowed to contain. For example “rating” should presumably be a number (possibly between 0 and 5) in which case you’d validate it using:
$rat = FALSE;
if (!empty($_POST['rating'])) {
if(filter_var(($_POST['rating'], FILTER_VALIDATE_INT) === false) {
echo '<p>Rating must be a number</p>';
} else (if $_POST['rating'] < 0 || $_POST['rating'] > 5) {
echo '<p>Rating must be between 0 and 5 inclusive</p>';
} else $rat = $_POST['rating']; // only at this point do we copy as we now know it is valid
} else {
echo '<p>Please select your rating</p>';
}
// all references to $rat from here on are either valid or FALSE.
Yes - when you switch to using prepare calls the data and code no longer get jumbled together and so there is no need to escape the data to avoid it being interpreted as code.
You just need to validate that the content of the posted values are valid before doing anything at all with the values.
injection is only possible when the code and data are jumbled together. When you use prepare statements only the code goes in the prepare statement and the data is kept separate in bind or execute statements. As there is no data in the prepare statement and only the prepare statement contains code there is no way to inject anything into the code.
I thought $_GET and $_POST were mutely exclusive. A request can be either a GET or a POST
What is the method attribute of the form element.
If it is method = “post” then all your input data is in the $_POST array and if the method is get then all the data is in the $_GET array.
As a my 2c comment, why not use PDO instead of mysql.
PDO takes care of escaping the input values.
They are not - you use $_GET for retrieving data that is not expected to change and $_POST for data that is likely to change - and you can use both in the same call if you really want to (although there is seldom a situation where it makes sense to do so).
