Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Sens tworzenia własnych systemów filtracji

Do potrzeby filtracji danych pochodzących od użytkownika nie trzeba nikogo przekonywać. Pytaniem, które rodzi się podczas pisania systemu filtracji jest sposób, w jaki należy to robić, by system był bezpieczny. Podczas tego procesu możemy korzystać z udogodnień, które udostępniają języki programowania, a także pisać własne rozwiązania. Jednak czy warto to robić?

Cel tworzenia własnego systemu filtracji danych.

Faktem, który świadczy o pisaniu własnych systemów filtracji nie korzystając z funkcji natywnych może być to, że każda aplikacja jest inna, każda korzysta z innych danych. System rejestracji biletów lotniczych operuje na danych pasażerów oraz lotów, system obsługi biblioteki na książkach. Dane te są teoretycznie różne, jednak jest coś, co je łączy. Są one typami prostymi (cyfry, litery). Skoro więc zawsze mamy do czynienia z typami prostymi, po co tworzyć filtracje opierając się na własnych algorytmach? Mamy przecież funkcje natywne.

Sprawdzanie typów danych.

W PHP mamy wiele funkcji umożliwiających sprawdzenie typu zmiennych. Możemy korzystać np. z funkcji is_* (is_int, is_string), lecz istnieje lepsze rozwiązanie mianowicie ctype. Różnica polega na tym, że funkcje z rodziny ctype korzystają z natywnej biblioteki języka C do weryfikacji typów co zapewnia znaczący wzrost szybkości.

Jeśli chcemy weryfikować typy danych złożone z typów prostych (np. poprawność daty, kodu pocztowego) możemy skorzystać z wyrażeń regularnych. W PHP mamy możliwość korzystania z dwóch rodzajów wyrażeń regularnych – POSIX (ereg*) oraz kompatybilnych z wyrażeniami PERL’a (preg_*). Zalecane jest korzystanie z tych drugich ze względu na większe możliwości oraz szybsze działanie.

Co ważne, podczas korzystania z wyrażeń regularnych należy wziąć pod uwagę dwie rzeczy.

  • Funkcja eregi nie radzi sobie z danymi binarnymi – bajt zerowy traktuje jako koniec łańcucha.
  • Funkcja preg_match ma problemy z łańcuchami, które zawierają znak nowego wiersza.

Filtracja niebezpiecznych danych.

Jeśli już sprawdziliśmy czy przekazane dane mają poprawne typy, możemy przystąpić do filtracji ich zawartości. Zdecydowana większość błędów aplikacji internetowych, to podatność na wstrzyknięcia. Możemy im zaradzić korzystając z funkcji strip_tags (HTML Injection) oraz *_real_escape_string (SQL Injection)1

Warto zajrzeć


Tagi:
Kategoria: Bezpieczeństwo, Filtracja i walidacja


8 komentarzy

  1. pawkow napisał(a):

    bo filtracja jest najważniejsza :)

  2. Michał `Bełdzio` Ławicki napisał(a):

    No tak, ale nikt tu nie mówi, że mamy nie filtrować danych. Chodzi o to, że 99% własnych mechanizmów filtrowania danych nie ma sensu.

  3. lpilorz napisał(a):

    Dla uzupełnienia:is_int() sprawdza typ zmiennej, a nie zawartość, więc dla danych GET/POST/COOKIE zawsze zwróci false (mają typ string/array). Trzeba byłoby najpierw rzutować zmienną na typ int, a wtedy i tak jest na pewno czysta, więc przy filtrowaniu danych is_int() nie ma raczej zastosowania. Najbardziej wydajne i skuteczne jest rzutowanie.Zamiast strip_tags() sugerowałbym:- mb_convert_encoding() lub iconv() dla poprawienia kodowania- htmlspecialchars()+ENT_QUOTES dla zamiany na encje- całkowite usunięcie znaków specjalnych (w tym nawiasów, średników, nowych linii itp.) w przypadku zmiennych wstawianych do javascriptu w atrybutach HTML (np. onclick, onload)

  4. Michał `Bełdzio` Ławicki napisał(a):

    1. is_int() nie, ale już is_numeric tak :-)2. czemu zamiast strip_tags chcesz konwertować?3. jeśli chodzi o usuwanie konkretnych zestawów znaków to jestem za wyrażeniami regularnymi :) dzięki za komentarz :)

  5. lpilorz napisał(a):

    Wcięło nowe linie, dlatego komentarz do strip_tags() może być niejasny. Zastanawiam się, jak Twój system potraktuje ten komentarz ;) Chodziło mi o zastąpienie tej funkcji taką, która wykonuje następujące trzy akcje:1. poprawia kodowanie – po to, aby uniknąć błędu w IE (na http://lukasz.pilorz.net/index.php/2007/04/01/xss-hackme-zwyciezca-i-rozwiazania/ w rozwiązaniu do trzeciego skryptu)2. zamienia znaki specjalne na encje – po to, żeby bezpieczne były również atrybuty HTML (test, itp.)3. opcjonalnie usuwa znaki specjalne, jeśli chcemy wykorzystać zmienną w atrybutach on* (tutaj nie podam przykładu)

  6. Michał `Bełdzio` Ławicki napisał(a):

    ok teraz wszystko rozumiem :) i oczywiście przyznaję rację :)

  7. stopek napisał(a):

    tak nawiasem . jesli uzytkownik przy rejestracji ma opcje select,radio lub checkbox .. to moze dowolnie manipulowc ta zawartoscią? te zmienne tez musze filtrowac tak?

  8. tak mozna, jesli chodzi o manipulacje kodem HTML to polecam zapoznanie się z wtyczką FireBug do FireFoxa, która umożliwia pełną edycję zarówno kodu HTML jak i CSS / JS

    a filtrowane powinny być wszystkie dane, które pochodzą z zewnątrz

Dodaj komentarz