Wykonanie ataku fałszerstwa żądania między

Wykonanie ataku fałszerstwa żądania między
Atak CSRF to ten, który sprawia, że ​​uwierzytelnieni użytkownicy wykonują niechciane działania w aplikacji internetowej, z którą są uwierzytelniani. Odbywa się to za pośrednictwem strony zewnętrznej, którą odwiedza użytkownik i która uruchamia te działania.

W tym artykule uzyskasz wymagane informacje z aplikacji, aby dowiedzieć się, co powinna zrobić strona atakująca, aby wysłać prawidłowe żądania na serwer wrażliwy. Następnie utworzysz stronę, która symuluje uzasadnione żądania i oszukuje użytkownika do odwiedzenia tej strony podczas uwierzytelniania. Zrobisz także kilka iteracji na podstawowym dowodzie koncepcji, aby wyglądał bardziej jak atak rzeczywistego, w którym ofiara tego nie zauważa. Zauważ, że plik kodu dla tego artykułu można znaleźć w GitHub autora.

Przygotowywanie się

Do tego artykułu potrzebujesz prawidłowego konta użytkownika w Bodgeit. Ten artykuł używa Użytkownik@przykład.com Jako ofiara:

Jak to zrobić…

Najpierw musisz przeanalizować żądanie, które chcesz zmusić ofiarę do złożenia. Aby to zrobić, potrzebujesz pakietu Burp lub innego proxy skonfigurowanego w przeglądarce:

  1. Zaloguj się do Bodgeit jako każdego użytkownika i kliknij nazwę użytkownika, aby przejść do profilu.
  2. Dokonaj zmiany hasła. Zobacz, jak wygląda żądanie w proxy:

    Więc to jest POST poprosić o http: // 192.168.56.11/bodgeit/hasło.Jsp, i ma tylko hasło i jego potwierdzenie w ciele.

  3. Spróbuj stworzyć bardzo prostą stronę HTML, która replikuje to żądanie. Utwórz plik (nazwij go CSRF-Change-Password.html) Z następującymi treściami:







  4. Teraz załaduj ten plik w tej samej przeglądarce, co sesja zalogowana:
  5. Kliknij Prześlij, a zostaniesz przekierowany na stronę profilu użytkownika. Powie ci, że hasło zostało pomyślnie zaktualizowane.
  6. Chociaż dowodzi to, strona zewnętrzna (lub lokalna strona HTML, jak w tym przypadku) może wykonać żądanie zmiany hasła w aplikacji. Nadal jest mało prawdopodobne, aby użytkownik kliknie Składać Możesz go zautomatyzować i ukryć pola wejściowe, aby złośliwa treść była ukryta. Teraz zrób nową stronę opartą na poprzedniej; nazwać CSRF-Change-Pass-Sword Scriptted.html:


    Całkowicie nieszkodliwa strona


    Możesz zaufać tej stronie.
    Nic złego nie stanie się z tobą ani Twoim konto Bodgeit.





    Tym razem formularz ma parametr identyfikacyjny i na stronie znajduje się skrypt, który przesyła jej zawartość, gdy strona zostanie całkowicie załadowana.

  7. Jeśli załadujesz tę stronę w tej samej przeglądarce, w której zainicjujesz sesję bodgeit, automatycznie wyśle ​​żądanie, a strona profilu użytkownika wyświetli się później. Na poniższym zrzucie ekranu przeglądarki DebuggerUstaw punkt przerwania tuż przed złożeniem wniosku:
  8. Ta ostatnia próba wygląda lepiej z perspektywy atakującego. Potrzebujesz tylko ofiary, aby załadować stronę, a żądanie zostanie wysłane automatycznie, ale wtedy ofiara zobaczy Twoje hasło zostało zmienionewiadomość, a to z pewnością podniesie ostrzeżenie.
  9. Możesz dodatkowo ulepszyć stronę atakującą, zmuszając ją do załadowania odpowiedzi w niewidzialnej ramce wewnątrz tej samej strony. Istnieje wiele sposobów na to; Szybki i brudny jest ustawienie rozmiaru 0 na ramkę. Twój plik wyglądałby tak:


    Całkowicie nieszkodliwa strona


    Możesz zaufać tej stronie.
    Nic złego nie stanie się z tobą ani Twoim konto Bodgeit.
    Target = "celle_frame">





    Zwróć uwagę, w jaki sposób właściwość docelową formularza jest iframe zdefiniowana tuż pod nim i że taka ramka ma 0%wysokości i szerokości.

  10. Załaduj nową stronę w przeglądarce, w której zainicjowano sesję. Ten zrzut ekranu pokazuje, jak wygląda strona podczas kontroli z przeglądarką Narzędzia deweloperskie: Zauważ, że obiekt IFRAME to tylko czarna linia na stronie, a w inspektorze widać, że zawiera stronę profilu użytkownika Bodgeit.
  11. Jeśli przeanalizujesz komunikację sieciową podjętą przez twoją stronę CSRF, możesz zobaczyć, że faktycznie składa prośby o zmianę hasła Bodgeit:

Jak to działa…

Kiedy wysyłasz żądanie z przeglądarki i już masz przechowywanie pliku cookie należące. To właśnie sprawia, że ​​pliki cookie są tak wygodne jak identyfikatory sesji, ale ta cecha działania HTTP jest również tym, co sprawia, że ​​jest podatny na atak taki jak ten, który widziałeś w tym artykule.

Po załadowaniu strony w tej samej przeglądarce, w której masz aktywną sesję w aplikacji, przeglądarka automatycznie podłączy sesję plik cookie do tego żądania. Dzieje się tak, nawet jeśli jest to inna karta lub okno, a ta strona prosimy do domeny, w której sesja jest inicjowana.

Jeśli serwer nie weryfikuje, że otrzymane żądania faktycznie pochodzą z aplikacji, pozwala złośliwej witrynie wykonywać połączenia w imieniu legalnych, aktywnych użytkowników, którzy odwiedzają tę złośliwą witrynę, uwierzytelniając się w domenie docelowej.

W teście penetracji aplikacji internetowych, pierwszy użyty kod, ten z dwoma pola tekstowym i Składać przycisk może wystarczyć, aby zademonstrować obecność wady bezpieczeństwa. Jednak testy penetracji aplikacji może być częścią innego zaangażowania, takiego jak inżynieria społeczna lub ćwiczenie zespołu czerwonego. W takim przypadku wymagane będą dodatkowe wysiłki, aby uniemożliwić ofiarę podejrzewanie, że coś się dzieje.

W tym artykule użyłeś JavaScript do automatyzacji wysyłania żądania, ustawiając zdarzenie Onload na stronie i wykonując metodę przesłania formularza w funkcji obsługi zdarzenia. Użyłeś również ukrytej iframe, aby załadować odpowiedź zmiany hasła, więc ofiara nigdy nie widzi wiadomości, że jego hasło się zmieniło.

Jeśli uznałeś ten artykuł interesujący, możesz odkryć KALI LINUX PERETRACJA TESTOWA Książka kucharska - Drugie wydanie odkryć najczęstsze luki w sieci i zapobiec ich zagrożeniu dla bezpieczeństwa Twojej witryny. KALI LINUX PERETRACJA TESTOWA Książka kucharska - Drugie wydanie daje umiejętności potrzebne do pokrycia każdego etapu testu penetracyjnego - od gromadzenia informacji o systemie i aplikacji do identyfikacji luk w zabezpieczeniach poprzez testowanie ręczne.