Wprowadzenie

Każdy system komputerowy został stworzony do przetwarzania danych, a strony internetowe nie są tu wyjątkiem. Możesz doświadczyć przetwarzania danych na co dzień - przewijając swoje ulubione media społecznościowe lub sprawdzając faktury od dostawcy energii elektrycznej. Wiele systemów posiada rozwiązania w zakresie przechowywania danych, a w wielu przypadkach polegają one na bazie danych z identyfikatorami auto-inkrementingowymi na prawie każdej tablicy. Strony internetowe są dostępne pod adresami URL, co może powodować problemy z bezpieczeństwem...

Problem

URL jest często integralną częścią API serwisu i jest używany jako interfejs do danych serwisu. Kilka prostych przykładów to między innymi: - GET /invoices/47833 - GET /articles/7983 - GET /users/9908

Widzisz tu jakieś problemy? Tak - ekspozycja danych!

Jeśli jesteś firmą, Twoja konkurencja może teraz odkryć Twoje wewnętrzne dane - przynajmniej wielkość Twojej firmy. Patrząc na URL GET /users/9908 (/users/{id}), mogą łatwo zmienić go na GET /users/1, a jeśli to pokazuje dane, mogą założyć, że w Twoim systemie jest co najmniej 9908 użytkowników. Przy pomocy łatwego skryptu/Postman można iterować* nad podanym adresem URL (++id) i zliczać co 200 odpowiedzi, aby uzyskać całkowitą liczbę użytkowników. Oprócz ujawnienia liczby użytkowników lub faktur, kolejnym problemem mogą stać się Twoje skończone zasoby. Wyobraź sobie, że masz stronę e-commerce z niestandardowymi/niezwykłymi zdjęciami artykułów, które mogą być łatwo pobrane przez iterację nad adresami URL związanymi z danym artykułem.

*zabronione możliwe wykorzystanie mechanizmów bezpieczeństwa (zliczanie/ograniczanie możliwych adresów URL połączeń z jednego klienta/adresu IP itp.)

Rozwiązanie

Co można zrobić, aby uniknąć ekspozycji danych lub bezpośredniego pobierania bazy danych? Jednym z możliwych rozwiązań jest zaciemnienie ID - możesz ukryć swoje przewidywalne 1, 2, 3, ... ID jako mniej przewidywalne ciągi, np. 216 -> X46dBNxd79 lub 315 -> 4w9aA11avM. Będzie to utrudniać prostą operację id++. Jak? Jednym z moich pierwszych odkryć była biblioteka hashidów, dostępna dla JavaScript, Ruby, Python, Java, Scala, PHP i innych. Jako że jestem programistą PHP i Symfony, stworzyłem pakiet HashId, aby uprościć proces zaciemniania parametrów URL z hashidami jako domyślnym enkoderem/dekoderem (obfuscator). Moim pierwszym wymaganiem było, aby nie modyfikować wywoływania metod generowania adresów URL w szablonach lub kontrolerach Twig. Wymaganie to zostało spełnione poprzez uruchomienie {{{ url('route_name', {'id': 1}) }} w szablonie twig lub $this->generateUrl('route_name', ['id' => 1]); w kontrolerze. Biblioteka haszyszowa będzie wystarczająca dla niektórych projektów, ale nie jest tak bezpieczna; można ją łatwo zastąpić np. malutkim obfuscatorem lub robionym na zamówienie. Innym możliwym rozwiązaniem, które prowadzi do ukrycia poufnych danych jest użycie UUID - uniwersalnego unikalnego identyfikatora. Będzie to preferowane rozwiązanie w niektórych scenariuszach, ale wymaga dodatkowych zmian w bazie danych, które wprowadzają nowe kolumny do przechowywania UUID-ów.