Prepared statements with Mysqli does not require validation of data entry?

Question

I was studying here about security in PHP & Mysqli, and I was left with a question: if I am using prepared statments, still need to validate data entry?

For example, I have a field in the form:

<input type='text' name='campo'>

In the archive script.php picked up this variable like this:

$campo = empty($POST['campo'] ? NULL : $POST['campo']; // isso até é 
//uma validação né (ou não?), mas pra efeitos de segurança em prevenção      
//de PHP injection e SQL injection não sei se é efetivo

In the output file use this variable, for example:

echo $campo;

Or:

if ($campo = 'sim') {
   return true;
   echo 'O campo é sim';
}

And at the end of the output file I call a file to record in the bank, using prepared statments, thus:

$sql = "INSERT INTO nometabela (campo) VALUES (?)";

$stmt = mysqli_prepare($mysqli, $sql);

mysqli_stmt_bind_param($stmt, 's', $campo);

mysqli_stmt_execute($stmt);
$stmt->close();
$mysqli->close();  

This way, as I understood it is impossible to SQL Injection, because it will only accept string characters, so there would be no way to include characters needed to change the query.

And let’s also say I use this field for some SELECT, there is some risk (even without SQL Injection)?

In this answer for example it is suggested to validate with preg_match, but from there I was in doubt whether with the prepared statmentsThis is no longer solved. Can the above code be considered safe? Is there something wrong? There’s something else I can do to ensure the integrity of the system?

Answer 1

Hazards

Risks are everywhere. For example, the code shown is assigning 'sim' for $campo. And having something printed that will never be printed out. It may seem silly to observe, but failures occur because of silly things like that.

So how shown in this question validation should occur with any data coming from source that you do not fully control in the application.

Of course, the information will only be used in one query this way the main validation is already made by the function used.

Invalid data

This does not prevent other invalid data from being used. Since it is entered then it is very likely that one wants to check whether the data are in proper state to enter the database, but in terms of security there will be no direct risks. There may be indirect ones, such as the person putting the password that they use in a field that can be accessed by anyone publicly, but of course this is more difficult to prevent if the person really wants to do it.

Remember that the information can be used for other things and there is the risk of your application becoming vulnerable. There is not only SQL injection. One of the most common errors is to let the user enter a file path freely.

Content injection

There is also the injection of content that has nothing to do with SQL. In web applications it is common to try to put as an innocent data an HTML/JS code. When this data is accessed by someone, this code will be inserted into the normal page of your application and will execute something on the client that was not your intention. This creates a security problem for your users. This is also your responsibility. It gets worse if this information is used on the server to generate something that will run.

Ddos

There is the denial-of-service attack that can be obtained by making the database work longer than it is waiting for. This can happen because the data has not been validated. And it is not always easy to find a balance between the data being valid or not in situations like this. Validating a data to avoid request robotization is important as well. Almost no web application is prepared for this. Almost all of them are done quite amateurishly. Luckily they are so irrelevant that they do not usually suffer these attacks.

Any attack is possible

I keep remembering other attacks, but if I don’t stop here the answer will continue to be edited and increased. Developing for web is much more complicated than people realize.

Completion

According to the answer linked in the question here, you must restrict the values accepted as much as possible. Not only because of the SQL Injection.

Don’t forget there might be one bug in the function that Prepared statement. It may be rare, but if you validated it earlier, it decreases the chances of an attack succeeding. I’m not saying to be so paranoid to suspect that everything might fail, but it’s something to reflect on.

And the first example is a validation, bad, but it is. It doesn’t help or disturb SQL Injection. And for me it makes a situation worse in most cases. In general it is better to have an empty field than a null one. But if you know what you’re doing, if you’re sure you’ll always be checked if the variable is null before you use it, okay. It’s not wrong, it’s just a matter of style.

Positive test X negative test

But overall one of the biggest mistakes people comment on is testing the application to see if it’s working. Tests are made to know if she is not working. And this is the most important thing. Testing all What can go wrong is fundamental. Most people don’t value this, and when they do, they don’t know everything that needs to be tested. And I doubt there’s anyone who knows everything that needs to be tested in complex applications. You just try to minimize to the maximum, not repeat the same mistakes, fix what was wrong so you find a new problem.