IDOR w nowoczesnych aplikacjach

W świetle obowiązujących w Polsce oraz na terenie wszystkich unijnych państw przepisów GDPR (ang. General Data Protection Regulation) dotyczących ochrony danych osobowych wszystkie nowoczesne aplikacje muszą zostać odpowiednio zabezpieczone. Pomóc mogą w tym oczywiście profesjonaliści z branży cyberbezpieczeństwa albo doświadczeni testerzy z działu QA. Warto tu jednak zaznaczyć, iż dużo bardziej istotną rolę w kontekście bezpieczeństwa odgrywa kod źródłowy wraz z całą logiką aplikacji. Niestety nawet najlepiej zabezpieczone na pierwszy rzut oka aplikacje narażone mogą być na ataki typu IDOR, które wykorzystują w złośliwy sposób błędy w logice biznesowej. Czym jest IDOR? Czy oprogramowanie wykorzystywane do wykrywania IDOR-ów jest bezpieczne? Jak zabezpieczyć się przed atakami i błędami typu IDOR? Na wszystkie te pytania odpowiadamy w poniższym artykule.

Czym jest IDOR?

Insecure Direct Object Reference (IDOR) to w dosłownym tłumaczeniu niezabezpieczone bezpośrednie odwołanie do obiektu. Termin ten odnosi się przede wszystkim do występujących w aplikacjach błędów w logice biznesowej, ale warto zwrócić tu uwagę, że termin IDOR wykorzystywany może być także w kontekście rodzaju cyberataku. To, czym jest IDOR, najprościej wyjaśnić można na podstawie przykładów obrazujących najczęściej występujące błędy typu Insecure Direct Object Reference. Jednym z najprostszych do wychwycenia gołym okiem IDOR-ów jest możliwość manipulacji adresem URL. Prowadzić to może przykładowo do sytuacji, w których użytkownik modyfikuje ID (lub inny dowolny parametr) w adresie strony i uzyskuje dostęp do danych innego konta. Wiele osób nie zdaje sobie sprawy z tego, jak łatwo manipulować można żądaniami HTTP, które w każdej aplikacji przeglądarkowej sprowadzać się będą do 4 rodzajów akcji (GET, POST, PUT, DELETE). Problem pojawia się wtedy, gdy logika biznesowa aplikacji pozwala użytkownikom na manipulowanie danymi i żądaniami. Podczas projektowania i tworzenia profesjonalnych aplikacji biznesowych programiści powinni zadbać by odwołania do obiektów takich, jak klucze SSH, hasła czy nazwy plików w katalogu nie były nigdy widoczne po stronie frontendu. Niestety początkujący lub mniej doświadczeni developerzy często zapominają o stosowaniu odpowiednich modyfikatorów dostępu po stronie backendu. Problematyczne pod kątem IDOR-ów mogą być także aplikacje, które z nieuzasadnionego rozsądnie powodu przetwarzają wrażliwe dane po stronie klienta.

Jakie narzędzia pomagają wykrywać Insecure Direct Object Reference?

Jednym z najpopularniejszych narzędzi, wykorzystywanych zarówno przez testerów odpowiedzialnych za przebieg testów penetracyjnych, jak i też cyberprzestępców jest BURP Suite. Oprogramowanie to pozwala dokładnie monitorować cały ruch sieciowy, dzięki czemu dokładnie prześledzić można wszystkie żądania HTTP. W dużym uproszczeniu BURP Suite tworzy lokalny serwer proxy, przez który następnie przekierowany zostaje cały ruch z przeglądarki, co pozwala nie tylko na wyświetlanie żądań, ale także i modyfikowanie ich parametrów. Niestety program ten wykorzystywany jest przez również cyberprzestępców i hakerów do manipulowania żądaniami HTTP i nadużywania błędów w niezabezpieczonych lub niedopracowanych aplikacjach. Warto wspomnieć też, iż oprogramowanie BURP Suite w bezpłatnej wersji zostało wcielone do dedykowanych cyberbezpieczeństwu dystrybucji systemów operacyjnych takich jak Kali Linux czy Parrot OS. 

Insecure Direct Object Reference – jakie działania prewencyjne mogą się przydać?

Jak już wspomnieliśmy, do wykrywania IDOR-ów wykorzystać można oprogramowanie takie jak BURP Suite czy Postman. Starając się zminimalizować ryzyko wystąpienia błędów i luk tego rodzaju warto poświecić też więcej czasu i zasobów na Code Review. Zaangażowanie większej liczby testerów i developerów w proces inspekcji kodu zwiększa prawdopodobieństwo tego, iż IDOR zostanie szybko wyłapany i naprawiony. Z perspektywy prewencji opłaca się wyczulić programistów na nieobecność modyfikatorów dostępu oraz to, w jakich miejscach i w jaki sposób przetwarzane są wrażliwe dane. Warto również upewnić się, czy wszystkie obiekty, do których istnieją odniesienia, zostały sprawdzone pod kątem potencjalnego IDOR-a. Niezabezpieczone bezpośrednie odwołania do obiektów pojawić się mogą także na skutek przeprowadzanych po łebkach napraw, aktualizacji i zmian. Bardzo istotne jest również to, by testy penetracyjne i badania pod kątem obecności IDOR-ów prowadzone były zarówno z poziomu kont o niskich przywilejach (np. zwykły użytkownik), jak i też tych o podwyższonych (np. konta premium lub administrator). Działanie to ma na celu zminimalizowanie ryzyka sytuacji, w której IDOR wykorzystywany jest do eskalacji uprawnień.

Insecure Direct Object Reference – podsumowanie

Zdawać by się mogło, iż do wykrywania błędów i luk typu Insecure Direct Object Reference potrzebna może być wręcz nieziemska cierpliwość, ale w praktyce dzięki odpowiednim narzędziom oraz doświadczeniu testerów penetracyjnych można ten proces znacznie przyśpieszyć. Niezabezpieczone bezpośrednie referencje obiektowe traktować należy przede wszystkim jako karygodny błąd w logice biznesowej aplikacji. Pomimo że na pierwszy rzut oka IDOR-y nie wpływają w żadnym stopniu na funkcjonalność danego rozwiązania, trzeba je jak najszybciej załatać, ponieważ wcześniej lub później zostaną one wykryte i wykorzystane przez cyberprzestępców albo mniej uczciwych użytkowników.