Dane w bezpiecznych aplikacjach – pisanie i testowanie

Proponowana w mej ostatniej lekturze strategia tworzenia bezpiecznych aplikacji opiera się głównie na podziale danych przetwarzanych przez aplikację na dane bezpieczne i niebezpieczne.

Dane bezpieczne to te, które generujemy we wnętrzu aplikacji (np. sklejanie stringa, obliczenia, generowanie daty itp.). Uwaga jednak na zewnętrzne biblioteki – „w trybie paranoika” również danych pochodzących z bibliotek  nie powinno traktować się jako w 100% zaufane.
Dane niebezpieczne to wszystkie dane pochodzące ze źródeł zewnętrznych: adresy URL (dane, które nadeszły wraz z żądaniem GET), dane w żądaniach typu POST, nagłówki HTTP (cookie), dane z bazy danych, pliki itp.

Opierając się na powyższym podziale, bezpieczeństwo aplikacji można zapewnić poprzez:

  • Skuteczną walidację danych niebezpiecznych. Autor zaleca, by walidacji dokonywać za pomocą funkcji wbudowanych w język (np. is_number) – minimalizujemy wtedy ryzyko popełnienia błędu we własnych funkcjach. Wyrażeń regularnych używamy w ostateczności.
  • Nie opieranie się na interfejsie. To, że w interfejsie aplikacji użyliśmy checkboxa z kilkoma dozwolonymi wartościami nie oznacza, że użytkownik nie spreparuje żądania, przesyłając dane, których się nie spodziewamy.

dane_bezpieczne2

  • Unikanie korzystania z danych niewiadomego pochodzenia (sytuacja, gdy nie wiadomo, czy dana pochodzi z tablicy POST, GET, COOKIE?). W PHP zaleca się wyłączenie dyrektywy register_globals i korzystanie wyłącznie z tablic superglobalnych:
    • $GLOBALS
    • $_SERVER
    • $_GET
    • $_POST
    • $_FILES
    • $_COOKIE
    • $_SESSION
    • $_REQUEST
    • $_ENV
  • Nie poprawianie błędnych danych – zamiast tego lepiej wyświetlić błąd i poprosić użytkownika o ponowne przesłanie danych.
  • Inicjowanie zmiennych wykorzystywanych w aplikacji. Czyli lepiej pisać $something = 0, niż nie pisać nic.
  • Autor zaleca także stosowanie spójnej konwencji nazewniczej, np.: stworzenie osobnej tablicy na:
    • dane przefiltrowane (wejście) – by w dalszych etapach aplikacji sięgać tylko do tych danych
    • dane do wysłania (wyjście) – tuż przed ich wyświetleniem w przeglądarce lub wysłaniem do bazy danych, zostaną one przeformatowane i opatrzone znakami ucieczki.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *