Този изолиран пример е неуязвим за инжектиране.
Но трябва да осъзнаете, че защитата от sql инжектиранене е просто замяна на символ . И обстоятелствата може да се различават от тези, които приемате в момента за даденост. Така вашият код ще стане уязвим в дългосрочен план, поради съществени недостатъци на този метод :
- замяната на символа е само част на необходимото форматиране
- тази конкретна замяна може да се приложи само към низове, оставяйки други части абсолютно незащитени.
- такава замяна е външна по отношение на изпълнението на заявка, означава, че е склонна към човешка грешка от всякакъв вид.
- такава замяна е по същество разглобяема мярка, означава, че може да бъде преместена твърде далеч от действителното изпълнение на заявката и в крайна сметка да бъде забравена.
- този вид избягване е предразположен към атака на кодиране , което прави разтвора твърде ограничен в употреба.
Няма нищо лошо в подмяната на символи сама по себе си, но само ако се използва като част от пълното форматиране; прилага се към дясната част на заявката; и се извършва от драйвер на база данни, а не от програмист; точно преди изпълнението.
Функциите, които предложихте в коментарите, са добра стъпка, но все още недостатъчни, тъй като са обект на изброените по-горе недостатъци, което ги прави податливи на всякакви човешки грешки.
И SQL инжекцията не е единственият проблем с този подход, това е и грешка в използваемостта, тъй като тази функция или би развалила данните ви, ако се използва като въплъщение на късно вълшебни цитати , или направете кода си раздут, ако се използва за форматиране на всяка променлива точно в кода на приложението.
Такива функции могат да се използват само за обработка на заместител , но разбира се не чрез използване на домашно приготвена функция за замяна, а правилна функция, предоставена от API на базата данни.
