Korzystając ze stron internetowych, użytkownik przesyła bądź odbiera żądania HTTP. Mogą być one parametryzowane wartościami i ich kluczem. Przykładowy request, wyświetlający post, którego id wynosi 213, wyglądać może w poniższy sposób.
https://dummy-domain.com/blog/posts?id=213Dzięki dynamicznej manipulacji parametrami na stronie uzyskujemy bezpośredni dostęp do danych, a jeśli system uprawnień nie został w sposób prawidłowy zaimplementowany, jesteśmy w stanie w sposób nieuprawniony podejrzeć dane, które nie powinny być dla nas dostępne. Wtedy możemy możemy mówić o IDOR.
Używane parametry na stronie możemy uzyskać na kilka sposobów. Należy do nich między innymi:
- przechytywanie żądań za pomocą narzędzia Burpsuite i przeglądanie ich (na samo narzędzie poświęcić trzeba będzie osobny artykuł ;))
- wyklikując kolejne linki na stronie i przeglądając bezpośrednio URI
- używając dorobku pentesterów w postaci gotowych skryptów
Znajdowanie ukrytych parametrów za pomocą skryptu Arjun
Wspomnieliśmy wyżej o gotowych skryptach. Jednym z nich jest Arjun, do którego repozytorium i dokumentacji, odsyłamy tutaj. Jest to narzędzie do wykrywania ukrytych parametrów na konkretnym endpoincie. Do dyspozycji mamy domyślną listę parametrów, w której jest prawie 11 tysięcy słów kluczowych. Ponadto, skan dla niej trwa jedynie około 12 sekund. Przykładowy request, wykorzystujący parametry z pliku common.txt oraz metodę POST dla strony z endpointem /user, wygląda w poniższy sposób.
arjun -u https://dummy-website.com/user -w ./SecList/common.txt -m POSTRodzaje IDOR
Dzięki podatności Insecure Direct Object Reference, możemy uzyskać dostęp do zastrzeżonych danych użytkownika, a w innych przypadkach może prowadzić to do ingerencji w pliki na serwerze. Przyjmuje się podział na cztery główne typy IDOR, ze względu na możliwą wielkość potencjalnych szkód. Często okazuje się, że typy te pokrywają się ze sobą nawzajem.
- Nieaturyzowany dostęp do danych – przez manipulowanie parametrami, atakujący jest w stanie dotrzeć do wrażliwych danych aplikacji, takich jak dokładne informacje o użytkowniku,
- Manipulowanie wewnętrznym stanem aplikacji – polega ono na zmianie danych wewnętrznych serwera. Przykładem może być wstrzyknięcie XSS,
- Wykonanie nieautoryzowanych operacji – manipulując parametrami, jesteśmy w stanie wykonywać nieautoryzowane operacje w aplikacji. Dzięki temu jesteśmy w stanie na przykład uzyskać stały dostęp do konta innych użytkowników,
- Bezpośredni dostęp do plików serwera – pozwala nam na przeglądanie oraz edycję plików serwera. Dzięki temu możemy uzyskać z bazy danych informacje o hasłach użytkowników. Jakie to niesie za sobą skutki – nie trzeba wyjaśniać.
Kilka przykładów
Użytkownik Rahul Varale w jednym ze swoich postów opisuje sytuację, w której uzyskał informacje o wszystkich użytkowikach dzięki manipulacji parametrem address_id.
Przykład wykorzystania błędu IDOR, świadczący o tym, że warto analizować pliki .js, ponieważ mogą zawierać elementarne informacje. Docelowo, błąd skutkował przejęciem konta innego użytkownika.
Ciekawy przykład, który potwierdza tylko, że należy kilkukrotnie przeprowadzić retesty załatanej luki. Błąd uprzednio znaleziony został naprawiony na endpoincie z metodą GET. Zapomniano jednak o POST 🙂
Źródła
https://www.netsparker.com/blog/web-security/insecure-direct-object-reference-vulnerabilities-idor/
https://www.geeksforgeeks.org/insecure-direct-object-reference-idor-vulnerability/
https://mayank-01.medium.com/an-interesting-account-takeover-3a33f42d609d
https://rahulvarale.medium.com/idor-vulenebility-with-empty-response-still-exposing-sensitive-details-of-customers-bdce0a6a1b07
https://infosecwriteups.com/how-i-made-it-to-google-hof-f1cec85fdb1b