Paweł Goleń, blog

Cross-site request forgery i Clickjacking

Na temat CSRF pisałem wiele razy, przygotowałem też kilka przykładów. Można się z nimi zapoznać tu:

• Lekcja 4: Cross Site Request Forgery
• Lekcja 5: Cross Site Scripting i Cross Site Request Forgery

Istotą Cross-Site Request Forgery jest skłonienie przeglądarki ofiary do wysłania żądania, które zrobi coś w atakowanej aplikacji. Prostym i skutecznym sposobem ochrony jest dołączenie do żądania losowego tokenu, który jest weryfikowany przez aplikację. Jeśli jest nieprawidłowy, aplikacja nie wykonuje żądanej aplikacji. Atakujący nie może przeprowadzić ataku CSRF jeśli nie jest w stanie przygotować prawidłowego żądania, a nie jest w stanie go przygotować, bo nie zna losowej wartości tokenu.

W drugim z przywoływanych wcześniej przykładów pokazuję, że zabezpieczenie to może być nieskuteczne, jeśli atakujący jest w stanie umieścić swój kod na atakowanej stronie, na przykład z wykorzystaniem podatności cross-site scripting. Jeśli nie ma XSS, ale do dyspozycji pozostaje clickjacking.

Clickjacking i X-FRAME-OPTIONS

Aplikacja, na której chcę pokazać clickjacking, jest bardzo prosta. Dostępna jest pod adresem: http://bootcamp.threats.pl/lesson15/demo.php. Jej jedyna funkcja to zliczanie kliknięć (przycisk Wyślij). Aplikacja ta jest zabezpieczona przed CSRF, wykorzystuje losowy token, o którym wspominałem wcześniej. Głos nie zostanie zaliczony, jeśli token nie jest prawidłowy lub gdy go brakuje. Przy okazji tematu tokenu mała dygresja: Lekcja 22: Improper Initialization.

Pora na demonstrację. Przykład powinien działać w Firefox oraz Chrome, nie wiem jak z Internet Explorer, nie doszedłem do porozumienia z nim i kwestią przezroczystości.

Bez X-FRAME-OPTIONS

Pierwszy przykład dostępny jest tutaj: http://bootcamp.threats.pl/lesson15/cj.php?sameorgin. Prosta demonstracyjna aplikacja jest wstawiona do iframe, przy czym:

• znajduje się nad właściwą stroną,
• jest częściowo przezroczysta,

W tym przypadku aplikacja co prawda zwraca nagłówek X-FRAME-OPTIONS, ale jego wartość to SAMEORGIN. Ponieważ obie strony są na tym samym serwerze, to nagłówka X-FRAME-OPTIONS równie dobrze mogłoby nie być.

Całość wygląda mniej więcej tak:

W prawdziwym ataku przycisk (cała zawartość iframe) byłby całkiem niewidoczny. Tu specjalnie "prześwituje". Użytkownik jest skłaniany do tego, by kliknąć w odpowiednim miejscu strony. W co wówczas właściwie klika? Ponieważ iframe znajduje się nad stroną, klika w przycisk znajdujący się iframe, którego (prawie) nie widzi. A rezultat jest mniej więcej taki:

I z X-FRAME-OPTIONS: DENY

Sytuacja nieco inaczej wygląda w przypadku, gdy nagłówek X-FRAME-OPTIONS ma wartość DENY, przykład: http://bootcamp.threats.pl/lesson15/cj.php?deny. W tym przypadku przeglądarka, która rozumie znaczenie nagłówka X-FRAME-OPTIONS nie wyświetli aplikacji w iframe, więc użytkownik klikając w sugerowane przez atakującego miejsce nie może kliknąć w przycisk, bo go tam po prostu nie ma. W przypadku Firefoxa z NoScript wygląda to tak:

Warto zwrócić uwagę, że w tym przypadku również dostępny jest link, po którego kliknięciu otworzy się osadzona w iframe strona. Otworzy się ona w pełnym oknie. Dokładnie tak samo jak w Internet Explorer. Żądanie, które wyśle przeglądarka jest takie, jak przy normalnym otwieraniu strony, atakujący nie osiąga swojego celu, bo użytkownik nie naciska przycisku Wyślij, głos nie zostaje zaliczony. Gdyby samo wyświetlenie strony (wysłanie przez przeglądarkę odpowiedniego żądania) było problemem, wówczas aplikacja byłaby podatna na cross-site request forgery, do którego wykorzystania sztuczki z iframe i ukrywaniem "właściwej" strony nie są potrzebne.

Jeśli ktoś chce dokładnie prześledzić żądania wysyłane przez przeglądarki, może to zrobić na przykład z użyciem narzędzia Fiddler. Krótki kurs jego użycia: Lekcja 1: absolutne podstawy.