Forum PHP.pl

Pytania o streszczenie wątku, posty z "genialnymi" skryptami nadającymi się tylko na przedszkole i inne tego typu, będą bez ostrzeżenia usuwane przez moderatorów.
To mówiłem ja, Jarząbek... znaczy nospor dnia 2007-12-10
-------------------------------------------------------------------------------

SQL Injection (zwane też "SQL Insertion") to (rzekomo) najprostszy sposób włamu na stronę. Spowodowany jest on niepełnym sformułowaniem zapytań do MySQL.

Przykład. Dajemy na stronie możliwość edycji profilu. Zapytanie do SQL wygląda następująco:

[PHP] pobierz, plaintext 
<?php
$query = &#092;"update uzytkownicy set pole='$dane' where id='$id'\";
?>
[PHP] pobierz, plaintext 

Osoba włamująca się na stronę umieszcza całkiem prosty, odpowiedni ciąg znaków/poleceń w dowolnym polu edycji tego profilu, który wygląda np. tak (dla zmiany hasła użytkownika o dowolnie wybranym, przez atakującego numerze ID):

[PHP] pobierz, plaintext 
<?php
', haslo='nowe_haslo' WHERE id = '1
?>
[PHP] pobierz, plaintext 

W taki oto prosty sposób, osoba atakująca zmieniła hasło użytkownikowi o ID=1 (zazwyczaj administrator). W podobny sposób można również wyciągnąć dowolne dane z tabeli SQL.

W każdym razie. Poszperałem, pomyślałem i zebrałem wszystko do kupy. Zamieszczam to tutaj razem, oraz proszę o rozbudowanie tego topica, gdyż nie znalazłem na tym forum więcej informacji o "SQL Injection".

Oto co możemy dokonać:
1. Możemy sformułować nasze zapytanie do SQL tak:

[PHP] pobierz, plaintext 
<?php
$query = 'update `uzytkownicy` set `pole`=\"'.$dane.'\" where `id`=\"'.$id.'\";';
?>
[PHP] pobierz, plaintext 

2. Przy wstawianiu numerów ID do zapytań należy stosować tzw. rzutowanie typów:

[PHP] pobierz, plaintext 
<?php
$id = (int)$_GET['id'];
// lub
$id = intval($_GET['id']);
?>
[PHP] pobierz, plaintext 

3. Przy wstawianiu tekstów, należy wyciąć niebezpieczne znaki przy pomocy funkcji:

[PHP] pobierz, plaintext 
<?php
$string = mysql_real_escape_string($_POST['string']); // PHP5
 
$string = mysql_escape_string($_POST['string']); /* lub */ $string = addslashes($_POST['string']); // PHP4
?>
[PHP] pobierz, plaintext 

Może nie ma tego dużo, ale jest to już jakaś podstawa do zabezpieczenia strony/skryptu przed prostym i niezwykle niebezpiecznym, SQL Injection. Proszę osoby obeznane w tym temacie, aby dopisały tu własne propozycje metod zabezpieczenia się przed tym atakiem.

Ten post edytował Najki 14.02.2008, 10:04:12

punkt 1. twojego "zabezpieczenia" nie ma nic do rzeczy z rzeczywistym bezpieczeństwem przynajmniej wg mnie

punkt 2. ja stosuje po prostu addslashes() i filtruje dane z POST GET COOKIE itd. tzn jak ma byc liczba do liczba a nie string

stosujac gotowe skrypty ala phpbb itd. dopisuje zawsze w jakims glownym pliku
usuwanie s url-a wystapien wyrazow "<script>" i "UNION" co zabezpiecza przez script kiddie

Z tego co wiem to mysql nie wykonuje zapytan typu "zapyta1;zapyt2" od sstrony php wiec tego nei masz sie co bac... co do filtrowania danych...

mysql_escape_string" title="Zobacz w manualu PHP" target="_manual

Gdzieś znalazłem informację, że niby jednak to ma pomóc (głównie chodzi o średnik tam też o średnik na końcu zapytania)

Czy czasem $_POST, $_GET i $_COOKIE nie mają automatycznie dodawanych slash'y ?

Tak będzie OK? (nie znam się na wyrażeniach regularnych, a chciałbym, aby w tym topicu wszystko było jasno opisane, co by nikt problemów nie miał)

[PHP] pobierz, plaintext 
<?php
preg_replace( '%<script>%', '', $zmienna );
?>
[PHP] pobierz, plaintext 

zabezpieczenie w stylu:

[PHP] pobierz, plaintext 
<?php
$query = 'update `uzytkownicy` set `pole`=\"'.$dane.'\" where `id`=\"'.$id.'\";';
?>
[PHP] pobierz, plaintext 

to jak juz powiedziano zadne zabezpieczenie a pozatym zmnijsza wydajnosc zapytania, umieszczanie wartosci liczbowych w momiedzy " " powiduje iz MySQL mysli ze ma do czynienia ze znakami (stringami) i niepotzrebnie musi konwertowac typy.

Przylacze sie do tego co juz powiedziano, uzywac Zmiennych globalnych, i filtrowac wszystko, to co ma byc liczba to konwertowac na liczbe np:

[PHP] pobierz, plaintext 
<?php
$_GET['id'] = intval($_GET['id']);
?>
[PHP] pobierz, plaintext 

a to co ma byc stringiem dodawac slashe (addslashes).

Podstawowa zasada to nie ufac nikomu i spodziewac sie najgorszego!
budowac aplikacje tak by wytrzymaly wybuch nuklearny

w jednym ze swoich projektw zrobilem petle na foreach ktora z kazdego elemenu tablicy ($_GET, $_POST, $_COOKIE) zamieniala ewentualn wystapienia wyrazen takich jak "SELECT, UPDATE, INSERT, DELETE, WHERE AND" dodajac do nich np twarda spacje &nbsp; lub jakis inny znak co powodowalo ze ew. zapytanie bylo by z gory obarczone bledem.

coprawda rozwiazanie takie nie jest eleganckie bo wszystkie wystapienia tych wyrazeni byly zamieniane nawet jesli ktos nie mial zlych intencji ale sa one bardzo zadko uzywane w naszym slownictwie a dodanie np. twardej spacji praktycznie niczego nie zmienia w wygladzie takiego komentarza, posta etc.

nie rozumiem dlaczego wszyscy piszą o addslashes, przecież php automatycznie dodaje slashe do wszystkich zmiennych $_GET i $_POST i włamanie opisane przez Najki

[PHP] pobierz, plaintext 
<?php
', haslo='nowe_haslo' WHERE id = '1
[PHP] pobierz, plaintext 

nie ma prawa zadziałać.

Czy mógłby ktoś wyjaśnić mi tą sytuację?

Owszem dodaje, ale chyba tylko, gdy na serwerze jest włączone magic_quotes_gpc ?
A jeśli nie to jakim prawem kolega mi się włamał?

Dodam jeszcze te dwa linki:
http://www.nextgenss.com/papers/SecondOrderCodeInjection.pdf
http://hacking.pl/download.php?file=get&id=113

Temat ciekawy, ale w zasadzie nie wiem jeszcze co moglbym zrobic w swojej aplikacji aby uniemozliwic taki atak i aby bylo to zrobione w profesjonalny sposob. Gdyby ktos mogl zerknac na kod i pomoc mi.
Oto kod ktory sluzy do sprawdzenia hasla i nazwy usera:

[PHP] pobierz, plaintext 
<?php
 
// utworzenie krotkich nazw zmiennych i spr. czy dane sa przek. w zm. sesji
if (!isset($_SESSION['nazwa_uz']))
  $_SESSION['nazwa_uz'] = $HTTP_POST_VARS['nazwa_uz'];
if (!isset($_SESSION['haslo']))
  $_SESSION['haslo'] = $HTTP_POST_VARS['haslo'];
 
//spr. czy zostalo nadane nowe haslo
if (isset($_SESSION['nowe_haslo']))
	$_SESSION['haslo'] = $_SESSION['nowe_haslo'];
 
if (($_SESSION['nazwa_uz'] && $_SESSION['haslo']) || ($_SESSION['nazwa_uz'] == '' || $_SESSION['haslo'] == ''))
// proba logowania, sprawdzenie czy podano login oraz haslo
{
	if (loguj($_SESSION['nazwa_uz'], $_SESSION['haslo']))
	{
	  // jesli uzytkownik znajduje sie w bazie danych rejestracja identyfikatora
	  $HTTP_SESSION_VARS['prawid_uzyt'] = $_SESSION['nazwa_uz'];
 
 
	}
	else
 
?>
[PHP] pobierz, plaintext 

a to kod funkcji wykonujacej to sprawdzenie:

[PHP] pobierz, plaintext 
<?php
 
function loguj($nazwa_uz, $haslo)
// sprawdzenie nazwy uzytkownika i hasla w bazie danych
// jezeli sie �zgadza, zwraca true
// jezeli nie, zwraca false
{
  // polaczenie z baza danych
  $lacz = lacz_bd();
  if (!$lacz)
	return false;
 
  // sprawdzenie unikatowosci nazwy uzytkownika
  $wynik = mysql_query(&#092;"select * from uzytkownik 
						 where nazwa_uz='$nazwa_uz'
						 and haslo = password('$haslo')&#092;");
  if (!$wynik)
	 return false;
 
  if (mysql_num_rows($wynik) > 0)
	 return true;
  else 
	 return false;
}
 
?>
[PHP] pobierz, plaintext 

Chcialbym uniknac mozliwosci wlamania, poprzez wpisanie kodu SQL do pola haslo i uzytkownik:)

przyklad:

[PHP] pobierz, plaintext 
<?php
 
$sql = mysql_query(&#092;"SELECT * FROM news WHERE id=\".$_GET['id']);
 
?>
[PHP] pobierz, plaintext 

wywołanie normalne:


wywołanie zmodyfikowane przez kogostam
np.


zabezpieczenie? ja znalazlem pare...

1. dodanie id2

[PHP] pobierz, plaintext 
<?php
 
if(md5($_GET['id']*4)!=$_GET['id2'])die('Błędny url');
 
?>
[PHP] pobierz, plaintext 

2. wymuszenie typu

[PHP] pobierz, plaintext 
<?php
 
$id = (int)$_GET['id'];
 
?>
[PHP] pobierz, plaintext 

3. mysql_escape_string

[PHP] pobierz, plaintext 
<?php
 
$id = mysql_escape_string($_GET['id']);
 
?>
[PHP] pobierz, plaintext 

ale mam wrazenie ze to dalej nie o to biega... z tych 3 które przedstawilem to pierwsze wydaje mi sie być najrozsądniejsze...

osobiscie uwazam ze dosc dobrym rozwiazaniem jest odpowiednie zarządzanie uprawnieniami, np. stworzyc konto dla www, gdzie moga byc tylko SELECT, INSERT, UPDATE, ewentualnei DELETE

druga sprawa, czy probowales w praktyce wykonac przedstawione przez ciebie polecenie? standardowo (nie jestem pewny czy da sie to przestawic tak zeby bylo inaczej) przez mysql_querynie wykonasz dwóch zapytań

przez mysql_query() nie. ale funckje postgreSQL już to dopuszczają :/
Dlatego userzy tego drugiego mają większy problem.

Co do zabezpieczenia, nie wiem czym się tak przejmujecie? ;]
Ja stosuje jedynie addslashes() oraz usuwam slowo 'UNION' ze zmiennych

dość często jest WHERE coś = liczba gdzie coś jest polem auto_increment i ma wartości liczbowe.. wystarczy przed wykonaniem zapytania sprawdzić czy is_numeric parametr dla Where

Ja do liczb stosuje najczęściej ereg" title="Zobacz w manualu PHP" target="_manual (zwłaszcza w UPDATE, w grze MMORPG). Wtedy mam pewność że osoba która wpisze np -1230 nie wyrządzi mi żadnych szkód. A zabezpieczanie skryptów można trenować na wspomnianym przeze mnie wyżej ExoFusion. Jak ktoś go tak zabezpieczy, że nie będzie żadnych (no, może nie żadnych, a prawie żadnych) błędów to będzie się miał czym pochwalić (ja znałem 2 gry na 10 które były w miarę zabezpieczone, ale i tak padły - właśnie przez SQL Injection)

Hmmm.... wykonanie ereg zajmuje nieco czasu (jak to wyrażeń regularnych). Chyba jednak lepiej się nieco przyłożyć i pobawić kombinacją is_numeric(), is_integer(), intval() i warunkami. Chyba każdy wie jakiego mniej więcej zakresu się spodziewa? Jak nie chcesz liczb ujemnych to po porostu wycinasz je warunkiem i już…
Po co z armatą na muchy;-)

Pozdrawiam
Marcin Staniszczak

@MStaniszczak: podobnież "is_numeric(), is_integer(), intval()" nie są zawsze dobrym wyjściem. Gdzieś czytałem, iż Zend Engine działa tak, iż te funkcje sprawdzają tylko typ zmiennej. Może to doprowadzać do przekłamań, dlatego niektórzy właśnie stosują eregi (co w tamtym artykule także polecano).

@Vengeance:
Więc działa to tak:
is_numeric() - sprawdza czy cos co podałeś jako argument jest cyfrą. Dokładniej czy nie ważne czy cyfra jest stringiem ('123') czy cyfrą (123) czy cyfrą ułamkową (123.123). Jeśli jest cyfrą zwraca true;

is_integer() - zwraca true TYLKO wtedy gdy parametr:
a) jest cyfra
b) jest typu integer (czyli dla '123' nie zwróci true)
c) jest cyfrą CAŁKOWITĄ (czyli dla 123.123 nei zwróci true).
WSZYSTKIE te punkty muszą być spełnione jednocześnie

intval() - nic nie sprawdza... Zamienia parametr na integera (jesli zaczyna się od cyfry). Czyli:

[PHP] pobierz, plaintext 
<?php
$i = intval('123')
?>
[PHP] pobierz, plaintext 

powoduje przepisanie do $i wartości 123 typu INTEGER.

[PHP] pobierz, plaintext 
<?php
$i = intval('123 ala ma kota')
?>
[PHP] pobierz, plaintext 

działa podobnie - w $i otrzymujemy INTEGER-a o wartości 123.
Dodatkowo intval() ignoruje początkowe białe znaki i oczywiście poprawnie obsługuję znaki +/- przed cyfrą.
W przypadku niepoprawnego parametru podanego do intval:

[PHP] pobierz, plaintext 
<?php
$i = intval('ala ma kota');
?>
[PHP] pobierz, plaintext 

zwraca 0 (czyli w przykładzie $i otrzymuje wartość 0).

I NIE MA ODSTPSTW OD TYCH REGÓŁ.
Zamieszanie może powstać gdy się nie wie jak te funkcje działają (jest ich więcej - to tylko 3 z całej grupy). Ale to tak jak z operatorami...
Zobacz co da w wyniku:

[PHP] pobierz, plaintext 
<?php
$ret  = '123 ala'+'123ma kota';
echo $ret;
?>
[PHP] pobierz, plaintext 

Pozdrawiam
Marcin Staniszczak

Ten post edytował MStaniszczak 2.03.2005, 03:09:57

@MStaniszczak: ja tam nie wiem Mówie tylko co czytałem. Skoro ktoś to dostrzegł w kodzie Zend Engine (może go analizowałeś, ja nie) to miał jakieś powody by tak twierdzić Może już to poprawili albo coś. Przytaczam tylko swoją "wiedzę" na ten temat, choc sam także używam is_integer() itp.

@Vengeance: Ano analizowałem Zend Engina dość dokładnie (jeszcze raz mnie to czeka).
Oto funkcja odpowiedzialna za is_numeric (która nie jest częścią Zend Engine-u):



A to np. is_string:

do tego php_is_type:


A is_integer, is_double, is_real ma jeszcze ładniejszą postać (sam sprawdź). To nie może działać źle - używaj bez obaw;-)

Pozdrawiam
Marcin Staniszczak

W PHPBB też jest coś takiego używane, ale - znowu - nie prościej użyć rzutowania typów? Ostatnio zrobiłem coś takiego na zmiennej $id z GET'a i nawet jeśli dałem id=3fk5 to jeśli zrzutowałem to na (int) otrzymywałem 35. Chyba o to wam chodzi, nie?