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.
If you are declaring a variable to
NULL
it is best to check again, and work in order to that return. Very good answer +1.– Edilson
Excellent answer! + 1 I’ll read a few more times, and then maybe ask for some punctual explanations... thanks for now!
– gustavox