Pięć rzeczy, które wychodzą w aplikacjach zbudowanych szybko

Skąd się to bierze

Narzędzia pozwalają dziś postawić działający system w tydzień. Robią to dobrze: baza, logowanie, przesyłanie plików i interfejs powstają z gotowych klocków.

Czego nie robią, to pilnowanie, kto zobaczy czyje dane. To zostaje po stronie osoby, która składa aplikację, i to jest dokładnie ta część, o której najłatwiej zapomnieć, bo aplikacja bez niej wygląda na działającą.

Poniższa piątka to nie są rzadkie przypadki. To jest to, co wychodzi najczęściej.

1. Reguła dostępu istnieje, ale nie na każdej tabeli

Typowy przebieg: ktoś włącza kontrolę dostępu na tabeli z zamówieniami, bo to oczywiste. Tabela z fakturami, dodana trzy tygodnie później, zostaje bez reguły.

Interfejs tego nie pokazuje, bo interfejs pyta bazę o dane zalogowanego użytkownika. Problem widać dopiero wtedy, gdy ktoś zapyta bazę bezpośrednio, z pominięciem interfejsu. Klucz potrzebny do takiego zapytania jest w przeglądarce, bo musi tam być.

Jak sprawdzić: wypisz wszystkie tabele i przy każdej zaznacz, czy ma regułę. Nie pytaj kodu, pytaj bazy. Lista tabel bez reguł to lista otwartych drzwi.

2. Reguła domyka odczyt, ale nie zapis

Druga wersja tego samego problemu, trudniejsza do zauważenia. Reguła na odczyt jest, więc test „czy widzę cudze dane” wychodzi na zielono i wszyscy są spokojni.

Tymczasem zapis i zmiana są osobnymi operacjami z osobnymi regułami. Bez reguły na zmianę da się wziąć własny wiersz i przepisać go do cudzego konta, albo odwrotnie.

Jak sprawdzić: dla każdej tabeli sprawdź cztery operacje osobno, nie jedną. Zielony odczyt niczego nie dowodzi o zapisie.

3. Klucz z pełnym dostępem trafia do przeglądarki

Większość systemów ma dwa klucze: publiczny, który wolno pokazać, i serwisowy, który omija wszystkie reguły dostępu.

Klucz serwisowy trafia do przeglądarki zwykle jedną z dwóch dróg. Albo przez widok administracyjny, gdzie ktoś potrzebował „szerszego dostępu na chwilę”. Albo przez zmienną środowiskową nazwaną tak, że narzędzie budujące uznało ją za publiczną.

To jest najgorszy z tej piątki, bo unieważnia wszystkie pozostałe zabezpieczenia. Można mieć idealne reguły dostępu i nie mieć z nich nic.

Jak sprawdzić: otwórz aplikację, wejdź w źródła załadowane przez przeglądarkę i poszukaj w nich fragmentu swojego klucza serwisowego. Zajmuje to dwie minuty.

4. Załączniki bez reguły i z przewidywalnym adresem

Pliki idą do osobnego magazynu, który ma własne reguły dostępu, i to jest ten moment, w którym łatwo je pominąć.

Sytuacja robi się poważna, gdy nazwy plików powstają z kolejnego numeru. Wtedy nie trzeba niczego zgadywać: wystarczy zmniejszyć numer w adresie o jeden.

Jak sprawdzić: pobierz własny załącznik, zmień numer w adresie i powtórz żądanie. Jeśli plik się pobiera, masz odpowiedź.

5. Trasy, o których nikt już nie pamięta

Panel diagnostyczny, trasa testowa, stara wersja interfejsu programistycznego, adres do sprawdzania stanu bazy. Powstają w trakcie budowania i zostają po wdrożeniu.

Same w sobie rzadko ujawniają dane klientów. Ułatwiają za to rozpoznanie systemu i czasem zdradzają nazwy zmiennych albo wersje bibliotek.

Jak sprawdzić: wypisz wszystkie trasy, które aplikacja obsługuje, i przy każdej odpowiedz, czy ma prawo działać bez logowania. Jeśli nie potrafisz uzasadnić, dlaczego jest publiczna, prawdopodobnie nie powinna być.

Czego ta lista nie obejmuje

To jest piątka najczęstsza, nie komplet. Nie ma tu podatności w bibliotekach, błędów w logice biznesowej, problemów z sesją ani niczego, co dotyczy odporności na obciążenie.

Przejście tej listy nie znaczy, że aplikacja jest bezpieczna. Znaczy, że nie ma pięciu najczęstszych problemów. To dwie różne rzeczy i warto je rozróżniać, zwłaszcza w rozmowie z klientem.