![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 190 Pomógł: 0 Dołączył: 12.02.2004 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
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:
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):
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:
2. Przy wstawianiu numerów ID do zapytań należy stosować tzw. rzutowanie typów:
3. Przy wstawianiu tekstów, należy wyciąć niebezpieczne znaki przy pomocy funkcji:
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 |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Najki @ 2004-11-25 00:13:57) Oto co możemy dokonać: 1. Możemy sformułować nasze zapytanie do SQL tak:
2. Numer ID warto ustawiać w sposób $_GET['id'], lub $_POST['id'], można też ustawić go w nast. sposób:
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. 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 |
|
|
![]()
Post
#3
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]()
Post
#4
|
|
Grupa: Zarejestrowani Postów: 190 Pomógł: 0 Dołączył: 12.02.2004 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vengeance @ 2004-11-25 00:34:40) punkt 1. twojego "zabezpieczenia" nie ma nic do rzeczy z rzeczywistym bezpieczeństwem przynajmniej wg mnie Gdzieś znalazłem informację, że niby jednak to ma pomóc (głównie chodzi o średnik tam też o średnik na końcu zapytania) Cytat(Vengeance @ 2004-11-25 00:34:40) 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 Czy czasem $_POST, $_GET i $_COOKIE nie mają automatycznie dodawanych slash'y ? Cytat(Vengeance @ 2004-11-25 00:34:40) 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 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ł)
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 560 Pomógł: 0 Dołączył: 15.07.2003 Skąd: Kwidzyn Ostrzeżenie: (0%) ![]() ![]() |
zabezpieczenie w stylu:
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: 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 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. |
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 90 Pomógł: 2 Dołączył: 3.12.2004 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Kinool @ 2004-11-25 07:48:38) to co ma byc stringiem dodawac slashe (addslashes) nie rozumiem dlaczego wszyscy piszą o addslashes, przecież php automatycznie dodaje slashe do wszystkich zmiennych $_GET i $_POST i włamanie opisane przez Najki
nie ma prawa zadziałać. Czy mógłby ktoś wyjaśnić mi tą sytuację? |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 190 Pomógł: 0 Dołączył: 12.02.2004 Skąd: Poznań Ostrzeżenie: (0%) ![]() ![]() |
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ł? (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) |
|
|
![]()
Post
#8
|
|
Grupa: Przyjaciele php.pl Postów: 2 335 Pomógł: 6 Dołączył: 7.03.2002 Ostrzeżenie: (0%) ![]() ![]() |
Dodam jeszcze te dwa linki:
http://www.nextgenss.com/papers/SecondOrderCodeInjection.pdf http://hacking.pl/download.php?file=get&id=113 |
|
|
![]()
Post
#9
|
|
Grupa: Zarejestrowani Postów: 117 Pomógł: 0 Dołączył: 24.05.2004 Skąd: krakow Ostrzeżenie: (10%) ![]() ![]() |
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:
a to kod funkcji wykonujacej to sprawdzenie:
Chcialbym uniknac mozliwosci wlamania, poprzez wpisanie kodu SQL do pola haslo i uzytkownik:) |
|
|
![]()
Post
#10
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) ![]() ![]() |
przyklad:
wywołanie normalne: Kod news.php?id=1 news.php?id=25 itd wywołanie zmodyfikowane przez kogostam np. Kod news.php?id=1;DROP%20TABLE%20news; zabezpieczenie? ja znalazlem pare... 1. dodanie id2
2. wymuszenie typu
3. mysql_escape_string
ale mam wrazenie ze to dalej nie o to biega... z tych 3 które przedstawilem to pierwsze wydaje mi sie być najrozsądniejsze... |
|
|
![]()
Post
#11
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat(ActivePlayer @ 2005-02-26 21:45:06) 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ń |
|
|
![]()
Post
#12
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]()
Post
#13
|
|
Grupa: Zarejestrowani Postów: 640 Pomógł: 44 Dołączył: 8.02.2004 Ostrzeżenie: (0%) ![]() ![]() |
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
|
|
|
![]()
Post
#14
|
|
Grupa: Zarejestrowani Postów: 193 Pomógł: 0 Dołączył: 14.09.2003 Skąd: Brodnica (koło Torunia) Ostrzeżenie: (0%) ![]() ![]() |
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)
|
|
|
![]()
Post
#15
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Ja do liczb stosuje najczęściej ereg (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 |
|
|
![]()
Post
#16
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
@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).
|
|
|
![]()
Post
#17
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
@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:
powoduje przepisanie do $i wartości 123 typu INTEGER.
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:
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:
Pozdrawiam Marcin Staniszczak Ten post edytował MStaniszczak 2.03.2005, 03:09:57 |
|
|
![]()
Post
#18
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
@MStaniszczak: ja tam nie wiem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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ć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Może już to poprawili albo coś. Przytaczam tylko swoją "wiedzę" na ten temat, choc sam także używam is_integer() itp.
|
|
|
![]()
Post
#19
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
@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): Kod PHP_FUNCTION(is_numeric) { zval **arg; int result; if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &arg) == FAILURE) { WRONG_PARAM_COUNT; } switch (Z_TYPE_PP(arg)) { case IS_LONG: case IS_DOUBLE: RETURN_TRUE; break; case IS_STRING: result = is_numeric_string(Z_STRVAL_PP(arg), Z_STRLEN_PP(arg), NULL, NULL, 0); if (result == IS_LONG || result == IS_DOUBLE) { RETURN_TRUE; } else { RETURN_FALSE; } break; default: RETURN_FALSE; break; } } A to np. is_string: Kod PHP_FUNCTION(is_string) { php_is_type(INTERNAL_FUNCTION_PARAM_PASSTHRU, IS_STRING); } do tego php_is_type: Kod static void php_is_type(INTERNAL_FUNCTION_PARAMETERS, int type) { pval **arg; if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &arg) == FAILURE) { php_error_docref(NULL TSRMLS_CC, E_WARNING, "Only one argument expected"); RETURN_FALSE; } if (Z_TYPE_PP(arg) == type) { if (type == IS_OBJECT) { zend_class_entry *ce; ce = Z_OBJCE_PP(arg); if (!strcmp(ce->name, INCOMPLETE_CLASS)) { RETURN_FALSE; } } if (type == IS_RESOURCE) { char *type_name; type_name = zend_rsrc_list_get_rsrc_type(Z_LVAL_PP(arg) TSRMLS_CC); if (!type_name) { RETURN_FALSE; } } RETURN_TRUE; } else { RETURN_FALSE; } } 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 |
|
|
![]()
Post
#20
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 0 Dołączył: 25.01.2004 Skąd: Świętochłowice Ostrzeżenie: (0%) ![]() ![]() |
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?
|
|
|
![]()
Post
#21
|
|
Grupa: Przyjaciele php.pl Postów: 2 335 Pomógł: 6 Dołączył: 7.03.2002 Ostrzeżenie: (0%) ![]() ![]() |
To o czym piszesz sprawdza sie przy liczbach, natomiast do ciagow znakow trzeba juz inaczej do tego podchodzic.
|
|
|
![]()
Post
#22
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
@krzemian:
Cytat 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? Ciekawe co piszesz - sprawdź co zwróci skrypt...
A teraz popróbuj:
Pozdrawiam Marcin Staniszczak |
|
|
![]()
Post
#23
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) ![]() ![]() |
Moze ktos napisze klase, lub zbiór funkcji, alby uniknąc tego typu problemów, tylko ze... tu problem nie polega na tym, co zrobic zeby sprawdzic jaki typ danych user wpisze, tylko raczej na tym jak mądrze napisac zapytanie.
|
|
|
![]()
Post
#24
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Ja używam czegoś takiego (ma już swoje latka - dodałem tylko public;-):
A plik email.inc.php:
Dalej validuje już w odpowiednich funkcjach - inaczej chyba ciężko;-) Pozdrawiam Marcin Staniszczak Ten post edytował MStaniszczak 3.03.2005, 23:18:45 |
|
|
![]()
Post
#25
|
|
Grupa: Zarejestrowani Postów: 34 Pomógł: 2 Dołączył: 21.11.2003 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
no to i moje 3 grosze. primo: nie ma to jak szczyt lenistwa:
Kod foreach($_REQUEST as $key => $item) $$key = addslashes($item); mam nadzieje, ze sie podoba (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) oczywiscie nie wszedzie uzyteczne, niekoniecznie optymalne i nie zawsze dzialamy tylko na $_REQUEST. ale mniej wiecej juz znacie geneze (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) mozliwe modyfikacje oczywiscie: Kod foreach($_POST as $key => $item) $_POST[$key] = addslashes($item); itd... (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) zamiast addslashes mozna dac intvalue, albo i obydwa.. jesli nie frunie duzo danych to i tak nie bedzie roznicy w czasie wykonywania skryptu - a nie trzeba z dokladnoscia ksiegowego sprawdzac czy o czyms (czyt. ktorejs zmiennej) nie zapomnielismy pierwsza metoda (dla nei wiedzacych) symuluje niejako Register Globals na On, czyli zamiast odwolywac sie do strval($_REQUEST['zmienna']) mozemy po wykonaniu tamtego odwolac sie po prostu do $zmienna, ktora juz jest sparsowana pod kategm 'nieporzadanej' zawartosci EDIT: dziala oczywiscie i w druga strone. jesli do $rekord zczytamy sobie jakies dane z bazy danych to mozna sobie leniwie wrzucic: Kod foreach($rekord as $key => $item) $rekord[$key] = stripslashes($item); tylko nalezy pamietac, aby czytac dane za pomcoa mysql_fetch_assoc lub row - nie mysql_fetch_array, gdyz wtedy mamy podwojne klucze w tablicy i wiadomo co sie stanie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Ten post edytował docent 4.03.2005, 00:21:06 |
|
|
![]()
Post
#26
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
@docent: szczerze to zadna nowosc (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)
---- Przez chwilke pomyslalem, ze mozna by zmienne przekazyawc przez: www.site.com?int[postID]=4&string[mode]=showAll&bool[save]=true I robic odpowiednie petle na tablicach, stosujac odpowiednie funkcje (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]()
Post
#27
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Przez chwilke pomyslalem, ze mozna by zmienne przekazyawc przez: www.site.com?int[postID]=4&string[mode]=showAll&bool[save]=true I robic odpowiednie petle na tablicach, stosujac odpowiednie funkcje smile.gif I otrzymali byśmy w GET coś takiego:-) Więc bardzo miło;-) Kod Array ( [int] => Array ( [postID] => 4 ) [string] => Array ( [mode] => showAll ) [bool] => Array ( [save] => true ) ) Pozdrawiam Marcin Staniszczak |
|
|
![]()
Post
#28
|
|
Grupa: Zarejestrowani Postów: 34 Pomógł: 2 Dołączył: 21.11.2003 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vengeance @ 2005-03-04 20:04:20) @docent: szczerze to zadna nowosc (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) ---- Przez chwilke pomyslalem, ze mozna by zmienne przekazyawc przez: www.site.com?int[postID]=4&string[mode]=showAll&bool[save]=true I robic odpowiednie petle na tablicach, stosujac odpowiednie funkcje (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) heihei ja nie mowie, ze nowowsc - ale informacja dla tych, ktorzy nie znaja (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) a istotnie - jest pomocna :] bardziej mnie interesowalo zdanie innych na ten temat - sposob w zasadzie sam sobie stwrozylem (choc pewnie kazdy na to wpadl we wlasnym zakresie) i interesowalo mnie tylko zdanie innych w tej kwestii (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]()
Post
#29
|
|
Grupa: Zarejestrowani Postów: 147 Pomógł: 0 Dołączył: 3.03.2004 Skąd: śląsk Ostrzeżenie: (0%) ![]() ![]() |
w sumei można też tak, np. dla newsów:
To blokuje wysiwetlanie newsa np. 9999 jak i tekstu. w zmiennej id. Ten post edytował tara 2.04.2005, 17:33:28 |
|
|
![]()
Post
#30
|
|
Grupa: Zarejestrowani Postów: 46 Pomógł: 0 Dołączył: 13.03.2004 Skąd: Siemianowice Śl. Ostrzeżenie: (0%) ![]() ![]() |
Cytat To blokuje wysiwetlanie newsa np. 9999 jak i tekstu. w zmiennej id. no dobra, ale to niewiele ma do zabiezpieczenia przed SQL Injection...akurat wyswietlenie newsa nr 99999 nie wprowadza zadej nowej mozliwosci ataku.... wracając do tematu.... http://www.phpsolmag.org/pl/modules/wmpdow...php?cid=1&lid=6 tutaj jest darmowy artykuł z magazynu php solutions |
|
|
![]()
Post
#31
|
|
Grupa: Zarejestrowani Postów: 147 Pomógł: 0 Dołączył: 3.03.2004 Skąd: śląsk Ostrzeżenie: (0%) ![]() ![]() |
heh no ale jak ktoś wprawdzi DROP TABLE itp. to też zablokuje (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
|
|
|
![]()
Post
#32
|
|
Grupa: Zarejestrowani Postów: 193 Pomógł: 0 Dołączył: 14.09.2003 Skąd: Brodnica (koło Torunia) Ostrzeżenie: (0%) ![]() ![]() |
Cytat(MStaniszczak @ 2005-02-28 04:21:48) Hmmm.... wykonanie ereg zajmuje nieco czasu (jak to wyrażeń regularnych). [...] Szczerze mówiąc, to wolę stracić tą sekundę w czasie wykonywania skryptu niż stracić na bezpieczeństwie. I mniejszy bałagan w kodzie - jedna funkcja zamiast szeregu IF. A wyrażenie regularne można w razie czego łatwo zmodyfikować jeśli się znajdzie błąd. |
|
|
![]()
Post
#33
|
|
Grupa: Zarejestrowani Postów: 13 Pomógł: 0 Dołączył: 29.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
IMHO dosc wygodna i bezpieczne rozwiazanie:
a potem definiujemy swoje funckje sprawdzajace
a wykoanie zapytania np tak:
I w ten sposob nawet przy braku magic quotes czy tez mozliwosci wielu zapytan w jednemy poleceniu, nikt nie przepcha zadnego zlosliwego kodu. Ten post edytował tarlandil 29.04.2005, 07:50:11 |
|
|
![]()
Post
#34
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vengeance @ 2005-02-27 13:44:07) 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 Cytat przez mysql_query() nie. ale funckje postgreSQL już to dopuszczają :/ Dlatego userzy tego drugiego mają większy problem. A jak go rozwiązać? Cytat Co do zabezpieczenia, nie wiem czym się tak przejmujecie? ;] Ja stosuje jedynie addslashes() oraz usuwam slowo 'UNION' ze zmiennych Przecież addslashes() to tosamo co mysql_escape_string() (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) |
|
|
![]()
Post
#35
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat(J4r0d @ 2005-05-08 17:11:33) Cytat(Vengeance @ 2005-02-27 13:44:07) 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 Cytat przez mysql_query() nie. ale funckje postgreSQL już to dopuszczają :/ Dlatego userzy tego drugiego mają większy problem. A jak go rozwiązać? Cytat Co do zabezpieczenia, nie wiem czym się tak przejmujecie? ;] Ja stosuje jedynie addslashes() oraz usuwam slowo 'UNION' ze zmiennych Przecież addslashes() to tosamo co mysql_escape_string() (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) 1. np. mozna przefiltrowac ciag wyrzucajac wszelkie sredniki 2. funkcja nie sa sobie rownoznaczne mysql_real_escape_string() 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). |
|
|
![]()
Post
#36
|
|
Grupa: Zarejestrowani Postów: 90 Pomógł: 2 Dołączył: 3.12.2004 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(J4r0d @ 2005-05-08 16:40:02) Więc, które rozwiązanie bezpieczniejsze? Stosować addslashes() ? Nie rozumiem o co Wam chodzi z tym addslashes(). Czy chodzi o podwójne stosowanie addslashes()? Raz przecież robi to samo php. Otrzymując dane z formularzy dostajemy postać: To jest \"smaczny deser\" Czy trzeba to jeszcze raz potraktować addslashes() i otrzymać: To jest \\\"smaczny deser\\\" i dopiero wtedy wrzucać do bazy? Już od dawna mnie frapuje ten problem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) czy może ktoś to wyjaśnić? |
|
|
![]()
Post
#37
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
addslashes() (jeden raz!!!) powinno w zupelnosci wystarczyc. przy sotsowaniu mysql_escape_string moze sie pojawic porblem przy wyciganiu danych z bazy i stosowaniu stripslashes()
|
|
|
![]()
Post
#38
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
Smieszne sa te wasze rozwazania, nie szkoda czasu?
Przypomina mi to wiare w zabobony. Addslashes zalatwia calkowice sprawe, sprobujcie sie wlamac bez mozliwosci uzycia apostrofu. Mozecie wpisywac UNION, srednik i co tylko chcecie, ale to nic nie da, bo i tak co najwyzej zostanie wciagniete do bazy jako czesc stringa. Do liczb is_numeric i wystarczy. |
|
|
![]()
Post
#39
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat Nie rozumiem o co Wam chodzi z tym addslashes(). Czy chodzi o podwójne stosowanie addslashes()? Chodzi o to, że slash dodawany jest jeżeli włączona jest jakaś opcja (już nie pamiętam o jaką chodziło - szukaj na pierwszej stronie tego topicu). A jak dodadsz addslashes() to nawet jak dodawanie slasha jest wyłączone to ty massz pewność. Cytat Smieszne sa te wasze rozwazania, nie szkoda czasu? Przypomina mi to wiare w zabobony. Bezpieczeństwo - szkoda czasu? (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) Nie dla mnie :roll2: Cytat Addslashes zalatwia calkowice sprawe, sprobujcie sie wlamac bez mozliwosci uzycia apostrofu. Mozecie wpisywac UNION, srednik i co tylko chcecie, ale to nic nie da, bo i tak co najwyzej zostanie wciagniete do bazy jako czesc stringa. Do liczb is_numeric i wystarczy. Skoro tak mówisz to będę tak robił. Jaby co to wiemy do kogo z pretensjami (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) Dziękuje za odpowiedź i pozdrawiam |
|
|
![]()
Post
#40
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(J4r0d @ 2005-05-08 16:56:50) Bezpieczeństwo - szkoda czasu? (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) Nie dla mnie :roll2: A co z bezpieczenstwem ma wspolnego kasowanie ciagow typu UNION ze zmiennej, w ktorej i tak kazdy apostrof zostanie wysleszowany? Nic. addslash lub magic quote zalatwia calkowicie sprawe sql injection, oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Ten post edytował Peter Riley 8.05.2005, 18:45:39 |
|
|
![]()
Post
#41
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Peter Riley @ 2005-05-08 17:43:03) oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Możesz rozwinąć? |
|
|
![]()
Post
#42
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(J4r0d @ 2005-05-08 18:08:08) Cytat(Peter Riley @ 2005-05-08 17:43:03) oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Możesz rozwinąć? Po prostu musimy sprawdzic, czy przeslane wartosci maja odpowiedni przedzial, czyli np. wpisana ilosc sztuk nie przekracza stanu magazynu. W przypadku wartosci tekstowych mozna porownac wyszukac ciagu w zadeklarowanej wczesniej tablicy lub uzyc switch of. Jednak to wszystko nie ma nic wspolnego ze sql injection, przed ktorym pelna obrone zapewnia defaultowa konfguracja php, a jesli wylaczymy magic quote, pozostanie addslashes. |
|
|
![]()
Post
#43
|
|
Grupa: Zarejestrowani Postów: 853 Pomógł: 25 Dołączył: 27.08.2003 Skąd: Katowice Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Peter Riley @ 2005-05-08 18:43:03) addslash lub magic quote zalatwia calkowicie sprawe sql injection smiem twierdzic ze jest to zbyt odwazne stwierdzenie. wyobraz sobie taka sytuace : URL: www.strona.php?articleid=12 filtrujemy: $id = addslashes($_GET['articleid']) wstawiamy w zapytanie : query = 'SELECT * FROM articles WHERE id='.$id; i teraz np. URL www.strona.php?articleid=12 OR 1 jak widzisz w tym przykladzie (co prawda dosc naiwnym) addslashes nie zalatwilo sprawy... |
|
|
![]()
Post
#44
|
|
Grupa: Zarejestrowani Postów: 560 Pomógł: 0 Dołączył: 15.07.2003 Skąd: Kwidzyn Ostrzeżenie: (0%) ![]() ![]() |
panowie!!!!
juz ktos pisal o tym ze wiemy co "spodziewamy" sie otrzymac jesli chodzi o liczby to nie addslashes tylko intval() lub settype() $id = intval($_GET['articleid']); i jesli gosc wklepie tam cokolwiek to i tak bedzie zutowane na liczbe nawet ze wzglegow optymalizacji lepiej jest wykonac zapytanie SELECT * FROM table WHERE id=10 niz SELECT * FROM table WHERE id='10' poniewaz MySQL nie musi robic konwersji addslashes uzywamy jesli mamy doczynienia z wartosciami textowymi lub mieszanymi tak na marginesie to zadna funkcja nie zwalnia od myslenia! Ten post edytował Kinool 9.05.2005, 00:20:28 |
|
|
![]()
Post
#45
|
|
Grupa: Zarejestrowani Postów: 18 Pomógł: 0 Dołączył: 7.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(sopel @ 2005-05-08 21:14:33) smiem twierdzic ze jest to zbyt odwazne stwierdzenie. To chyba oczywiste, ze musimy sprawdzic czy liczby rzeczywiscie sa liczbami, przy okazji sprawdzajac ich zakres. Zreszta pisalem o tym wyzej. Dodam tylko, ze ja sklaniam sie raczej do sprawdzania typu, a nie konwersji na sile. Jesli typ sie nie zgadza, to mail do admina i die(). Nie jest to odwazne stwierdzenie tylko fakt. Zaloze sie, ze ci co usuwaja UNION i sredniki z ciagow, na wszelki wypadek klikaja "zastosuj" w windowsowych okienkach tuz przed kliknieciem "ok" :-) Ten post edytował Peter Riley 9.05.2005, 01:32:48 |
|
|
![]()
Post
#46
|
|
Grupa: Zarejestrowani Postów: 243 Pomógł: 0 Dołączył: 30.11.2003 Ostrzeżenie: (0%) ![]() ![]() |
Dorzucę się do tego wątku i powiem, że moim zdaniem najlepszym zabezpieczeniem jest:
1. ustawienie w php.ini opcji get_magic_quotes_gpc na ON 2. stosowana równolegle z powyższym funkcja czyszcząca otrzymane dane - od razu uprzedzam, że wbrew nazwie nie dotyczy ona tylko danych przesyłanych metodą POST:
3. Funkcja zapewniająca dodatkowe filtrowanie dla identyfikatorów, przekazywanych w URL'u:
Zastosowanie:
Jakieś uwagi? Pozdrawiam, K |
|
|
![]()
Post
#47
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Peter Riley @ 2005-05-08 19:43:03) Cytat(J4r0d @ 2005-05-08 16:56:50) Bezpieczeństwo - szkoda czasu? (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) Nie dla mnie :roll2: A co z bezpieczenstwem ma wspolnego kasowanie ciagow typu UNION ze zmiennej, w ktorej i tak kazdy apostrof zostanie wysleszowany? Nic. addslash lub magic quote zalatwia calkowicie sprawe sql injection, oczywiscie pozostaje sprawdzenie czy nadeslane dane mieszcza sie w dozwolonym zakresie, ale to juz inna historia. Hyh... kompletnie się z Tobą nie zgodzę :] Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu! Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne ! |
|
|
![]()
Post
#48
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 10.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
a takie pytanko jeszcze.
czy umozliwienie stosowania wszystkich znakow np. spacji przy tworzeniu loginu podczas rejestracji jest niebezpieczne ? |
|
|
![]()
Post
#49
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 10.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
wszystkie znaki - oczywiscie przy wlaczanej dyrektywie gpc_magic_quotes
ktuvok - uzywam podobnego mechanizmu i na razie nie ma problemow (moze dlatego, ze nikt nie robil testow, albo nie zauwazono, ze cos jest nie tak). dodatkowo uzywam htmlspecialchars. Ten post edytował bolas 18.05.2005, 14:58:44 |
|
|
![]()
Post
#50
|
|
Grupa: Zarejestrowani Postów: 581 Pomógł: 0 Dołączył: 21.07.2003 Skąd: Jasło Ostrzeżenie: (0%) ![]() ![]() |
Nie wiem czy był dawany ten link lecz jeśli nie to prosze o usunięcie postu, a takto ciekawy art do przeczytanie http://www.computerworld.pl/artykuly/31505.html
|
|
|
![]() ![]()
Post
#52
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vengeance @ 2005-05-14 20:44:37) Union da się wiele razy wykorzystać nie stosując nawet jednego apostrofu! Więc samo używanie addslashes() w przypadku posiadania MySQL 4 nie jest bezpieczne ! Mam w takim razie pytanko: w jaki sposób wykonać SQL Injection w takim skrypcie:
Jakoś nie widzę tutaj możliwości wykorzystania UNION poprzez SQL Injection (IMG:http://forum.php.pl/style_emoticons/default/dry.gif) Ten post edytował logeen 6.07.2005, 14:32:51 |
|
|
![]()
Post
#53
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Wiadomym jest, że nie w każdym się da... ale są przypadki gdzie tak jest. Przecież w UNION najczęściej chodzi o wyciągnięcie danych... więc nie musisz używać apostrofu. Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta.
|
|
|
![]()
Post
#54
|
|
Grupa: Zarejestrowani Postów: 90 Pomógł: 2 Dołączył: 3.12.2004 Ostrzeżenie: (0%) ![]() ![]() |
Nie zapominajmy, że przy union włamywacz musi znać nazwę tabeli i pól w tabeli mysql, a w przypadku, jeśli ktoś pisze skrypty sam i nie używa gotowców, prawdopodobieństwo, że włamywacz odgadnie nazwę tabeli i pola jest IMHO bardzo małe.
|
|
|
![]()
Post
#55
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
IMHO pokaz mi programiste co nie trzyma loginow i hasel w tabeli nazwą zblizonej do 'users' :]
Pozatym... wywolujac kontrolowane bledy SQL mozna czesto poznac spora czesc struktury bazy SQL. Ale ogólnie to masz racje (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) |
|
|
![]()
Post
#56
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(Vengeance @ 2005-07-07 18:53:24) Gdy ktoś zrobi błąd w takim miejscu, iż użycie apostrofu nie jest wymagane (a najczęściej jest właśnie tylko w dyrektywach WHERE) to droga otwarta. Tutaj się zgodzę, ale powiedzcie mi w takim razie, po co sztucznie wywalać UNION ze wszystkich danych podstawianych do zapytania, jeżeli można je tak zabezpieczyć, że nigdy nie będzie możliwości wykonania SQL injection (np. tak jak zaprezentowałem powyżej)? Czy to nie jest paranoja? Gdyby programiści IPB byli tak na to wyczuleni, to na tym forum w treści postów w ogóle nie dałoby się wpisać słowa "UNION" i jeszcze kilku innych, a jak widać da się (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]()
Post
#57
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Dlatego, że w takim forum wykonuje się masę zapytań i nie zawsze wszystkie 100% sprawdzisz. Więc lepiej w jednym miejscu filtrować niebezpieczne dane... by potem mieć pewność że do każdego zapytania dotrą w odpowiedniej formie... i że nie zapomnieliśmy gdzieś czegoś filtrować.
|
|
|
![]()
Post
#58
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
To jasne, ale zależy, co rozumiesz przez "filtrować". Jeżeli filtrowaniem nazywamy np. używanie funkcji "addslashes" czy "intval", to OK. Ale jeżeli to ma polegać na bezcelowym usuwaniu np. wszystkich wystąpień słowa "UNION" i innych podobnych z danych przesyłanych przez użytkownika, a podstawianych do zapytania, to ja tego nie rozumiem. Po co to usuwać, skoro i tak w żaden sposób nie może zaszkodzić, jeżeli odpowiednio przefiltrujemy dane? Na dodatek przez takie postępowanie zupełnie niepotrzebnie eliminujemy sobie możliwość wstawienia do bazy danych niektórych słów, co może być akurat potrzebne. Spróbujcie napisać np. tutorial używania unii w SQL, jeżeli z każdego tekstu wstawianego do bazy będziecie czyścić to słowo ;-)
Jak ktoś nie filtruje danych, to i tak żadne usuwanie "UNION" itp. mu nie pomoże, bo SQL injection można wykonać na wiele innych sposobów, kiedy nie przefiltrujemy danych wejściowych... |
|
|
![]()
Post
#59
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
1. A kto mówi że strona musi traktować o czymś gdzie wystąpi UNION.
2. Zobacz ile skryptów (np. phpbb) jest podatnych na tego typu ataki |
|
|
![]()
Post
#60
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
ad.1) Czyli co? Jeżeli zamierzasz zbudować np. forum dyskusyjne przeznaczone do dyskusji na temat języka SQL, to nie będzie się go dało zabezpieczyć, bo w takim przypadku usuwanie "UNION" z treści wysyłanych postów jest absolutnie nie do przyjęcia, a tylko to dałoby wystarczające zabezpieczenie?
ad.2) Skrypty są podatne, ponieważ programiści zapomnieli przefiltrować dane. Gdyby to zrobili, to by nie były podatne. Usuwanie "UNION" tutaj nic nie zmieni, ponieważ jeżeli dane wejściowe potraktujemy odpowiednio "addslashes" czy "intval", to żadne "UNION" przemycone w treści nam nie zaszkodzi. Do tego właśnie zmierzało moje pytanie, na które do tej pory nikt nie odpowiedział jasno i wyraźnie: czy jeśli stosujemy odpowiednią filtrację danych (np. taką jak zaprezentowałem), to wstawienie przez użytkownika "UNION" w danych wejściowych może się źle skończyć? |
|
|
![]()
Post
#61
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Nie ma sensu nic wywalać (filtrować żadnych słów). Grunt to dobrze wstawiać slashe a tam gdzie ich nie można dodać (np. identyfikatory) stosować odpowiednio is_number, is_integer, intval etc… Nie da rady o tym zapomnieć;-)
Dobry sposobem mogą być filtry w frameworku;-) Ew. klasa z metodami sprawdzającymi dane odpowiednich typów, a wówczaj wystarczy już coś w stylui:
Czy jakoś tak;-) Przy takiej organizacji łatwiej nawet poprawić ew. błąd czy luke w sposobie sprawdzania danych;-) Pozdrawiam Marcin Staniszczak Ten post edytował MStaniszczak 8.07.2005, 09:39:33 |
|
|
![]()
Post
#62
|
|
Grupa: Zarejestrowani Postów: 105 Pomógł: 0 Dołączył: 16.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
Oświećcie mnie proszę i powiedzcie, gdzie przy zdrowych zmysłach programista może zostawić lukę, że można użyć UNION bez ani jednego apostrofa? Przecież to jest możliwe tylko przy czymś takim:
O czym wogóle rozmawiacie... tak robią tylko początkujący-nieuświadomieni. |
|
|
![]()
Post
#63
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
Imperior... są nawet tacy co robią
Widac, ze analizowales malo skryptów i mało skomplikowanych zapytań widziałeś. Cytat tak robią tylko początkujący-nieuświadomieni O ile mi wiadomo, to forum i ten wątek jest także dla takich a my staramy się ich uświadomić co może być błędem. @logeen: AD2. Prawdopodobnie masz racje i wykorzystanie wszędzie odpowiednich filtrów intval() itd... wystarczy, ALE Mała opowieść: Cytat Zostałem adminem forum szkolnego. Obecnie jedyna możliwość posiadania dość fajnego i darmowego forum to phpBB. Pozatym
wcześniej też takie tam było i użytkownicy się przyzwyczaili. Zrobiłem update do najnowszej wersji, ale wiadomo że i tak znajdą jakieś błędy (i znaleźli). Trzeba było więc zastosować właśne zabezpieczenia. Przecież nie będę naprawiał całego phpBB i w odpowiednich miejscach dawał intval() tam gdzie oni zapomnieli! Zrobilem tak więc filtrację danych z GET i usuwam wszystkie "UNION". Jeśli znajdziesz mi podobne w szybkosći implementacji i pod względem bezpieczeństwa rozwiązanie to z chęcią wysłucham. A na forum dalej można pisać UNION gdyż filtruje tylko GET (phpBB do wszelkich rzeczy używa naszczęście tablic GET/POST/COOKIE a nie jedzie na superglobalach. |
|
|
![]()
Post
#64
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
@Vengeance: Z tą opowieścią, to się z Tobą zgodzę. Z tym, że są pewne "ale":
1. Ten temat chyba raczej miał na celu przedstawienia zasad takiego pisania skryptów, aby nie były podatne na SQL injection, a nie poprawiania gotowych skryptów. Więc w przypadku, który podałeś, takie postępowanie może być uzasadnione, ale chyba raczej nie w sytuacji, kiedy piszemy cały skrypt od nowa. 2. Jeżeli w sytuacji, którą przedstawiłeś, nie przefiltruje się odpowiednio danych, to i tak usuwanie "UNION" niekoniecznie da 100% bezpieczeństwo, bo przecież są inne sposoby wykonania SQL injection niż tylko za pomocą unii. Natomiast faktycznie w sytuacji konieczności porawiania istniejących dziurawych skryptów, lepsze takie zabezpieczenie niż żadne. 3. Dane $_POST też przecież można spreparować, po prostu tworząc odpowiedni formularz i go wysyłając do skryptu (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) Co wiecej, można zrobić tak, żeby taki formularz wysłał nieświadomie administrator forum. |
|
|
![]()
Post
#65
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
@logeen: Ale powiedzmy sobie prawde, że fora szkolne "hakują" tylko gówniarze co potrafią jedynie ściągnąć sploita z internetu. A te korzystają wyłącznie z GET i najczęściej właśnie z UNION (w przypadku phpBB). Ja nie mówie o pełnym zabezpieczeniu gotowca (bo to niemożliwe) ale o "zawężeniu kręgu niebezpieczeństwa" :]
Chyba doszliśmy do porozumienia (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]()
Post
#66
|
|
Grupa: Zarejestrowani Postów: 90 Pomógł: 2 Dołączył: 3.12.2004 Ostrzeżenie: (0%) ![]() ![]() |
Mówcie co chcecie, ale czy jest ktoś w stanie podać konkretny zestaw zabezpieczeń, który ustrzeże nas przed atakami poprzez php (oczywiście takie, które zależą od programisty) czy może nie ma sposobu na 100%-owe zabezpieczenie skryptów?
|
|
|
![]()
Post
#67
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
@johnson:
Odpowiedź brzmi: pełna filtracja (tzn. "addslashes", "intval" itp.) wszystkich danych zewnętrznych, które podstawiamy do zapytania SQL. Oczywiście jeżeli piszesz skrypt od zera, bo jeżeli poprawiasz bezpieczeństwo jakiegoś dziurawego gotowca, to trudno Ci będzie sprawdzić wszystkie linie kodu (ale nie jest to niewykonalne, bo tak naprawdę musimy odszukać tylko miejsca wywoływania zapytań SQL i sprawdzić, czy wszystkie zmienne podstawiane do kodu SQL są przefiltrowane) - wtedy można się dodatkowo zdecydować na rozwiązanie podane przez Vengeance, choć i tak nie będzie to pełne zabezpieczenie, niemniej powinno powstrzymać większość script kiddies. Ten post edytował logeen 8.07.2005, 13:34:56 |
|
|
![]() ![]()
Post
#68
|
|
Grupa: Zarejestrowani Postów: 92 Pomógł: 0 Dołączył: 13.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
jezeli mozna wtracic swoje 3 grosze.... to testowalem swoj system zlecen i o dziwo nie mozna sie do niego dostac za pomoca SQL injection, zasluga jest to domyslnych ustawien serwera oraz kilku funkcji sprawdzajacych poprawnosc - ktore wcale nie byly pisane w tym celu.... ogolnie warto jest pisac funkcje sprawdzajace poprawnosc wpisanych przez uzytkownika wartosci - nawet po to aby uniknac wpisywania glupot w wypadku gdy uzytkownikowi pomieszaja sie pola formularza (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
pozdrawiam |
|
|
![]()
Post
#69
|
|
Grupa: Zarejestrowani Postów: 71 Pomógł: 1 Dołączył: 3.10.2004 Ostrzeżenie: (0%) ![]() ![]() |
A tu http://www.gajdaw.pl/varia/xss.html macie coś o atakcha na strony (nie SQL Injection więc troche OT;-) )
Pozdrawiam Marcin Staniszczak |
|
|
![]()
Post
#70
|
|
Grupa: Zarejestrowani Postów: 20 Pomógł: 0 Dołączył: 24.08.2005 Ostrzeżenie: (0%) ![]() ![]() |
czyli co? mysql_escape_string, stripslashes (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)
moglby ktos napisac jakas funkcje ktora by to robila? |
|
|
![]()
Post
#71
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
Ten post edytował logeen 22.10.2005, 13:58:36 |
|
|
![]()
Post
#72
|
|
Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 22.02.2004 Ostrzeżenie: (0%) ![]() ![]() |
Jak można zabazpieczyć stronę jeżeli mam where id=$_GET['id'] and password=$password, wtedy wpisując kod w $_GET['id']= '7 --'
Zaniecha mi sprawdzanie hasła. Te funckje działają tylko w ściśle określonych przypadkach. Jak można było by zabezpieczyc przed pytaniami or,select,delete, into,update, w tablicy _GET, i mieć jakąś tam pewność że skrypt będzie zabezpieczony. |
|
|
![]()
Post
#73
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) ![]() ![]() |
Cytat Jak można zabazpieczyć stronę jeżeli mam where id=$_GET['id'] and password=$password, wtedy wpisując kod w $_GET['id']= '7 --' uzyj is_numeric na $_GET['id'] |
|
|
![]() ![]()
Post
#74
|
|
Grupa: Zarejestrowani Postów: 22 Pomógł: 0 Dołączył: 29.06.2005 Ostrzeżenie: (0%) ![]() ![]() |
Mam takie pytanie...
i teraz jak zrobic zeby wszystkie dane z _POST przepuscic przez mysql_real_escape_string bez koniecznosci powtarzania tej funkcji do kazdej zmiennej... tylko zrobic to hurtem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) please help |
|
|
![]()
Post
#75
|
|
Grupa: Przyjaciele php.pl Postów: 1 224 Pomógł: 40 Dołączył: 6.07.2004 Skąd: Wuppertal Ostrzeżenie: (0%) ![]() ![]() |
Cytat a jeśli zamiast _GET będzie _POST z jakimś tekstem? to obejmiesz te dane w ' i wykonasz na nich mysql_escape_string() |
|
|
![]()
Post
#76
|
|
Grupa: Zarejestrowani Postów: 158 Pomógł: 0 Dołączył: 29.06.2003 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Cytat(h.4 @ 2005-09-28 19:05:34) i teraz jak zrobic zeby wszystkie dane z _POST przepuscic przez mysql_real_escape_string bez koniecznosci powtarzania tej funkcji do kazdej zmiennej... tylko zrobic to hurtem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ? |
|
|
![]()
Post
#77
|
|
Grupa: Zarejestrowani Postów: 21 Pomógł: 0 Dołączył: 22.02.2004 Ostrzeżenie: (0%) ![]() ![]() |
Otóz zrobilem funckje która zamienia wyrażenia sql na np. z UnIoN na !union!. Sądze że to w miare skuteczna metota gdzyż zawiera popularną składnie sql + wyrażenia opisane w phpmyadminie na stronie ze statystykami. A co to tej pętli to się bardzo mi przyda (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
|
|
|
![]() ![]()
Post
#78
|
|
Grupa: Zarejestrowani Postów: 8 Pomógł: 0 Dołączył: 6.07.2005 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(qeuw @ 2005-09-28 20:08:04) Otóz zrobilem funckje która zamienia wyrażenia sql na np. z UnIoN na !union!. Sądze że to w miare skuteczna metota... Fakt... tylko po co? KAŻDE zapytanie można skutecznie zabezpieczyć przed SQL Injection, bez usuwania z niego słów kluczowych SQLa, a jedynie poprzez odpowiednią filtrację danych, przed podstawieniem ich do zapytania. Przez "Filtrację" rozumiem wykonania np. addslashes (albo lepiej funkcji, którą podałem wcześniej) lub np. intval tam, gdzie jest to konieczne - w zależności od kontekstu. Ciekaw jestem jak rozwiążesz sprawę, kiedy "UNION" powinno się zapisać w bazie danych, np. w jakiejś treści wyświetlanej później na stronie WWW? Fakt, można zamieniać np. na "!union!", a potem przy wyświetlaniu z powrotem na "UNION", ale po co? Jak ktoś mi pokaże jak wykorzystać "UNION" do wykonania SQL Injection w prawidłowo zabezpieczonym skrypcie - np. takim, jak podawałem w tym temacie kilka postów wcześniej - to będę bardzo wdzięczny. Wg mnie jest to niemożliwe. Po co w takim razie narzucać sobie jakieś sztuczne ograniczenia, polegające na niemożności wystąpienia w rekordach bazy danych jakichś słów (np. "UNION")? Ten post edytował logeen 29.09.2005, 20:01:40 |
|
|
![]()
Post
#79
|
|
Grupa: Zarejestrowani Postów: 168 Pomógł: 1 Dołączył: 19.11.2005 Ostrzeżenie: (0%) ![]() ![]() |
Prawdę mówiąc ten temat jest strasznie zaśmiecony. Niby ktoś pisał, że ma być też pomoca dla początkujących a jedyną rzeczą przydatną dla mnie, jako bardzo początkującego, było słowo addslashes. Niestety nic poza tym... Ani jak to wykorzystać ani jak to potem wyciągnąć z bazy danych... trochę szkoda bo gdy założyłem temat z prośbą o prostą odpowiedź ( http://forum.php.pl/index.php?showtopic=40200 ) to mi się trochę "oberwało" a temat przyklejony to dla początkującego uzytkownika czarna magia.
|
|
|
![]()
Post
#80
|
|
Grupa: Zarejestrowani Postów: 657 Pomógł: 2 Dołączył: 15.08.2003 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
MalyKazio: Znów ci się "oberwie" odemnie osobiście, bo skoro piszesz, że w tym temacie nic nie znalazłeś prócz addslashes() to śmię twierdzić, że czytać nie potrafisz i analizować kodów też nie!
Wiadomo, ile ludzi tyleż opini, dlatego w tym wątku znaleść można prawdziwe multum informacji o tym jak się zabezpieczyć. I nikt nie napiszę Ci jednego 100% sposobu - bo taki nie istnieje. Każdy ma jakieś zalety i wady, każda osoba faworyzuje innych. Ktoś ci napiszę "używaj addslashes" a potem odnajdą lukę w tej funkcji i cała koncepcja bierze w łęb :] Jeśli szukasz posegregowanych informacji to odsyłam do książek i artykułów. Tutaj jest forum, i nikt nie będzie edytował każdego postu tak aby początkujący mógł odczytać to jako książkę :/ A że się 5 stron czytać dokładnie ludziom nie chce.... no sorry. |
|
|
![]()
Post
#81
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.08.2003 Ostrzeżenie: (0%) ![]() ![]() |
i po sprawie, nikt nie podskoczy (mozna jeszcze trimowac, ale preg_replace nie przpusci chyba zero byte?) |
|
|
![]()
Post
#82
|
|
Grupa: Zarejestrowani Postów: 14 Pomógł: 0 Dołączył: 9.11.2005 Ostrzeżenie: (0%) ![]() ![]() |
Witam,
Czytałem posty na temat zabezpieczeń na stronie i zebrałem wszystko do kupy i wyszło mi coś takiego:
funkcja logs wyrzuca do pliku bardzo przydatne informacje o gościu który próbuje cos namieszać. W postaci np: "18:21:38 26-02-2006 ip: 127.0.0.1 proxy: plik: http://localhost/~www/zabezpieczenia.php url: http://localhost/~www/zabezpieczenia.php atak na zmienną: $akcja" Co tu jest niepotrzebne? a co źle!! Dodam ze metoda ma pobierac z linku dwie zmienne $akcja i $id dla późniejszego użycia zapytania SQL. $akcja ma zawierać tylko ciąg małych literek a $id tylko liczbe. Pozdrawiam. |
|
|
![]()
Post
#83
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 28.02.2006 Skąd: 127.0.0.1 :) => Ukraine Ostrzeżenie: (0%) ![]() ![]() |
Sorry that not Polish,
but your functions are so funny (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) e.g. Why do you make global $_SERVER?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) ?
I can`t explane it.
AND Kod UNI/**/ON OOPS (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)
Have you ever here about $_REQUEST?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) No? Ten post edytował vedeney 28.02.2006, 14:34:10 |
|
|
![]()
Post
#84
|
|
Grupa: Zarejestrowani Postów: 14 Pomógł: 0 Dołączył: 9.11.2005 Ostrzeżenie: (0%) ![]() ![]() |
hej vedeney. funkcja logs, jest przepisana. Global mozna wyrzucic. Ale czemu nie rozumiesz zastosowania tego kodu:
chcialem żeby nie mozna bylo użyć polecenia UNION.
wyciągania wszystkich tabel. |
|
|
![]()
Post
#85
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) ![]() ![]() |
i to tyle, zadne pregi, bo po co gdy pod $age wstawisz "UNION .....blalba.... --" $intAge == 0 gdy pod $name wstawisz "UNION .....blalba.... --" sql wyglada tak
bylo to juz wspominane na poczatku (lub dalej (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ) tego watka ale zginelo w masie postow probujacych to uzyskac. |
|
|
![]()
Post
#86
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 0 Dołączył: 28.02.2006 Skąd: 127.0.0.1 :) => Ukraine Ostrzeżenie: (0%) ![]() ![]() |
Ok! I`ve understand you, But your code didn`t prevent such hack as
Kod http://mojastron.php?id=10 UN/**/ION SEL/**/ECT bla bla bla.... Which will be executed without any problems; or Kod http://mojastron.php?id=BENCHMARK(1000000,MD5(NOW())) or Kod http://mojastron.php?id=BENCHMARK(1000000,BENCHMARK(1000000,BENCHMARK(1000000,MD5(NOW())))) It`s DOS through MySql-injection (IMG:http://forum.php.pl/style_emoticons/default/aaevil.gif) |
|
|
![]()
Post
#87
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 26.08.2003 Ostrzeżenie: (0%) ![]() ![]() |
Cytat(vedeney @ 2006-02-28 14:33:07)
Have you ever here about $_REQUEST?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) No? Yes, I've heard about $_REQUEST. But it's another stupid thing like register_globals on is. Let the manual speak: Cytat $_REQUEST Variables provided to the script via the GET, POST, and COOKIE input mechanisms, and which therefore cannot be trusted. The presence and order of variable inclusion in this array is defined according to the php variables_order configuration directive. This array has no direct analogue in versions of php prior to 4.1.0. See also import_request_variables(). Ain't simple? if you use _REQUEST, as foreach source, you won't be able to set cookie, set GET, set POST with the same string name! You will be forced to remember about it all time. Additionaly, here's no problem with my code, you can use _REQUEST in spite of. If you realy like it. |
|
|
![]()
Post
#88
|
|
Grupa: Zarejestrowani Postów: 160 Pomógł: 0 Dołączył: 27.03.2006 Ostrzeżenie: (0%) ![]() ![]() |
Cytat zabezpieczenie w stylu: 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. Bzdura. Zapisz taki jest jak najbardziej szybszy, bo kod nie jest parsowany (bo jest w ' '), a zapisując zmienną w cudzysłowiach w kodzie ("coś tam $zmienna") powoduje parsowanie kodu i dłuższe sprawdzanie zmiennych. Nie wprowadzajcie ludzi w błąd. Cytat przyklad:
wywołanie normalne: Kod news.php?id=1 news.php?id=25 itd wywołanie zmodyfikowane przez kogostam np. Kod news.php?id=1;DROP%20TABLE%20news; Ee tam, zonwu zonk, przecież mysql_query pozwala na wysłanie tylko jednego zapytania, więc to co pokazałeś nic nie da. Więcej tematu czytać mi się nie chciało, ale mam nadzieję, że nie ma tam dalej więcej bzdur (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) |
|
|
![]()
Post
#89
|
|
Grupa: Zarejestrowani Postów: 2 Pomógł: 0 Dołączył: 5.04.2006 Ostrzeżenie: (0%) ![]() ![]() |
A takie rozwiazanie:
XSS-y wykluczone, ' i " zamieniane na bezpieczne (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) da sie to obejsc? Ten post edytował Pawel86 6.04.2006, 07:51:35 |
|
|
![]()
Post
#90
|
|
Grupa: Zarejestrowani Postów: 40 Pomógł: 0 Dołączył: 24.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Mam taki problem:
Jesli uzyje mysql_real_escape_string i jesli jest wlaczone magic quotes to otrzymam przykladowo ze stringu jakis'wyraz, string jakis///'wyraz. Moglbym zrobic tak:
tylko, że wtedy, jeśli jest wlaczone magic_quotes to stosowanie tej funkcji jest bezsensu - gdy uzyje addslashes wyjdzie na to samo. jak mozna rozwiazac ten problem?? Moze poprostu zostac przy addslashes ? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Ten post edytował Janek111 17.04.2006, 10:54:39 |
|
|
![]()
Post
#91
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Dorzucę się do tego wątku i powiem, że moim zdaniem najlepszym zabezpieczeniem jest: 1. ustawienie w php.ini opcji get_magic_quotes_gpc na ON 2. stosowana równolegle z powyższym funkcja czyszcząca otrzymane dane - od razu uprzedzam, że wbrew nazwie nie dotyczy ona tylko danych przesyłanych metodą POST:
3. Funkcja zapewniająca dodatkowe filtrowanie dla identyfikatorów, przekazywanych w URL'u:
Zastosowanie:
Jakieś uwagi? Pozdrawiam, K Hmm.. Do czego jest właściwie to UNION? Może ktoś poda przykład? Bo ja się nie zetknąłem z takim zapytaniem |
|
|
![]()
Post
#92
|
|
Grupa: Zarejestrowani Postów: 984 Pomógł: 41 Dołączył: 16.03.2002 Skąd: Płock Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#93
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
Próbując podsumować dyskusję, możnaby powiedzieć, że aby zabezpieczyć się przed SQL Injection trzeba filtrować każdą zmienną przychodzącą, czyli:
1. Jeśli spodziewamy się liczby to każdą zmienną traktujemy
2. Jeśli spodziewamy się ciągu to stosujemy
Czy to wystarczy? A co w takim przypadku. Mamy spis użytkowników w systemie, który załóżmy że wygląda tak. (IMG:http://sebo5.w.interia.pl/spis.jpg) Przy każdym użytkowniku jest link z opcją usunięcia konta. Z tym linkiem, przesyłany jest numer ID danego klienta, żeby wiedzieć, którego klienta usunąć z bazy (ID jest kluczem głównym). Teraz ktoś może zmodyfikować URL, np zamiast usunąć konto 2 (http://jakasstrona/usun.php&id=2) może wpisać dowolny inny numer, np (http://jakasstrona/usun.php&id=1) i skasuje konto admina. Jak się przed tym zabezpieczyć? Stosuję w każdym skrypcie funkcję weryfikującą, któa sprawdza czy użytkownik jest zalogowany i czy ma odpowiednie prawa. Ale wiem, że to nie wystarczy. Ten post edytował J4r0d 30.05.2006, 07:24:43 |
|
|
![]()
Post
#94
|
|
Grupa: Zarejestrowani Postów: 44 Pomógł: 0 Dołączył: 11.06.2005 Skąd: Gostyń Ostrzeżenie: (0%) ![]() ![]() |
Wówczas zawsze należy robić dodatkowe confirmy - formularze typu "Czy na pewno chcesz.... [ TAK ] [ NIE ]"
|
|
|
![]()
Post
#95
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#96
|
|
Grupa: Zarejestrowani Postów: 504 Pomógł: 2 Dołączył: 31.03.2006 Skąd: Londyn Ostrzeżenie: (0%) ![]() ![]() |
Wedlug mnie mozesz jedynie sprawdzic czy Id nie jest elementem wyznaczonego przez Ciebie a niedozwolonego zbioru.
Zostaja jedynie confirmy, tutaj wszystko wydaje sie kwestia dostepu. Jesli dasz dostep do tego panelu, to po co meczyc sie ze zmiana URLa skoro wystarczy kliknac (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) No chyba ze kazdy uzytkownik ma inne prawa i innych uzytkownikow ktorych moze edytowac (taka relacja su/admin/sub-admin (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) wtedy wspommniany przezemnie zbior nalezalo by uzaleznic od uzytkowanika. |
|
|
![]()
Post
#97
|
|
Grupa: Zarejestrowani Postów: 367 Pomógł: 10 Dołączył: 20.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
@J4r0d Bardzo prosto się można zabezpieczyć
Zastosuj sume kontrolną. jakasstrona/usun.php&id=2&checksum=f3sxSdf32vx3sGx Napisz własny wzór generowania sumy kontrolnej oraz jej sprawdzania. Np.
Ten post edytował eai 2.08.2006, 00:20:53 |
|
|
![]()
Post
#98
|
|
Grupa: Zarejestrowani Postów: 800 Pomógł: 0 Dołączył: 26.11.2005 Skąd: Nowy Sącz Ostrzeżenie: (0%) ![]() ![]() |
Zgadzam się z Eai. Ja stosuje sumy plus sesje oraz grupy uprawnień. Jeśli użytkownik nie ma odpowiedniego levela odrazu acces denied w głównym pliku administracyjnym. Nie pozwalam nawet dojść do uruchomienia reszty (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .
Co do tego usuwania adminów to banał jest. Dodajemy do filtrowania requestów :
i gotowe (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Czyż nie trudne ? Po za tym thornag używaj głównego pliku administracyjnego przez który jest jedyna możliwość użycia funkcji ACP etc. . To dodatkowe zabezpieczenie i trochę utrudnia życie, ale warto. Dodatkowa bariera dla włamywacza... |
|
|
![]()
Post
#99
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) ![]() ![]() |
@J4r0d Bardzo prosto się można zabezpieczyć Zastosuj sume kontrolną. jakasstrona/usun.php&id=2&checksum=f3sxSdf32vx3sGx Napisz własny wzór generowania sumy kontrolnej oraz jej sprawdzania. Np.
Generujesz - ok. A w jaki sposób chcesz przetrzymywać tą sume i gdzie? |
|
|
![]()
Post
#100
|
|
Grupa: Zarejestrowani Postów: 367 Pomógł: 10 Dołączył: 20.05.2005 Ostrzeżenie: (0%) ![]() ![]() |
@J4r0d Przecież to jest jeszcze prostsze (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Przykład: checksum.php
admin.php
Prościej się wytłumaczyć nie da (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 10:30 |