This isolated example is invulnerable to injection.
But you should understand that protection against SQL injection does not just replace a character . And circumstances may differ from those that you currently take for granted. Thus, your code will become vulnerable in the long run due to significant shortcomings of this method :
- character replacement is only part of the formatting required
- this particular replacement can only be applied to strings, leaving the other parts completely unprotected.
- such a replacement is external to the execution of the request, meaning that it is subject to human error of any kind.
- such a replacement is an essentially separable measure, meaning that it can be moved too far from the actual execution of the request and ultimately be forgotten.
- this type of shielding is prone to attack encoding , which makes the solution too limited to use.
There is nothing wrong with replacing characters, but only if it is used as part of full formatting; applies to the right side of the request; and executed by the database driver, not the programmer; before doing.
The functions that you suggested in the comments are a good step, but still insufficient, being the subjects of the above disadvantages, which makes them prone to various types of human errors.
And SQL injection is not the only problem with this approach, it is also a usage error, since this function will either corrupt your data if used as an embodiment of late magic quotes or make your code bloated if it is used to format each variable directly in the code applications.
Such functions can only be used to process the placeholder, but, of course, not using the replace function homebrewed, but in the database API function.
source share