PDO nie jest obsługiwany w systemie docelowym, nad którym pracuję i chociaż szukam rozwiązania zapobiegającego wtryskiwaniu SQL przy użyciuPHP 5.1.x naPostGres-DB 8.2+. W tej chwili jestNie szansa przejścia na PDO.

Moje rozwiązanie w tej chwili to przygotowane przez pg_prepare oświadczenie:

// Trying to prevent SQL-Injection
$query = 'SELECT * FROM user WHERE login=$1 and password=md5($2)';
$result = pg_prepare($dbconn, "", $query);
$result = pg_execute($dbconn, "", array($_POST["user"], $_POST["password"]));
if (pg_num_rows($result) < 1) {
  die ("failure");
}

Ale pg_prepare-dokumentacji brakuje ważnych informacji:

mówi o „późniejszym użyciu”

pg_prepare () tworzy przygotowaną instrukcję do późniejszego wykonania za pomocą pg_execute () lub pg_send_execute (). [...]

mówi o „nazwanych / anonimowych oświadczeniach”

Funkcja tworzy przygotowaną instrukcję o nazwie stmtname z łańcucha zapytania, która musi zawierać pojedyncze polecenie SQL. stmtname może być „”, aby utworzyć bezimienną instrukcję, w którym to przypadku wszelkie istniejące wcześniej nienazwane instrukcje są automatycznie zastępowane; [...]

mówi o „typowaniu”

Przygotowane instrukcje do użycia z pg_prepare () można również utworzyć, wykonując instrukcje SQL PREPARE. (Ale pg_prepare () jest bardziej elastyczny, ponieważ nie wymaga wcześniej określonych typów parametrów.) Ponadto, chociaż nie ma funkcji PHP do usuwania przygotowanej instrukcji, do tego celu można użyć instrukcji SQL DEALLOCATE.

ale nie mówi, czy ta implementacja przygotowanych instrukcji jest bezpieczna przed wstrzykiwaniem SQL

* Niemal wszystkie komentarze z tego pytania bezpieczeństwa odnoszą się do rozwiązania PDO, gdzie w dokumentacji zauważono, że sterownik uniemożliwia wstrzyknięcie SQL. Ale jeśli łatwym rozwiązaniem może być pg_prepare, używałbym pg_prepare w tej chwili. *

Dziękuję za tę ważną informację, być może najlepsze rozwiązanie.

EDYCJA (po oznaczeniu jako rozwiązanie): Dzięki za bardzo pouczające odpowiedzi!

Oznaczyłem rozwiązanie Franka Heikensa najlepszą odpowiedzią, ponieważ wyjaśnia to ważny punkt w iniekcji SQL. Programista może korzystać z przygotowanych statystyk, ale brak wtrysku SQL może nadal być tam omyłkowo!Oprócz odpowiedzi Franka Heikensa, hoppa pokazuje, że wstrzykiwaniu SQL zapobiega się za pomocą pg_prepare / pg_query_params. W każdym razie dzięki.Teraz użyje zoptymalizowanego kodu zpg_query_params (dzięki Milenowi A. Radevowi)Ipg_escape_string() jako alternatywa jeśli chodzi o (dzięki halfer)

Wszystkie odpowiedzi są pomocne :)

// Trying to prevent SQL-Injection (**updated**)
$sql_query = 'SELECT * FROM user WHERE login=$1 and password=md5($2);';
$result = pg_query_params($dbconn_login, $sql_query, array($_POST["user"], $_POST["password"]));
if (pg_num_rows($result) < 1) {
  die('failure');
}