Dzięki. Nie zauważyłem, że generujesz go na podstawie Id. Wszystko jasne. Dzięki.

Co do zabezpieczenia przed SQL Injection znalazłem coś takiego

[PHP] pobierz, plaintext 
<?php
 
	$arrArguments = array();
	$intArgumentIndex = 0;
 
	function parseArgument($arrMatches) {
		global $arrArguments, $intArgumentIndex;
 
		$strMatch = $arrMatches[0];
		$strArgument = @$arrArguments[$intArgumentIndex++];
		switch ($strMatch) {
			case '%d': return (int)$strArgument;
			case '%s': return '"'.
			  mysql_real_escape_string($strArgument).'"';
			case '%b': return (int)((bool)$strArgument);
		}	
	}
 
	function SQL($strSql) {
		global $arrArguments, $intArgumentIndex;
 
		$arrArgs = func_get_args();
		array_shift($arrArgs);
		$arrArguments = $arrArgs;
		$intArgumentIndex = 0;
		return preg_replace_callback('/(%[dsb])/', 'parseArgument',
		  $strSql);	
	}
 
?>
[PHP] pobierz, plaintext 

Zastosowanie:

[SQL] pobierz, plaintext 
$sql = SQL('INSERT INTO users (id, uid, name, username, password, newsletter) 
VALUES (NULL, %d, %s, %s, %s, %B)', $_POST['uid'], $_POST['name'], 
$_POST['username'], md5($_POST['password']), $_POST['newsletter']); 
 
INSERT INTO users (id, uid, name, username, password, newsletter) 
VALUES (NULL, 1, "Łukasz \"anAKiN\" Lach", "anakin", 
"97296eca657a093aa379778c237e292d", 1)
[SQL] pobierz, plaintext 

Cały temat pod http://www.hacking.pl
oraz bardzo dobry przykład po angielsku ale kod każdy rozumie
http://www.unixwiz.net/techtips/sql-injection.html
a tu przykład błedów wysyłanych przez formularz
http://webcity.pl/webcity/porady.php/t/113

Dobrym też pomysłem są logi jeżeli było jakieś błędne zapytanie, dzięki temu można wyczaić co dany klient kombinuje, i powiedzmy przyblokować w imie dobra jego IP na jakiś czas ewentualnie login, wtedy niezrobimy krzywdy innym userom na tym samym ip.

Co do tego usówania to ja jeszcze weryfikuje IP, nazwe sesji, sumę kontrolną, i uprawniemia usera, pozatym nie jest dany wpis wywalany z bazy tylko deaktywowany powiedzmy jakieś pole w DB odpowiada za status, pużniej odpalam co jakiś czas skrypt który usówa wpisy starsze niż 30 dni z bazy danych w celu odciążenia serwera. Myślę że to w miarę bezpieczna metoda jeżeli chodzi o usówania damych z bazy. i jeszczcze na dodatek jak jest kilka osób które zarządzają serwisem.

Mam zapytanie, które jest brzydkie

[PHP] pobierz, plaintext 
<?php
$query = "DELETE FROM newsy WHERE id=".$_GET['id'];
?>
[PHP] pobierz, plaintext 

Czy jak zmienie w taki sposób:

[PHP] pobierz, plaintext 
<?php
$query = "DELETE FROM newsy WHERE id='".$_GET['id']."'";
?>
[PHP] pobierz, plaintext 

To będzie już ładne ?

a jak ktos ci w miejsce id zamiast powiedzmy 2, wpisze: 2' or 1=1 to usunie ci wszystko z tabeli.... byla mowa na poczatku tego topicu. jesli id to liczba, to rzutuj ja na liczbe: (int)$_GET['id']. jak nie liczba to slashuj

OK. Ale jak mam już zapytanie typu SELECT, np

[PHP] pobierz, plaintext 
<?php
$query = "SELECT * FROM newsy WHERE id=".$_GET['id'];
?>
[PHP] pobierz, plaintext 

To rozumiem, że chyba nic złego się nie może stać ?

W przypadku mysql za bardzo tak ci nic nie skasuja, gdyz mysql_query pozwala na wykonanie tylko jednego zapytania. ale w przypadku innych baz to moglbys sie zzdziwic.
Pozatym w mysql to ci moga wyciagnac inne dane niz w twoim warunku, wystarczy ze za id dadza: 2 or 1=1
i juz poznaja wszystkie rekordy a nie tylko o danym id.

Przyjmij wkoncu do wiadomosc. Dane nalezy filtrowac, niezaleznie od tego czy ktos moze zaszkodzic czy nie. Naucz sie wyrabiac w sobie dobre nawyki.
Cos ma byc intem: zrzutuj na int. Cos ma byc tekstem: przeslashuj to

żartujesz czy to jakaś prowokacja? w $_GET['id'] wpisuje OR 1=1 i po sprawie. wlasciwie mozna zrobic tu wszystko teraz. taki przyklad pojawia sie w kazdym kursie, artykule, ksiazce jako calkowity brazk zabezpieczenia.

a jesli bedzie cos takiego
http://index.php?site=del&id=2
i dopiszesz dalej
';%20$mysql_query%20=%20"%20DELETE%20%20FROM%20USERS";
chodzi o usuwanie to czy cos takiego ma szanse zadzialac

w przypadku jak id nie jest filtrowane

Czy Twoim zamierzeniem bylo zakonczenie jednej instrukcji php i wywolanie drugiej, w tym przypadku wywolanie ponownie mysql_query? Powodzenia życze.

Kurcze zrobiłem coś takiego:

[PHP] pobierz, plaintext 
<?php
$query  = ($_GET['id']=='') ? 'INSERT INTO formularze SET' : 'UPDATE formularze SET ';
$query .= " name = '".mysql_escape_string($_POST['name'])."', date='".$_POST['date']."' ";
if ($_GET['id']!='')
	$query .= ' WHERE id ='.(int)$_GET['id'];
 
$result = mysql_query($query) or die(mysql_error());
?>
[PHP] pobierz, plaintext 

Probelm jest chyba z mysql_escape_string
bo teraz po dodaniu tesktu z cudzysłowem i zapisaniu w bazie,
jak robie wyświetlanie wpisanych wartości to mam dodane slashe,
Co się w takim przypadku robi? Jest jakaś funkcja na to?

no musisz przed wyswietleniem uzyc stripslashes. jest to pewien feler...

Mozesz tez zapisywac do bazy przy pomocy htmlspecialchars z dyrektywa ENT_QUOTES. Zapiszesz wowczas encje i nie bedziesz mial \

używaj prepared statements to w wiekszosci przypadkow nie bedziesz musial sie sie przejmowaniem slashowaniem i odslashowaniem. niestety dostepne dopiero od mysqli i pdo

Apropo gier: http://sge.laventhar.pl/ Włamałem sie do niej pół roku temu poprzez błąd serwera, w kodzie php odnalazłem pliki *ini a tam hasło :-) i gra była moja.

przyznam szczerze, ze calego topica nie przeczytalem i moze sie juz pojawilo

jesli chcemy zrobic

[SQL] pobierz, plaintext 
SELECT pole FROM tabela WHERE id=$_GET['id']
[SQL] pobierz, plaintext 

to najlepiej jest nie przesylac zmiennej bezposrednio GETem, czy POSTem, lecz zrobic tak:

[PHP] pobierz, plaintext 
<?php
 
switch ($_GET['id'])
	{
	case 'a': $szukana=0;
	break;
	case 'b': $szukana=1;
	break;
	default : $szukana=666;
	}
 
$sql = "SELECT pole FROM tabela WHERE id =".$szukana.";";
?>
[PHP] pobierz, plaintext 

w ten sposob nikt nie jest w stanie pod nasza zmienna podpiac "zlych" warunkow do sqla, bo jesli wpisze cokolwiek innego niz a lub b, to $szukana bedzie defaultowa


p.s. co zrobic, zeby forum nie wstawialo mi \ przed "?

@Vexator z calym szacunkiem, ale przeczytaj jednak ten topic caly, albo przynajmniej strone na ktorej napisales tego posta...
Przeciez ty dales warunek na ID, w bazie mam powiedzmy 1000 rekordow i co, mam walić na kazdego case? Jak ty to sobie wyobrazasz? poroniony pomysl
skoro to ID to wystarczy zrzutowac na int: (int) $_GET['id']
i nikt ci nic nie wrzuci

Naklepsza ochroną jest stosowanie sesji z prawami dostepu. W swoich skryptach przed wyslaniem zapytanie do SQL spr czy user ma prawa dostepu, jezeli nie skrypt nie puszcza pasozyda.

@free ale jak to sie ma do topicu w ktorym uraczyles nas tym postem?
W jaki sposob sprawdzasz czy koles ma prawa? Na podstawie pewnie czy zalogowany, a zeby sie zalogowac to musi wpisac login i haslo i juz w tym momencie moze zrobic ci atak. No chyba ze sprawdzasz czy ma prawa do zalogowania sie

edit: a nawet jak ma prawa to moze chcacy lub niechcacy zrobic cos "źle"

Hmm, mam pytanie, stosuje mod_rewrite w ten sposób :

[HTML] pobierz, plaintext 
RewriteEngine on
RewriteRule ^$ /index.php
RewriteRule ^([0-9a-z]+)$ /$1/
RewriteRule ^([0-9a-z]+)/$ /index.php?p_zmienna=$1
 
RewriteRule ^([0-9a-z]+)/([0-9a-z]+)$ /$1/$2/
RewriteRule ^([0-9a-z]+)/([0-9a-z]+)/$ /index.php?p_zmienna=$1&d_zmienna=$2
[HTML] pobierz, plaintext 

Adres strony pojawia się w ten sposób : http://strona.net/wartosc1/wartosc2/
Jeśli w żadnym linku nie odwołam się do postaci http://strona.net/index.php?p_zmienna=wart...mienna=wartosc2 . To czy ewentualny atakujący będzię miał możliwość w jakikolwiek sposób zobaczyć nazwę tej zmiennej ? Bo jeśli nie będzie miał możliwości to przy wpisaniu http://strona.net/wartosc1 OR 1=1/ wyskoczy błąd serwera gdyż pusty znak nie jest uwzględniony w [0-9a-z] i SQL Injection się nie powiedzie. Czy się myle ?

Ja bronię się trochę inaczej:
robię zapytanie typu

[PHP] pobierz, plaintext 
<?php
$sql='SELECT id,login FROM baza WHERE haslo="'.md5($_POST['haslo']).'"';
$wynik=mysql_fetch_row($sql);
if ((mysql_num_rows($sql)==1) && ($wynik[1]==$_POST['login'])){
//Zalogowany
$_Session['id']=$wynik[0];
//Dalsze czynności....
}else{
//Jeszcze raz, bo nie udało się. Można ewentualnie wypisać, czy to zły login, czy 
też hasło....
}
?>
[PHP] pobierz, plaintext 

Funkcja haszująca MD5 gwarantuje, że treść wysłana w zapytaniu do bazy NIE będzie żadnym poleceniem. Jeżeli hasło istnieje (albo ktoś trafił na ciąg po haszowaniu dajacy jakiśtam rezultat, który jest w bazie), to sprawdzamy login z zapodanym wcześniej. Takie podejście od tyłu Najczęściej wykorzystywane jest pole [login] do takich zabaw jak SQL Injection. A w tym przypadku nie ma na to szans.

Proszę o ocenę pod względem bezpieczeństwa...

PS> Hasła w bazie są oczywiście shaszowane
PS2> w zmiennej $sql nie ma żadnych Backslashy (czyli [\])

Super - sprawdzasz tylko po haśle - więc zakladasz ze kazdy user MUSI miec inne haslo - zle - wybierz po loginie (ktory winien byc unikalny) i potem czy hash hasła = shaszowane wczesniej haslo z bazy.

@MatheW: Właśnie chodziło mi o to, żeby nie dopuścić do bazy danych zawartości $_POST['login']. Bezpieczne jest zhaszowane hasło

Racja, nie wpisałem ostatniej modyfikacji....

[PHP] pobierz, plaintext 
<?php
$sql='SELECT id,login FROM baza WHERE haslo="'.md5($_POST['haslo']).'"';
$wynik=mysql_query($sql);
if (mysql_num_rows($wynik)>=1){
  $ok=true;
  while (($dana=mysql_fetch_row($wynik))&&($ok==true)){
	if ($dana[1]==$_POST['login'])){
	  //Zalogowany
	  $ok=false;
	  $_Session['id']=$wynik[0];
	  //Dalsze czynności....
	}
  }
}else{
  //złe hasło
}
?>
[PHP] pobierz, plaintext 

Hasła mogą być takie same, ale różne loginy (sprawdzane przy rejestracji) jednoznacznie wskazują na dane konto.

To co zrobiłeś jest beznadziejne - pobierasz z bazy uzytkowników którzy mają takie same hasła! A takie same hasła moze miec paru userow. Wiec wynik moze zwrocic ich kilku - skad wiesz ktory to. W Twoim przpadku addslashes zupełnie wystarczy. Oczywiście przy rejestracji najlepiej zabron pewnych znakow w loginie, zeby nie sprawial trudnosci - najlepiej zostawic znaki alfanumeryczne, podkreslenia i spacje

MatheW: Przyjżałeś się? Ale tak naprawdę uważnie?
Piszesz:

a w kodzie jest:

[PHP] pobierz, plaintext 
<?php
if (mysql_num_rows($wynik)>=1){//jeżeli jest jakiś user (userzy) o takim haśle...
  $ok=true;  //ustaw zmienną pomocniczą 
  while (($dana=mysql_fetch_row($wynik))&&($ok==true)){// dekoduj wynik z bazy dopóki pomocnicza prawdziwa
	if ($dana[1]==$_POST['login'])){  //jeżeli jest taki login to...
	  //Zalogowany
	  $ok=false;  //skasuj pomocniczą
	  $_Session['id']=$wynik[0]; //ustaw sesję
 ...itd
?>
[PHP] pobierz, plaintext 

Czy wytłumaczyć dokładniej?
pozdrawiam

To jest bez sensu... a jeśli w bazie masz założymu 1 000 000 userów gdzie 10 000 na takie same hasło... Wtedy zalogowanie jednocześnie 1 000 userów, obciąży serwer. Po co tak robić?

Lepiej zrobić tak:
Login: [A-Za-Z0-9_-]
Hasło: tu już dowolnie i tak hasło trzymamy w bazie jako md5, wiec dodanie jakichkolwiek znaków ' " które mogłby by spowodować zmiane zapytania nic tu nie dadzą.

Po co sobie utrudniać życie i kombinować?

Witam,

Czytam wątek już drugi raz (pierwszy raz ok. 3 miesiące temu, kiedy php to było dla mnie jeszcze nowość) i dalej nie jestem pewien co do sposobu zabezpieczenia.


Do tej pory używałem ctype_digit() do liczb, oraz htmlspecialchars() do reszty.
Ogólnie to wolałbym używać zamiast htmlspecialchars() funkcję addslashes(), ale kilka postów zamieszczonym na tym forum skutecznie zniechęciło mnie do niej. A mianowicie teksty typu: "A ja podwójnie robię addslashes", jakieś wyrażenia regularne, cuda nie widy..

Czy istnieje możliwość na 'obejście' addslashes()? Tzn przekazać do zmiennej nie wyeskejpowany cudzysłów (podwójny czy pojedyńczy) ?


ps. addslashes() dlatego, że zauważyłem iż MySQL wykonuje swego rodzaju stripslashes() na przychodzących danych, więc oszczędza to miejsce i nie trzeba dekodować później danych z wartości html'owych.


I o co chodzi z tym poruszeniem na temat UNION?
Przeczytałem artykuł http://www.really-fine.com/SQL_union.html i mniej więcej wiem na czym to polega..
Jeśli wyeskejpuje zmiennę lub sprawdze czy są liczbowe, to powinienem być bezpieczny przed tym, racja?



Nie potrzebuję alternatyw do wspomnianych funkcji (czytać manuala potrafię ) , jedynie potwierdzenie od kogoś doświadczonego, czy addslashes() to 100% zabezpieczenie przed cudzysłowiami (nie SQL Injection).
Oczywiście, post Nospora polecający używanie addslashes() przy zmiennych tekstowych daje mi 99% pewności, iż to tylko moja paranoja, ale ten 1% to o 1% za dużo niepewności


Swoją drogą, czy składnia typu

[PHP] pobierz, plaintext 
<?php
"SELECT * FROM table WHERE cos = '".$_POST."'";
?>
[PHP] pobierz, plaintext 

[bez tych slashy..]
ma jakieś walory pod względem bezpieczeństwa? Używam ".$zmienna." tylko dlatego, że edytor mi wtedy ładnie koloruje taką składnie, ale kto wie, może to coś daje 'gratis'? Wydajność? Bezpieczeństwo?



Dzięki z góry za pomoc w tej sprawie,
Paziek.

http://pl.php.net/manual/pl/function.mysql-escape-string.php

Jarod: Dzięki ale nie dzięki ;o

Po pierwsze, cytujesz fragment postu i odpowiadasz na ten fragment (nawet jak by go wyjąć z kontekstu) czymś zupełnie innym :/ Zadatki na polityka tutaj widzę

Po drugie, tak jak napisałem, nie potrzebuje alternatywy do wspomnianych funkcji, ani gotowego rozwiązania na SQL Injection, koduje swoje aplikacje 'w miarę potrzeb' i potrafię posługiwać się manualem oraz goglami.
Przeczytałem już tyle artykułów oraz postów na forum, że wiem wystarczająco dużo na ten temat.



Chciałem się tylko dowiedzieć, czy istnieje jakiś bug, dziura, sposób, cokolwiek w funkcji addslashes(), który umożliwiłby wprowadzenie do zmiennej nie wyeskejpowanego cudzysłowia, bo nieco zwątpiłem w tą funkcję, zapewne nadinterpretacją kilku postów. To (prawie) wszystko.


Jakiś .. chakier się wypowie?

Tak, istnieje taki bug. Nazywa się on:

$slashedVar=str_replace('\"','"',addslashes($sourceVar));

Tylko to programista musiałby go popełnić.. Moim zdaniem, masz faktycznie paranoję


I na koniec: Jarod dobrze ci napisał - do escepowania zmiennych, które umieszczasz w zapytaniu SQL służy mysql_real_escape_string().

I na drugi koniec: ani addslashes() ani htmlspecialchars() nie służą do tego, do czego próbujesz je użyć (patrz punkt wyżej). htmlspecialchars() stosujesz w momencie wyświetlania treści na stronie, aby zabezpieczyć się przed złośliwym działaniem właśnie na poziomie przeglądarki (HTMLa) a nie bazy.

php5, pdo i podpinanie, a skończą się wam problemy z addslashes(), mysql_real_escape_string() i magic_quotes

Czy ktoś, kto się na tym zna może mi odpowiedzieć:

Jest tu wiele sprzecznych wypowiedzi

I czy "mysql_escape_string" w całkowicie wyklucza możliwość przeprowadzenia ataku SQL Injection, czy konieczne są jakieś modyfikacje zapytań (jak w pierwszym poście)? I proponuję administracji posprzątać temat, bo po przeczytaniu nic mi się kupy nie trzyma:P

Stosuję mysql_escape_string + filtrowanie danych i moim zdaniem jest to w zupełności bezpieczne.

A przy okazji jak filtrować na poziomie postgresql'a?

EDIT: @radex_p - bo nie znalazłem odpowiednika dla postgresql'a

skoro mysql_escape_string (nie licząc standardowych procedur filtrujących) jest good, to czemu nie użyć podobnej funkcji przeznaczonej dla postgre'a, lub PHP'owskiej wbudowanej?

są sytuacje kiedy da się ją obejśc, nie jest tajemnicą że najlepiej stosować tzw. prepared statements. więcej: http://ilia.ws/archives/103-mysql_real_esc...Statements.html

Witam.
Przeczytałem ten temat dwa razy. Dwa razy dostałem oczopląsu i palpitacji serca.
Temat niby jeden, ale skaczecie od wątku do wątku. Oszaleć można.
Postaram się w skrócie podsumować poprzednie wypowiedzi, zanim przejdę do swojego pytania,
jako że poprzednie podsumowania ułatwiły mi czytanie tego wątku.

1. Należy sprawdzać czy liczba jest liczbą, to znaczy że jeśli przesyłamy urlem id rekordu z tabeli musimy sprawdzić czy jest on liczbą.
2. Dodawanie ukośników przez addslashes() lub mysql_real_escape_string() w zmiennych typu string.
(Z tekstu tutaj wyczytałem że mysql_real_escape_string() robi to lepiej. Czy tak jest i dlaczego ?)
3. Ostatnim problemem z SQL-Injection jakiego zdołałem się tutaj doczytać jest słowo kluczowe SQL 'UNION'
dzięki któremu można pobrać więcej danych.

W mojej opinii nie należy trząść portkami przed UNION jeśli zamiast gwiazdki po SELECT wypisuje się nazwy pól które chce się pobrać z tabeli. Jeśli się mylę poprawcie mnie.

Moje pytanie(oprócz tego w punkcie drugim):
Chciałbym się dowiedzieć jak mam usunąć ze zmiennej wszystkie spacje nie tylko te z przodu i z tyłu - trim()
Mam z tym problem bo spacje można zapisać jeszcze w inny sposób niż ' ' a ja niestety na tych metodach zapisu się nie znam.

Poniżej przedstawiłem swoją metodę dodającą do łańcucha znaków wsteczne ukośniki.
Prosiłbym o jakieś komentarze czy jest ona bezpieczna i czy zamiast addslashes powinienem zastosować mysql_real_escape_string()

[PHP] pobierz, plaintext 
<?php
public function sanitize($input, $force=false)
	{
	  if(!get_magic_quotes_gpc() || $force == true)
	  {
		if(is_array($input))
		{
			  foreach($input as $key => $val)
			  {
				$input[$key] = addslashes($val);
			  }
		  return $input;
		} else {
		  return addslashes($input);
		}
	  } else {
		return $input;
	  }
	}
?>
[PHP] pobierz, plaintext 

Dziękuję za przeczytanie i odpowiedź na te moje wypociny

To zależy gdzie się jej użyje:

[PHP] pobierz, plaintext 
<?php
 
  // 1, zabezpieczone przed SQL injection
  $_GET['name'] = $this->sanitize( $_GET['name'] );
  mysql_query( "SELECT * FROM some_table WHERE name = '{$_GET['name']}'" );
 
 
  // 2, niezabezpieczone przed SQL injection
  $_GET['sort'] = $this->sanitize( $_GET['sort'] );
  mysql_query( "SELECT * FROM some_table ORDER BY {$_GET['sort']}" );
 
?>
[PHP] pobierz, plaintext 

A co do usuwania spacji to nie rozumiem problemu. Chodzi ci o to, że chcesz usunąć: ' ', ' ', '%20', itp? Tylko po co, skoro 2 i 3 przykład sam z siebie w spację się nie zamieni...
No ale zawsze możesz użyć str_replace" title="Zobacz w manualu PHP" target="_manual

Czyli nie ma się co zastanawiać tylko walnąć str_replace na ' '.
Ok dzięki.

Co do mysql_real_escape_string() to poniżej jest cytat z postu http://forum.php.pl/index.php?s=&showt...st&p=172835 calls MySQL's library function mysql_escape_string, which prepends backslashes to the following characters: NULL, \x00, \n, \r, \, ', " and \x1a.

addslashes() : Returns a string with backslashes before characters that need to be quoted in database queries etc. These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).

Też mam (niestety) podobne odczucia...


Tak. Warto użyć do tego wyrażenia regularnego takiego jak to:

Powyższe wyrażenie sprawdza jeszcze ilość cyfr - raczej mało kto będzie miał ponad miliard rekordów


mysql_real_escape_string() uwzględnia zestaw znaków używany podczas łączenia się z bazą danych, więc będzie też poprawnie działać jeżeli używasz np. Unicode.

Co do ukośników - z tego co się orientuję, to kilka lat temu MySQL był wyjątkiem i ich wymagał, a inne bazy danych z którymi miałem do czynienia (PostgreSQL, MS SQL, Oracle) akceptowały podwójny apostrof (dwa apostrofy obok siebie). Obecnie także MySQL je akceptuję. Ja tutaj zalecam używanie mysql_escape_string() (dla MySQL) i pg_escape_string() (dla PostgreSQL), ew. podobnych funkcji (jest to opisane w dokumentacji PHP).

Przed wywołaniem tych funkcji warto także sprawdzić czy string wpisany do formularza nie jest za długi, i go obciąć. Warto także wywołać trim() - raczej nie ma sensu przechowywać dodatkowych spacji, które i tak nie będą wyświetlone.

Przy UNION jest tylko ważne aby zgadzała się ilość kolumn i ich typy były zgodne, dlatego "SELECT *" przed niczym nie chroni. Dlatego np. takie zapytanie zadziała:



Użyj czegoś takiego:

To polecenie zamienia kilka spacji (i innych "białych" znaków) na jedną spację. Nie usuwa ono jednak całkowicie spacji z początku i końca - trzeba albo to wyrażenie poprawić, albo dodatkowo użyć trim(). Jeżeli chcesz natomiast wyciąć wszystkie spacje, usuń spację z drugiego parametru.

Ktoś wcześniej wspomniał też o mod_rewrite i .htaccess - można tego użyć jako dodatkowego mechanizmu zabezpieczeń, trzeba tylko pilnować aby nigdzie na stronach nie pojawił się rzeczywisty adres stron w serwisie. Poza tym warto także pamiętać że zawsze można próbować zgadnąć nazwy stron i nazwy parametrów.

Poza tym jest jeszcze kwestia znaku komentarza "--" w SQL, i tzw. ataki wielofazowe, ale o tym nie chce mi się drugi raz pisać - zerknijcie sobie tutaj: Ataki SQL Injection

tylko po co te regexpy?

Właśnie po co skoro istnieje filter_ input()" title="Zobacz w manualu PHP" target="_manual

Po to żeby ci z php4 też mieli bezpieczne formularze

1. ctype_digit
2. str_replace

?

z ctype_digit() trzeba ostrożnie, bo jeśli nie dostanie stringa tylko int np. 34 to zwróci false, do tego jeśli string jest puszty "" to zwraca true.
dlatego jak ktoś chce użyć do sprawdzania danch np. z GET to powinien użyć takiego złożenia

[PHP] pobierz, plaintext 
<?php
if ( !empty($_GET['id']) && ctype_digit($_GET['id']) ){
   //dobre id (string składa się z samych liczb)
}else{
   //Zły, pusty/zawiera inne znaki
}
?>
[PHP] pobierz, plaintext 

Postanowiłem przyłączyć się do dyskusji. Kiepski ze mnie teoretyk więc od razu podam moj sposób rozuminienia tego o czym piszecie...

[PHP] pobierz, plaintext 
<?php
//clasa t_panel
class t_panel
{
	var $item_id; //pole trzymajace numer wiersza tabeli
	var $user_name; //pole trzymajacy nazwe pobraną z tabeli mysql
 
	function t_panel() //konstruktor klasy
	{
		$this->item_id = $_GET["item_id"]; //pobieranie numeru przekazanego za pomocą _get
		if (!is_int($this->item_id) $this->item_id = 0; //ustawianie na 0 jesli nie jest liczba całk.
		$this->load_data_from_database();
	}
 
	function load_data_from_database()
	{
		$query ="SELECT * FROM moja_tabela WHERE id=".$this->item_id." LIMIT 1";
		$result = mysql_query ( $query ) or die ( _MYSQL_ERROR_.":".mysql_error());
		$row = mysql_fetch_array($result, MYSQL_ASSOC);
		$this->user_name = $row["nazwa_uzytkownika"];
	}
 
	function drop()
	{
		echo $this->user_name;
	}
}
?>
[PHP] pobierz, plaintext 

Czy ktoś będzie się mógł mi włamać przy takim kodzie?

Nie, zawsze będzie 0, ponieważ tu jest błąd:

[PHP] pobierz, plaintext 
<?php
$this->item_id = $_GET["item_id"]; //pobieranie numeru przekazanego za pomocą _get
if (!is_int($this->item_id) $this->item_id = 0;
?>
[PHP] pobierz, plaintext 

Zmienne z tablicy $_GET są zawsze typu string, więc musisz najpierw rzutować na int, bo:

Tyle się rozpisaliście na tym wątku, a jak ktoś (chyba słusznie) zauważył nie da sie praktycznie włamać do bazy MYSQL za pomocją SQL injection jeśli zmienne przekazywane metodą _GET są tylko i wyłącznie liczbami (a jak sądzę tak jest w większości przypadków.klk

Myślę też, że jeśli w przypadku przekazywania stringów zastosujemy funkcję real_escape_string() to włamanie SQLInjection będzie niemożliwe. Jeśli się myslę to prosze mnie skorygować bo w tym wątku czas na wniski.

Pozdrawiam.

[SQL] pobierz, plaintext 
SELECT * FROM tabelka WHERE id = $_GET['id'];
[SQL] pobierz, plaintext 

-> $_GET['id'] = 5 or 1=1

wynik =

[SQL] pobierz, plaintext 
SELECT * FROM tabelka WHERE id = 5 OR 1=1
[SQL] pobierz, plaintext 

efekt: pobranie wszystkich wpisów

że też ja na to nie wpadłem....

Sory, że dalej drążę temat ale nie chcę się obudzic z ręką w nocniku później...
Czy takie funkcje mnie ochronią przed SQL Injection? Czy powinienem do nich coś jeszcze dodać ?

[PHP] pobierz, plaintext 
<?php
function mysql_valid_number( $a_value )
{
	if ( !empty( $a_value ) && ctype_digit( $a_value ) ){
		return $a_value;
	}else{
		return 0;
	}
}
 
function mysql_valid_string( $a_value )
{
	return mysql_real_escape_string( $a_value );
}
 
$id = mysql_valid_number( $_GET["id"] );
$name = mysql_valid_string( $_GET["name"] );
$query_1 = "SELECT * FROM mytable WHERE id = ".$id."";
$query_2 = "SELECT * FROM mytable WHERE name = ".$name."";
?>
[PHP] pobierz, plaintext 

EDIT: poprawiony return dla mysql_valid_string;

w mysql_valid_string return by się przydał

Black-Berry, po co tak kombinować? Po prostu do intów zawsze używaj (int) a do stringów mysql_real_escape_string albo PDO i bindParamy

A wiesz co uzyskasz po takim czymś:

[PHP] pobierz, plaintext 
<?php
$strIn = '-2';
$intT = (int)$strIn;
var_dump($intT);
if( ctype_digit($strIn) ){
   echo "Tylko cyfry";
}else{
   echo "Nie tylko cyfry";
}
?>
[PHP] pobierz, plaintext 

A trzeba pilnować, ja coś ma być liczbą dodatnią niech nią będzie, bo potem gdzieś ktoś nie przewidzi, że może być ujemną i się posypie, a czasem jest tak że nie wywala błędu i trzeba szukać.
Aby jakiś algorytm działał poprawnie, muszą być spełnione wszystkie warunki początkowe.