Ta sama polityka dotycząca pochodzenia w Layman Warunki

Question

Czy ktoś może mi pomóc lepiej zrozumieć zasady dotyczące tego samego pochodzenia. Widziałem kilka stron opisujących to, ale szukam wyjaśnienia o wiele prostszego, jak opisałbyś to dziecku?

Wydaje się, że ta link wykonuje najlepszą pracę, jaką udało mi się znaleźć. Czy ktoś może się rozwinąć? Czy ktoś może wyjaśnić, dlaczego ta polityka istnieje?

Answer 1

Wymagana jest polityka tego samego pochodzenia, aby zapobiec CSRF. Wyobraź sobie ten scenariusz:

1. Menedżer banku Joe Fatcat ma konto na zapleczu administracyjnym swojego banku. To konto pozwala mu uzyskać dostęp do poufnych informacji o koncie dla każdego, kto korzysta z banku TBtF. Może nawet zresetować czyjś numer PIN, przelać środki, zmienić właściciela konta itp.
2. Teraz TBtF Bank odkłada Jacka IT-faceta. Teraz to Jack Dig Digntntled Ex-IT-Guy, a on chce się zemścić na swoim byłym pracodawcy. Jack nie ma dostępu do zaplecza administracyjnego banku, ale wie, że Joe to robi.
3. Więc Jack wysyła swojemu szefowi wiadomość e-mail z linkiem do strony utworzonej przez Jacka. Na stronie, tam jakiś JavaScript jak:

var xhr = new XMLHttpRequest(), 
    data = "from="+victimAccount 
      + "&to="+jacksAccount 
      + "&amt=a+gazillion+dollars"; 
xhr.open("POST", "http://tbtfbank.tld/accounts/wiretransfer.aspx", true); 
xhr.send(data); 

3. Następnego dnia Joe przybywa do swojego biura i loguje się do swojego konta administracyjnego jak zawsze robi i pozostawia otwartą kartę w tle.
4. Joe widzi e-mail zawierający linki do zdjęć Natalie Portman pokrytych gorącymi kaszami. Więc naturalnie klika na niego, otwierając złośliwą stronę.
5. Przeglądarka uruchamia JavaScript na stronie i wysyła żądanie AJAX POST do strony zaplecza administracyjnego TBtF Banku. Ponieważ Joe jest już zalogowany na stronie i ma aktywną sesję, aplikacja bankowa akceptuje polecenie i zarabia miliardy dolarów na zagraniczne konto bankowe Jacka.

I Jack mógł równie dobrze wykorzystać tę samą technikę do zebrania tysięcy numerów kont i pinów lub innych informacji, do których Joe zarządzający bankiem ma dostęp za pośrednictwem swojego konta.

Na szczęście polityka tego samego pochodzenia chroni nas przed tego typu atakami przez większość czasu, ponieważ złośliwa strona Jack'a jest hostowana w innej domenie niż aplikacja banku, nie wolno jej składać do aplikacji bankowej.Mimo że złośliwa strona może nadal zawierać obraz, który wysyła żądanie GET do aplikacji bankowej, ważne jest, aby działania z efektami ubocznymi nie były inicjowane za pomocą żądań GET, a aplikacje sprawdzały nagłówek strony odsyłającej otrzymanych żądań i wykorzystywały Żetony CSRF.

Answer 2

Zasadniczo oznacza to - tylko skrypty, które są obsługiwane z tej samej domeny, mają dostęp do siebie obiektów i właściwości bez ograniczeń (więc jeśli masz plik .js o zdefiniowanych nazwach funkcji, możesz wywołać go z dowolnego innego pliku hostowanego na ta sama domena).

Tak więc, jeśli służą skrypt z inny ograniczenia domeny zrobić zastosowania.

Ta zasada istnieje, ponieważ zbyt łatwo jest wstrzyknąć link do pliku javascript (np. Kod javascript, który wstrzykuje link do takiego pliku) znajdujący się w innej domenie. Jest to ryzyko związane z bezpieczeństwem - naprawdę potrzebujesz tylko kodu pochodzącego z witryny, w której się znajdujesz, a nie tylko kodu, który tam jest.