Dlaczego Ajax między domenami jest problemem bezpieczeństwa?

Dlaczego zdecydowano, że używanie XMLHTTPRequest do wykonywania wywołań XML nie powinno odbywać się poza granicami domeny? Możesz pobrać JavaScript, obrazy, CSS, ramki iframes i prawie każdą inną zawartość, jaką mogę wymyślić z innych domen. Dlaczego żądania HTTP Ajax nie mogą przekraczać granic domeny? Wydaje się, że dziwne ograniczenie, biorąc pod uwagę, że jedynym sposobem, w jaki mogłem zobaczyć, że jest nadużywany, byłoby, gdyby ktoś wstrzyknął Javascript na stronę. Jednak w w tym przypadku możesz po prostu dodać element img, skrypt lub element iframe do dokumentu, aby poprosić o adres URL strony trzeciej i wysłać go na serwer.

[edytuj]

Niektóre z odpowiedzi wskazują na następujące powody, wskażmy powody, dla których nie tworzą one głównego powodu, aby temu zapobiec.

XSRF (Cross Site Request Forgery, znany również jako CSRF, XSRF)

Twój może wykonywać ataki XSRF bez użycia tego w ogóle. Ogólnie Rzecz Biorąc, XMLHTTPRequest nie jest używany w ogóle, po prostu dlatego, że tak trudno jest zrobić XMLHTTPRequest w sposób zgodny ze wszystkimi głównymi przeglądarkami. O wiele łatwiej jest po prostu dodać tag img do adresu URL, jeśli chcesz, aby załadował Twój adres URL.

Publikowanie na stronie trzeciej 

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

Można osiągnąć za pomocą 

<body onload="document.getElementById('InvisbleForm').submit()"
    <div style="display:none">
        <form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
            <input type="hidden" name="amount" value="10000">
            <input type="hidden" name="to_account" value="xxxxx">
        </form>
    </div>
</body>

JPunyon: dlaczego zostawiasz lukę w nowej funkcji

Nie tworzysz więcej niepewności. Jesteś po prostu niewygodne deweloperów, którzy chcą używać go w sposób dla dobrze. Każdy, kto chce użyć tej funkcji dla zła (aka awesome), może po prostu użyć innej metody.

Podsumowanie

Zaznaczam odpowiedź z bobince jako poprawną, ponieważ wskazał krytyczny problem. Ponieważ XMLHTTPRequest pozwala na publikowanie, z poświadczeniami (ciasteczkami) do witryny docelowej, i odczytywanie danych wysyłanych z powrotem ze strony, wraz z wysyłaniem poświadczeń osób, można zaaranżować trochę javascript, który przesłałby serię formularzy, w tym formularzy potwierdzających, wraz z dowolnymi wygenerowanymi losowo kluczami, które zostały wprowadzone, aby zapobiec XSRF. W ten sposób możesz przeglądać witrynę docelową, jak bank, a serwer internetowy banku nie byłby w stanie powiedzieć, że nie był to zwykły użytkownik przesyłający wszystkie te formularze.

Author: Kirill Kobelev, 2009-01-21
Source

9 answers

Dlaczego żądania HTTP Ajax nie mogą przekraczać granic domen.

Ponieważ żądania AJAX są (a) przesyłane z poświadczeniami użytkownika i (b) pozwalają wywołującemu odczytać zwrócone dane.

Jest to kombinacja tych czynników, które mogą spowodować podatność. Istnieją propozycje dodania formy cross-domain AJAX, która pomija poświadczenia użytkownika.

Możesz po prostu dodać img, skrypt lub element iframe do dokumentu

Brak metody te pozwalają wywoływaczowi odczytać zwrócone dane.

(z wyjątkiem skryptów, w których jest to celowo ustawione, aby na to pozwolić, dla dozwolonego skryptowania między domenami - lub gdzie ktoś zrobił straszną fuck-up.)

Twój może wykonywać ataki XSS bez używania tego w ogóle. Publikowanie na stronie trzeciej

To nie jest atak XSS. To cross-site request forgery attack (XSRF). Znane są sposoby rozwiązywania ataków XSRF, takie jak jednorazowe lub tokeny kryptograficzne w celu sprawdzenia, czy zgłoszenie pochodzi celowo od użytkownika i nie zostało uruchomione z kodu atakującego.

Jeśli zezwalasz na cross-domain AJAX, stracisz to zabezpieczenie. Atakujący kod mógł zażądać strony ze strony bankowej, odczytać na niej wszelkie tokeny autoryzacyjne i przesłać je w drugim żądaniu AJAX w celu wykonania przelewu. I to byłoby atakowaniem skryptów.

 36
Author: bobince,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:53:22

Ważna różnica między postem: 

<body onload="document.getElementById('InvisbleForm').submit()" ...

A Ajax polega na tym, że po wykonaniu dowolnego postu przeglądarka zastąpi stronę, a po wywołaniu Ajax-nie. Wynik postu będzie:

  1. wyraźnie widoczne dla użytkownika.
  2. atak zostanie zablokowany w tym momencie, ponieważ strona odpowiedzi z my-bank.com przejmie kontrolę. Żaden bank nie wdroży one-click-transfer .

Scenariusz XSRF, gdyby cross domain Ajax być dozwolone, będzie wyglądać następująco:

  1. użytkownik odwiedza www.bad-guy.com.
  2. Jeśli nie ma otwartej strony my-bank.com w innej instancji przeglądarki, atak zakończy się niepowodzeniem.
  3. ale jeśli taka strona jest otwarta, a użytkownik wprowadził już swoją nazwę użytkownika/hasło, oznacza to, że w pamięci podręcznej przeglądarki znajduje się plik cookie dla tej sesji.
  4. kod JavaScript na stronie z www.bad-guy.com wywołuje Ajax do my-bank.com.
  5. dla przeglądarki jest to zwykły Połączenie HTTP, musi wysłać ciasteczka my-bank do my-bank.com i wysyła je.
  6. Bank przetwarza to żądanie, ponieważ nie może odróżnić tego wywołania od zwykłej aktywności użytkownika.
  7. fakt, że kod JavaScript może odczytać odpowiedź, nie jest ważny. W przypadku ataku może to nie być konieczne. Naprawdę ważne jest to, że użytkownik przed komputerem nie będzie miał pojęcia, że ta interakcja ma miejsce. Obejrzy ładne zdjęcia na www.bad-guy.com strona.
  8. kod JavaScript wykonuje kilka innych wywołań do my-bank.com, jeśli jest to konieczne.

Chodzi o to, że nie ma potrzeby wstrzykiwania ani manipulowania stroną.

Lepszym rozwiązaniem może być umożliwienie połączenia, ale nie wysyłanie plików cookie. Jest to bardzo proste rozwiązanie, które nie wymaga rozległego rozwoju. W wielu przypadkach połączenie Ajax trafia do niezabezpieczonej lokalizacji i nie wysyłanie plików cookie nie będzie ograniczeniem.

CORS (Cross Origin Resource Sharing) to jest obecnie dyskutowane, między innymi, mówi o wysyłaniu / nie wysyłanie plików cookie.
 7
Author: Kirill Kobelev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-24 08:43:59

Cóż, najwyraźniej nie jesteś jedyną osobą, która tak myśli...

Http://www.google.com/search?q=xmlhttp + cross + site

EDIT: jest ciekawa dyskusja linkowana z powyższego wyszukiwania:

Http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx

Wygląda na to, że trwają prace nad propozycjami zezwalającymi na cross site XMLHTTP requests (IE 8, FF3 itp.), chociaż szkoda, że nie było ich tam, gdy pisałem kod dla moich stron :) I jest jeszcze problem kompatybilności... Minie trochę czasu, zanim będzie wszechobecny.

 2
Author: Andrew Rollings,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:11:41

Kiedy wysyłasz żądanie HTTP do serwera, pliki cookie ustawione przez serwer są również wysyłane z powrotem przez przeglądarkę do serwera. Serwer wykorzystuje te pliki cookie, aby ustalić, że użytkownik jest zalogowany, itp.

Może to być wykorzystane przez złośliwego napastnika, który za pomocą JavaScript może ukraść informacje lub wykonać nieautoryzowane polecenia na innych stronach internetowych bez wiedzy użytkownika o tym.

Na przykład, można poprosić Użytkownika o odwiedzenie strony, która posiada następujący kod JavaScript (zakładając jQuery): 

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

Teraz, jeśli użytkownik był naprawdę zalogowany do banku podczas wykonywania powyższego kodu, atakujący mógł przelać 10 000 USD na konto XXX.

Tego rodzaju ataki nazywane są Cross Site Request Forgery (XSRF). Więcej informacji na ten temat znajduje się na Wikipedii .

Głównie z tego powodu istnieje polityka tego samego pochodzenia i przeglądarki nie pozwalają na wykonywanie zapytań Xmlhttprequestów na domenach różni się od pochodzenia.

Toczy się dyskusja, aby rzeczywiście zezwolić na XHR między domenami, ale musimy zobaczyć, czy to naprawdę zostanie zaakceptowane.

 2
Author: Baishampayan Ghose,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:18:28

Jest to problem, ponieważ może być używany do złych celów, jak wspomniałeś. Może być również używany z dobrymi intencjami i z tego powodu opracowywane są protokoły między domenami.

Dwa największe problemy dotyczą tego, że jest on używany w połączeniu z cross-site scripting (XSS) i cross-site request forgery (CSRF). Oba są poważnymi zagrożeniami (dlatego trafiły do OWASP top 10 i SANS 25).

Jedynym sposobem, w jaki mogłem to zobaczyć, byłoby, gdyby ktoś miał wstawić Javascript

To jest XSS zdecydowanie zbyt wiele aplikacji jest nadal podatnych na ataki, a jeśli modele zabezpieczeń przeglądarek nie zapobiegają X-domain AJAX, otwierają swoich użytkowników na znaczny wektor ataku.

Możesz po prostu dodać img, skrypt lub element iframe do dokumentu, aby zażądać adresu URL strony trzeciej

Tak, ale te będą wysyłać HTTP_REFERRER i (w inny sposób) mogą zostać zablokowane, aby zapobiec CSRF. Połączenia AJAX mogą być fałszywe nagłówki łatwiejsze i umożliwiłyby inne sposoby obejścia tradycyjnych zabezpieczeń CSRF.

 1
Author: Mike Griffith,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:28:17

Myślę, że kolejną rzeczą, która oddziela to od normalnego ataku XSRF jest to, że możesz robić rzeczy z danymi, które otrzymujesz również za pomocą javascript.

 1
Author: Shawn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:34:53

Nie wiem w czym problem? Czy połączenia AJAX wysyłane do innych domen firs wysyłane do aplikacji, a następnie przekazywane gdzie indziej z filtrowanych danych, analizować zwrócone dane, jeśli naprawdę trzeba, i karmić go do użytkownika.

Obsługa wrażliwych żądań AJAX? Zdobądź przychodzące Ssaki, sprawdzając nagłówki, przechowując dane o czasie sesji lub filtrując przychodzące adresy IP do źródeł zaufania lub aplikacji.

Co ja osobiście chciałbym zobaczyć w przyszłości jest solidne zabezpieczenie wszystkich przychodzących żądań domyślnie na serwerach WWW, frameworkach i CMSs, a następnie jawnie zdefiniować zasoby, które będą przetwarzać żądania z zewnętrznych źródeł.

 1
Author: Filip Dupanović,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:48:59

Z <form> możesz publikować dane, ale nie możesz ich odczytać. Z XHR możesz zrobić jedno i drugie.

Strona taka jak {[2] } jest bezpieczna dla XSRF (zakładając, że wyświetla tylko i nie ustawia hasła) i ramek (mają politykę tego samego pochodzenia). Jednak cross-domain XHR byłby podatnością.

 1
Author: Kornel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 21:32:39

Zamieniasz niczego nie podejrzewających gości w atakujących odmową usługi.

Wyobraź sobie również skrypt strony krzyżowej, który kradnie wszystkie twoje rzeczy facebook. Otwiera IFrame i przechodzi do Facebook.com

Jesteś już zalogowany do facebook (cookie) i idzie odczytuje swoje dane / znajomych. I robi więcej okropności.

 0
Author: user57660,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-21 20:09:31