Czy taka kombinacja zmiennej jest poprawna i zostanie zinterpretowana przez serwer poprawnie? Głównie chodzi o ochronę przed SQLInjection.

[PHP] pobierz, plaintext 
$nazwa_uz = addslashes((string)trim($_POST['nazwa_uz']));
[PHP] pobierz, plaintext 

Czy może powinno to wyglądać tak?

[PHP] pobierz, plaintext 
if(!get_magic_quotes_gpc()){
	$nazwa_uz = addslashes($nazwa_uz);
}
$nazwa_uz = (string)$_POST['nazwa_uz'];
$nazwa_uz = trim($_POST['nazwa_uz']);
[PHP] pobierz, plaintext 

Albo jeszcze inaczej wymyśliłem:

[PHP] pobierz, plaintext 
if(!get_magic_quotes_gpc()){
	$nazwa_uz = addslashes($_POST['nazwa_uz']);
	$nazwa_uz = addslashes($nazwa_uz);
	$nazwa_uz = (string)$_POST['nazwa_uz'];
	$nazwa_uz = (string)$nazwa_uz;
	$nazwa_uz = trim($_POST['nazwa_uz']);
	$nazwa_uz = trim($nazwa_uz);
}
else
{
	$nazwa_uz = (string)$_POST['nazwa_uz'];
	$nazwa_uz = trim($_POST['nazwa_uz']);
	$nazwa_uz = trim($nazwa_uz);
}
[PHP] pobierz, plaintext 

Czy to jest poprawne?

Nie, to nie jest poprawne. addslashes nie uchroni Cię przed SQL Injection. Rzutowanie stringa na string nie ma najmniejszego sensu.

Najlepiej zapoznaj się z wbudowaną biblioteką PDO, która pozwala na eleganckie budowanie bezpiecznych zapytań. Od biedy możesz używać np. mysql_real_escape_string, ale z całego serca polecam PDO.

Ta funkcja wystarczy? + rzutowanie int.

Używaj PDO zamiast się takimi przyziemnymi rzeczami przejmować. Samo (int) wystarczy. Nie trzeba dodawać już addslashes.

No, dobrze.Używam już PDO. Ale czy używając tej biblioteki, nie muszę już używać rzutowania typów, addslashe, escape string i tak dalej? Bo PDO zabezpieczy mniez gwarancją?

Zabezpieczy pod warunkiem, że z niego faktycznie korzystasz:

[PHP] pobierz, plaintext 
$stmt->bindParam(':id', $_GET['id'], PDO::PARAM_INT);
[PHP] pobierz, plaintext 

Zrezygnowałem z PDO, bo mnie dosłownie wkur... to, ze nie ma zaimplementowanych wielu funkcji z Mysqli.

Czy taki kod jest dobrze zabezpieczony? Niby kolega wyżej mówił, że addslashes nie potrzeba, przy int, no, ale... na wszelki wypadek:

[PHP] pobierz, plaintext 
$wynik = $lacz->query("select * from uzytkownicy where email='". $nazwa_uz_l ."' and haslo = '". $haslo_l ."' ");
 
	$nazwa_uz_l = $lacz->real_escape_string($nazwa_uz_l);
	$nazwa_uz_l = addcslashes($nazwa_uz_l, '%_');
	$nazwa_uz_l = addslashes($nazwa_uz_l);
	$nazwa_uz_l = (int)$nazwa_uz_l;
 
	$haslo_l = $lacz->real_escape_string($haslo_l);
	$haslo_l = addcslashes($haslo_l, '%_');
	$haslo_l = addslashes($haslo_l);
	$haslo_l = (int)$haslo_l;
[PHP] pobierz, plaintext 

Nie czepiać się kodowania md5/sha przy haśle To dla testu kod.


I jeszcze jedno pytanie. Jak zabezpieczyć pusty VALUE id_uz

[PHP] pobierz, plaintext 
VALUES (''
[PHP] pobierz, plaintext 

w:

[PHP] pobierz, plaintext 
$wynik =  $lacz->query("INSERT INTO uzytkownicy (id_uz, haslo, email, pytanie_pomoc) VALUES ('','".$haslo."', '".$email."', '".$pytanie_pomoc."') ");
[PHP] pobierz, plaintext 

Wiersz w bazie w tym miejscu mam unsigned auto increment primary key int wiec wiecie dlaczego puste.

Sam sobie robisz krzywde, tylko dlatego ze przywykles do dwoch czy trzech funkcji, ktorych odpowiednikow nie potrafisz znalezc....

A do szkoly/pracy tez chodzisz z pontonem na wszelki wypadek powodzi?

Int to int, wystarczy ze zrobisz:
$zm = (int)$zm;

i juz.

Z twojego kodu wynika, ze haslo i email to inty? Ktos z nas czegos tu nie rozumie
Z twojego kodu wynika rowniez, ze dane zaczynasz zabezpieczac juz dawno po tym jak wykonales zapytanie, ktore korzysta z tych danych.... Nie sadzisz ze to odrobine za pozno?

A co ty tu chcesz zabezpieczac? Przeciez to ty wkladasz te wartosc. Jak bedziesz sam w kodzie wstawial wartosc 2, to tez bedziesz chcial ja zabezpieczac? Znowu na wszelki wypadek?

Poza tym dobrą praktyką jest wstawianie NULL a nie ''

No i czemu po real_escape_string robisz znowu addslashes?? Przeciez podwojnie zaczynasz slashowac wszystko..... Naprawde, im wiecej, nieznaczy lepiej... W tym wypadku znaczy gorzej.

No, nie rozumiem. I prosiłbym o szersze wyjaśnienia. Swoją drogą bardzo sięuśmiałem, czytając Twoją opinię Dzięki za mniej więcej uświadomienie mi błędu.
Mógłby ktoś wyjaśnić mi, jak się więc zabezpieczyć dokładnie? Dam real escape i addcslashes %_ bo real escape nie escapuje %_ i inta przed, tak?

Pozdrawiam, jestem nowy w php.
A i nie mogę znaleźć żadnej książki na temat obrony przed SQL injection, ani po rosyjsku, angielsku, niemeicku, no i polsku... W manualu niby cos tam mam o XSS i inject. o escapach i intach i addcslashach i htmlentitles czy tej drugiej funkcji, no ale i tak nikt tego do kupy nie pozbierał i nie wyjaśnił na konkretnych przykładach.

Nie trzeba zakładać 50 kondomów, jeden wystarczy.

[PHP] pobierz, plaintext 
$id=(int)$_GET['id'];
[PHP] pobierz, plaintext 

zostanie zawsze na liczbę zamieniony, co by w tym nie było. Jaśniej chyba nie można? Nie trzeba (do liczb) więcej "zabezpieczeń" jak to nazwałeś.
Do zmiennych zawierających tekst użyj tylko htmlspecialchars, więcej też Ci nie potrzeba.

Powinieneś PDO używać, nie potrafisz i twierdzisz, że Cię denerwuje. Jakich funkcji Ci brakuje?

Np. num_rows.

http://php.net/manual/en/pdostatement.rowcount.php

To moze napisz dokladnie czego nie zrozumiales z mojego posta, bo nie wierze ze nic. A jesli naprawde nie zrozumiales nic, to poprostu sie w ogole nie starales by zrozumiec....

Przeciez napisalem wyraznie ja, oraz wczesniej przedemna inni, ze liczb nie trzeba escapowac tylko rzutowac na int i juz. TU nie ma co wyjasniac ani robic nic wiecej "na wszelki wypadek". Liczba to liczba, ona nie ma nic do escapowania po zrzutowaniu na INT.

Napisalem ci rowniez, ze zabezpieczasz dane po tym, jak juz z nich skorzystales..... To tak jakbys slodzil herbate juz po tym, jak ją wypiles... Durne, nieprawdaz? Jak chesz miec slodką herbate to ją sie slodzi przed wypiciem a nie po. Identycznie z danymi do zapytania: je sie zabezpiecza przed wykonaniem zapytania a nie po. Naprawde tego nie rozumiesz i to też wymaga dodatkowych wyjasnien?

Escapowanie %_? Po co? Dodatkowo oprocz addcslashes robisz addslashes..... Toz ci napisalem, ze robisz to podwojnie, a przez to zle. Ma byc samo real_escape_string. Tu rowniez nie ma co tlumaczyc.


num_rows? Uzywam PDO od x lat i pewnie jestem dziwny, ale ani razu nie potrzebowalem num_rows, bo i po co? By sprawdzic czy uzytkownik z danym emailem i haslem istnieje? W tym celu poprostu pobieram rekord przy pomocy FETCH. Jak sie rekord pobierze, znaczy ze user istnieje, jak sie nie pobierze znaczy ze nie istnieje (pomijam przypadek bledu zapytnia by nie mieszac.)