Ochrona przed wstrzyknięciem SQL

To nie o co chodzi w SQL Injection. Za każdym razem, gdy używasz parametrów, które nie zostały oczyszczone w zapytaniu SQL, pozostawiasz bazę danych otwartą na wstrzyknięcie SQL, co niekoniecznie musi mieć na celu zniszczenie danych. Może to być również kradzież danych lub uzyskanie nieautoryzowanego dostępu.

Rozważ bardzo ograniczone konto, na którym wszystko, co może zrobić, to SELECT . Piszesz zapytanie o uwierzytelnienie:

$sql = "SELECT COUNT(*) AS count
          FROM users 
         WHERE user_id='{$_POST['user']}' AND pass='{$_POST['password'}'";

// check if returns a count of 1, if yes, log in

Przy normalnych danych wejściowych oczekujesz, że zapytanie będzie wyglądać tak:

SELECT COUNT(*) AS count
  FROM users 
 WHERE user_id = 'username' AND pass='********'

Co powinno zwrócić 1 jako liczbę, jeśli zarówno nazwa użytkownika, jak i hasło pasują do siebie. Teraz atakujący próbuje zalogować się jako administrator. Ponieważ nie oczyściłeś danych wejściowych, wysyłają one $_POST['user'] jako:admin'; -- . Całe zapytanie staje się:

SELECT COUNT(*) AS count
  FROM users 
 WHERE user_id = 'admin'; -- AND pass='********'

Wszystko po -- jest komentarzem, więc ignoruje drugi warunek i zwraca 1 niezależnie. Proszę bardzo, właśnie przyznałeś dostęp administratora złośliwemu użytkownikowi. W ten sposób przeprowadzane są niektóre prawdziwe ataki. Zaczynasz z nisko uprzywilejowanym kontem i przez luki w zabezpieczeniach próbujesz uzyskać dostęp do większej liczby uprawnień.

Krótko mówiąc, posiadanie konta dla całej aplikacji z ograniczonymi uprawnieniami (np. bez DROP , ALTER itp.) jest dobry. Nigdy nie dawaj nikomu ani żadnej aplikacji więcej uprawnień, niż potrzebują. Ale aby zapobiec wstrzykiwaniu SQL, użyj przygotowanych instrukcji .