Dla builderów i zespołów no-code
Zbudowałaś aplikację. Sprawdź, czy nie wystawiłaś danych.
Narzędzia pozwalają dziś postawić działający system w tydzień. Nie pilnują przy tym, kto zobaczy czyje dane. To jest dokładnie ta luka, którą zamykamy przed publikacją.
01
Jak wygląda taki problem naprawdę
Nie chodzi o teorię ataku. Chodzi o jedno zapytanie, które nie powinno zadziałać, a działa.
Aplikacja obsługuje wielu klientów w jednej bazie. Interfejs pokazuje każdemu tylko jego dane, bo tak napisano zapytanie. Ale baza nie ma własnej reguły, która by tego pilnowała.
Wystarczy, że ktoś zalogowany zapyta bazę bezpośrednio, z pominięciem interfejsu. Klucz do tego zapytania jest w przeglądarce, bo musi tam być.
Zapytanie poniżej wykonał użytkownik z konta A, pytając o dane konta B. Powinien dostać pustą odpowiedź albo odmowę. Dostał dane.
tenant_a → GET /rest/v1/invoices?owner=eq.tenant_b
200 OK · 148 rekordów · polityka odczytu: brak
tenant_a → GET /rest/v1/invoices?owner=eq.tenant_b
200 OK · 0 rekordów · polityka: invoices_select_own
02
Co sprawdzamy
01
Granice danych
Czy reguły dostępu istnieją na każdej tabeli i czy domykają odczyt, zapis, zmianę i usunięcie. Sam odczyt to za mało.
02
Uwierzytelnianie
Kto może się zalogować, co widzi po zalogowaniu, czy da się podnieść sobie uprawnienia i czy wylogowanie faktycznie kończy sesję.
03
Sekrety
Czy klucz z pełnym dostępem do bazy nie trafił do przeglądarki, do repozytorium albo do logów.
04
Pliki
Czy załączniki mają politykę dostępu, czy adresy są przewidywalne i czy da się pobrać cudzy plik przez podmianę identyfikatora.
05
Publiczna powierzchnia
Co system pokazuje bez logowania: trasy testowe, panele debugowania, stare wersje API, źródła z komentarzami.
06
Zależności
Czy używane biblioteki mają znane podatności i czy któraś z nich sięga gdzieś, gdzie nie powinna.
03
Jak to przebiega
- Zgłaszasz aplikację i mówisz, do czego służy i czyje dane trzyma.
- Ustalamy zakres i to, co nam udostępniasz. Domyślnie tylko odczyt.
- Sprawdzamy. Nic nie zmieniamy w Twoim systemie.
- Dostajesz listę blokad publikacji, oddzieloną od rzeczy, które mogą poczekać.
- Do każdej blokady jest konkretna poprawka, nie ogólnik.
- Po naprawie robimy ponowny test i dopisujemy wynik do raportu.
04
Czego się nie spodziewaj
To nie jest pełny test penetracyjny
Sprawdzamy konkretny, opisany zakres. Wszystko poza nim jest wypisane w raporcie jako nietestowane, a nie przemilczane.
Nie powiemy, że aplikacja jest bezpieczna
Powiemy, co sprawdziliśmy, co znaleźliśmy, czego nie dało się ustalić i na jaki dzień to jest aktualne. Reszta to marketing.
Lepiej dowiedzieć się teraz niż od klienta
Napisz, co zbudowałaś i czyje dane to trzyma. Odpowiemy, co da się sprawdzić i ile to zajmie.