Ten odosobniony przykład jest niewrażliwy na wstrzyknięcie.
Musisz jednak zdać sobie sprawę, że ochrona przed wstrzyknięciem sql nie jest tylko zamianą znaków . A okoliczności mogą różnić się od tych, które w tej chwili uważasz za oczywiste. Tak więc Twój kod stałby się narażony na dłuższą metę, z powodu podstawowych wad tej metody :
- zastępowanie znaków to tylko część wymaganego formatowania
- to konkretna zamiana może być zastosowana tylko do ciągów, pozostawiając inne części całkowicie niechronione.
- takie zastąpienie jest zewnętrzne w stosunku do wykonania zapytania, co oznacza, że jest podatne na wszelkiego rodzaju błędy ludzkie.
- takie zamiana jest zasadniczo odłączalną miarą, co oznacza, że może zostać przesunięta zbyt daleko od rzeczywistego wykonania zapytania i ostatecznie zapomniana.
- ten rodzaj ucieczki jest podatny na atak kodujący , przez co rozwiązanie jest zbyt ograniczone w użyciu.
Nie ma nic złego w zastępowaniu znaków per se, ale tylko wtedy, gdy jest używane jako część pełnego formatowania; zastosowane do właściwej części zapytania; i wykonywane przez sterownik bazy danych, a nie programistę; tuż przed wykonaniem.
Funkcje, które zaproponowałeś w komentarzach są dobrym krokiem, ale wciąż niewystarczającym, ponieważ są przedmiotem wymienionych powyżej wad, co czyni je podatnymi na wszelkiego rodzaju ludzkie błędy.
Wstrzyknięcie SQL nie jest jedynym problemem związanym z tym podejściem, jest to również błąd użyteczności, ponieważ ta funkcja albo zepsułaby twoje dane, gdyby była używana jako wcielenie późnego magiczne cytaty , lub rozdęty kod, jeśli jest używany do formatowania każdej zmiennej bezpośrednio w kodzie aplikacji.
Takie funkcje mogą być używane tylko do przetwarzania symbolu zastępczego , ale oczywiście nie za pomocą domowej funkcji zamiany, ale odpowiedniej funkcji dostarczanej przez API bazy danych.
