Czy htmlspecialchars i mysql real escape string chroni mój kod PHP przed wstrzyknięciem?

Oprócz doskonałej odpowiedzi Cheekysoft:

• tak, zapewnią Ci bezpieczeństwo, ale tylko wtedy, gdy zostaną użyte całkowicie poprawnie. Użyj ich nieprawidłowo, a nadal będziesz podatny na ataki i możesz mieć inne problemy (na przykład uszkodzenie danych)
• Proszę zamiast tego używać zapytań sparametryzowanych(jak wspomniano powyżej). Można ich używać np. przez PDO lub przez owijarkę jak PEAR DB
• Upewnij się, że magic_quotes_gpc i magic_quotes_runtime są wyłączone przez cały czas i nigdy nie otrzymasz przypadkowo włączony, nawet na krótko. Są to wczesne i głęboko błędne próby programistów PHP, aby zapobiec problemom z bezpieczeństwem (które niszczy dane)

Tak naprawdę nie ma srebrnej kuli zapobiegającej wtryskiwaniu HTML( np. cross Site scripting), ale możesz być w stanie osiągnąć to łatwiej, jeśli używasz biblioteki lub systemu szablonów do wyprowadzania HTML. Przeczytaj dokumentację, aby dowiedzieć się, jak odpowiednio uciec od rzeczy.

W HTML, rzeczy MUSZĄ BYĆ uciekł inaczej w zależności od kontekstu. Jest to szczególnie prawdziwe w przypadku ciągów umieszczanych w Javascript.

Zdecydowanie zgodziłbym się z powyższymi postami, ale mam jeszcze jedną drobną rzecz do dodania w odpowiedzi Cheekysoft, konkretnie:

Jeśli chodzi o zapytania do bazy danych, zawsze staraj się używać przygotowanych zapytania parametryzowane. Mysqli i Biblioteki PDO wspierają to. To jest nieskończenie bezpieczniejsze niż używanie ucieczki funkcje takie jak mysql_real_escape_string.

Tak, mysql_real_escape_string jest skutecznie tylko ciąg uciekający funkcja. To nie jest magia kula. Wszystko, co zrobi, to ucieczka niebezpiecznego znaków, aby mogły być bezpieczny w użyciu w jednym łańcuchu zapytań. Jeśli jednak nie odkażasz swojego wejść wcześniej, wtedy będziesz podatny na ataki.

Wyobraź sobie następujący SQL:

$ wynik = " wybierz pola z tabeli WHERE id = ".mysql_real_escape_string($_POST['id']);

Powinieneś widzieć, że to podatny na wykorzystywanie. Wyobraź sobie id parametr zawierał wspólny atak wektor:

1 lub 1=1

Nie ma tam ryzykownych chars do kodować, więc przejdzie prosto przez filtr uciekający. Zostawić us:

SELECT fields FROM table WHERE id = 1 OR 1=1

Zakodowałem małą, szybką funkcję, którą umieściłem w mojej klasie bazy danych, która usunie wszystko, co nie jest liczbą. Używa preg_replace, więc jest trochę bardziej Zoptymalizowana funkcja, ale działa w szczypta...

function Numbers($input) {
  $input = preg_replace("/[^0-9]/","", $input);
  if($input == '') $input = 0;
  return $input;
}

Więc zamiast używać

$ wynik = " SELECT fields FROM table WHERE id =".mysqlrealescapestring("1 OR 1=1");

Użyłbym

$ wynik = " SELECT fields FROM table WHERE id =".Numbers("1 OR 1=1");

I bezpiecznie uruchomi zapytanie

SELECT fields FROM table WHERE id = 111

Jasne, że po prostu powstrzymało to wyświetlanie poprawnego wiersza, ale nie sądzę, że jest to duży problem dla kto próbuje wprowadzić sql do twojej strony;)

Ważnym elementem tej układanki są konteksty. Ktoś wysyła "1 lub 1=1" jako ID nie jest problemem, jeśli cytujesz każdy argument w zapytaniu:

SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"

Co daje:

SELECT fields FROM table WHERE id='1 OR 1=1'

$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];

Działa dobrze, nawet lepiej na systemach 64 bitowych. Uważaj na ograniczenia systemów dotyczące adresowania dużych liczb, ale w przypadku identyfikatorów baz danych działa to świetnie w 99% przypadków.

Powinieneś używać jednej funkcji/metody do czyszczenia swoich wartości, jak również. Nawet jeśli ta funkcja jest tylko opakowaniem dla mysql_real_escape_string (). Dlaczego? Ponieważ pewnego dnia, gdy zostanie znaleziony exploit do preferowanej metody czyszczenia danych, musisz go zaktualizować tylko w jednym miejscu, a nie w całym systemie znajdź i wymień.

Dlaczego, och, dlaczego, nie zawierać cudzysłowy wokół wejścia użytkownika w instrukcji sql? wydaje się całkiem głupie nie! włączenie cudzysłowów w poleceniu sql uczyniłoby "1 lub 1=1" bezowocną próbą, prawda?

Więc teraz, powiesz, " co jeśli użytkownik zawiera cytat (lub podwójne cudzysłowy) w wejściu?"

Cóż, Łatwa poprawka: po prostu usuń cudzysłowy wprowadzone przez użytkownika. eg: input =~ s/'//g;. wydaje mi się, że wejście użytkownika byłoby zabezpieczone...