Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 27

4.
CROSS-SITE REQUEST FORGERY
CSRF przez żądanie GET

Оглавление

Sposób, w jaki złośliwa strona wykorzystuje stronę bankową Boba, zależy od tego, czy bank akceptuje przelewy przez żądania GET, czy POST. Jeśli strona bankowa Boba akceptuje przelewy przez żądanie GET, złośliwa strona wyśle żądanie HTTP z ukrytym formularzem, bądź znacznikiem <img>. Zarówno metoda GET, jak i POST opierają się na tym, aby dzięki odpowiedniemu kodowi HTML przeglądarka wysłała wymagane żądanie HTTP, oraz obie metody mogą użyć techniki ukrytego formularza, lecz tylko z metodą GET można użyć techniki tagów <img>. W tej części przyjrzymy się działaniu ataku, który korzysta ze sposobu tagu <img> przez żądanie GET, natomiast techniką z użyciem ukrytego formularza zajmiemy się w kolejnej części, „CSRF przez żądanie POST”.

Atakujący musi umieścić pliki cookies Boba w każdym żądaniu HTTP do strony bankowej. Ponieważ jednak nie ma żadnego sposobu na odczytanie plików Boba, atakujący nie może po prostu stworzyć żądania HTTP i wysłać go na stronę. Zamiast tego może on użyć tagu <img> do utworzenia żądania GET, które będzie już mieć wymagane pliki cookies Boba. Tag <img> wyświetla zdjęcia na stronie internetowej i zawiera atrybut src, który określa lokalizację plików ze zdjęciami. Kiedy przeglądarka wyrenderuje tag <img>, wykona ona żądanie HTTP GET na adres opisany w atrybucie src oraz umieści w tym żądaniu wszystkie istniejące pliki cookies. Powiedzmy zatem, że złośliwa strona w celu wykonania przelewu 500 $ od Boba do Joe wykorzystuje poniższy URL:

https://www.bank.com/transfer?from=bob&to=joe&amount=500

Tag <img> użyje tego adresu jako wartość atrybutu src, tak jak poniżej:

<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">

W wyniku tego, gdy Bob odwiedza stronę atakującego, w swojej odpowiedzi HTTP będzie ona zawierać złośliwy tag <img>, a zatem przeglądarka wykona żądanie GET do banku. Przeglądarka wysyła pliki uwierzytelniające w celu otrzymania tego, co uważa za obraz. W rzeczywistości jednak bank otrzymuje żądanie, przetwarza URL zawarty w atrybucie src i wykonuje żądanie przelewu.

By uniknąć tej podatności, deweloperzy nigdy nie powinni korzystać z żądań GET w celu wykonania jakichkolwiek żądań modyfikujących dane, takich jak przelewanie pieniędzy. Jednak jakiekolwiek żądanie, które służy jedynie do odczytu, powinno być bezpieczne. Wiele popularnych frameworków używanych w budowie stron internetowych, takich jak Ruby on Rails, Django i tak dalej, odgórnie oczekuje od programistów przestrzegania tej zasady, zatem automatycznie dodają one zabezpieczenia CSRF do żądań POST, ale nie do żądań GET.

Na tropie błędów. Przewodnik hakerski

Подняться наверх