POSTING formularza między domenami

145

Widziałem artykuły i posty (w tym SO) na ten temat, a dominującym komentarzem jest to, że polityka tego samego pochodzenia zapobiega wysyłaniu formularza POST w różnych domenach. Jedyne miejsce, w którym ktoś sugerował, że polityka tego samego pochodzenia nie dotyczy postów formularzy, jest tutaj .

Chciałbym otrzymać odpowiedź z bardziej „oficjalnego” lub formalnego źródła. Na przykład, czy ktoś zna specyfikację RFC, która odnosi się do tego, jak to samo źródło wpływa lub nie wpływa na formularz POST?

wyjaśnienie : nie pytam, czy GET lub POST można zbudować i wysłać do dowolnej domeny. Pytam się:

czy Chrome, IE lub Firefox zezwalają zawartości z domeny „Y” na wysyłanie POST do domeny „X”
czy serwer odbierający POST w rzeczywistości zobaczy jakiekolwiek wartości formularza. Mówię to, ponieważ większość dyskusji online rejestruje testerów, którzy twierdzą, że serwer otrzymał wiadomość, ale wszystkie wartości formularza były puste / usunięte.
Jaki oficjalny dokument (tj. RFC) wyjaśnia, jakie jest oczekiwane zachowanie (niezależnie od tego, jakie przeglądarki obecnie zaimplementowały).

Nawiasem mówiąc, jeśli to samo pochodzenie nie wpływa na posty z formularza - wtedy staje się nieco bardziej oczywiste, dlaczego tokeny chroniące przed fałszerstwem są konieczne. Mówię „trochę”, ponieważ zbyt łatwo wydaje się, że osoba atakująca może po prostu wydać HTTP GET w celu pobrania formularza zawierającego token zabezpieczający przed fałszerstwem, a następnie wykonać niedozwolony POST zawierający ten sam token. Komentarze?

— Brent Arias
źródło

Tak, osoba atakująca może to zrobić ... za pomocą zwykłej przeglądarki internetowej.

— Michael Hampton,

Być może nie ma dokumentów RFC z tego samego powodu, dla którego nie ma dokumentów RFC, które mówią: „nie umieszczaj hasła na swojej stronie internetowej”. Standardy sieciowe są wymagane tylko wtedy, gdy wiele stron musi współpracować, aby coś osiągnąć: ta sama polityka pochodzenia jest bardziej złożonym zestawem „najlepszych praktyk bezpieczeństwa”, które chronią użytkowników przed włamaniami.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@ Ciro Proszę powiedzieć wyraźnie. Zasady cross-postów do innych witryn nie mają wpływu na wiele stron. Nie ma potrzeby mglistego języka.

— Little Alien

Odpowiedzi:

175

Te same zasady dotyczące pochodzenia mają zastosowanie tylko do języków programowania po stronie przeglądarki. Więc jeśli spróbujesz wysłać wiadomość na inny serwer niż serwer pochodzenia przy użyciu JavaScript, wtedy w grę wchodzi ta sama zasada pochodzenia, ale jeśli wysyłasz bezpośrednio z formularza, tj. Akcja wskazuje na inny serwer, na przykład:

<form action="http://someotherserver.com">

i nie ma javascript zaangażowanego w wysyłanie formularza, wtedy ta sama polityka pochodzenia nie ma zastosowania.

Więcej informacji można znaleźć w Wikipedii

— Suresh Kumar
źródło

Przepraszam, że przeciągam stare pytanie, co by się stało, gdyby akcja została zmieniona za pomocą JS, ale formularz zostałby wysłany za pomocą przycisku? Czy pozwoliłoby to na udany post w wielu domenach?

— Chris

AFAIK to nie powinno być problemu, ale sam tego nie próbowałem. Byłoby ciekawie się dowiedzieć.

— Suresh Kumar,

Jestem tego samego zdania. Właściwie martwiłem się o bezpieczeństwo, jakiś JS / wirus innej firmy zmienił akcję, aby wysłać formularz w złośliwym miejscu, ale zdałem sobie sprawę, że można to zrobić na dowolnej płatności otrzymanej w wielu domenach lub nie, a wynik byłby taki sam. Lekcja tutaj naprawdę: sprawdź pliki JS stron trzecich;)

— Chris

W skrócie: TAK, międzydomenowe POSTing jest dozwolone.

— Christian Davén,

-1 dla: ta sama polityka pochodzenia nie ma nic wspólnego z wysyłaniem żądania do innego adresu URL (innego protokołu, domeny lub portu), chodzi o ograniczenie dostępu do (odczytywania) danych odpowiedzi z innego adresu URL (a tym samym uniemożliwienie javascript do aktualizacji dokumentu za pomocą formularze, które mają tokeny bezpieczeństwa z innego adresu URL).

— Mohsenme

Możliwe jest zbudowanie dowolnego żądania GET lub POST i wysłanie go na dowolny serwer dostępny dla przeglądarki ofiary. Obejmuje to urządzenia w sieci lokalnej, takie jak drukarki i routery.

Istnieje wiele sposobów tworzenia exploita CSRF. Prosty atak CSRF oparty na POST można wysłać za pomocą .submit()metody. Bardziej złożone ataki, takie jak cross-site atakami CSRF wysyłania plików będzie wykorzystywał CORS używać z zachowaniem xhr.withCredentals .

CSRF nie narusza zasady tego samego pochodzenia dla skryptów JavaScrip t, ponieważ SOP dotyczy JavaScript odczytującego odpowiedź serwera na żądanie klienta. Ataki CSRF nie przejmują się odpowiedzią, dbają o efekt uboczny lub zmianę stanu wywołaną przez żądanie, taką jak dodanie użytkownika administracyjnego lub wykonanie dowolnego kodu na serwerze.

Upewnij się, że Twoje żądania są chronione za pomocą jednej z metod opisanych w ściągawce OWASP CSRF Prevention . Więcej informacji na temat CSRF można znaleźć na stronie OWASP poświęconej CSRF .

— Mikey
źródło

Zaktualizowałem moje pytanie, aby wyjaśnić. Ponadto łącze do WordPressa, które podałeś, dotyczy exploitów, które zostały zainicjowane z poziomu X tego samego pochodzenia, a nie zainicjowane z międzydomenowego Y ... więc nie jest to właściwy scenariusz z tego, co widzę.

— Brent Arias,

@Brent Arias tak, to, co opisujesz w punktach 1 i 2, jest dokładnie równe temu, co wykonuje atak CSRF, być może powinieneś spróbować wykonać jeden z dostarczonych exploitów CSRF i podsłuchać ruch. Zaktualizowałem swój post, powinieneś przeczytać każdy podany link, ponieważ dokładnie odpowie na te pytania. Celem ataku typu „cross-site request fałszerstwo” (CSRF) jest żądanie pochodzące z innej domeny, wszystkie dostarczone exploity w pełni spełniają ten podstawowy wymóg.

— Mikey,

Ta sama zasada pochodzenia nie ma nic wspólnego z wysyłaniem żądania do innego adresu URL (innego protokołu, domeny lub portu).

Chodzi o ograniczenie dostępu do (odczytywania) danych odpowiedzi z innego adresu URL. Tak więc kod JavaScript na stronie może wysyłać do dowolnej domeny lub przesyłać formularze z tej strony w dowolne miejsce (chyba że formularz jest w ramce iframe z innym adresem URL).

Ale to, co sprawia, że żądania POST są nieefektywne, to fakt, że nie zawierają one tokenów zabezpieczających przed fałszerstwem, więc są ignorowane przez inny adres URL. Co więcej, jeśli JavaScript próbuje uzyskać te tokeny bezpieczeństwa, wysyłając żądanie AJAX na adres URL ofiary, uniemożliwia dostęp do tych danych zgodnie z Polityką tego samego pochodzenia.

Dobry przykład: tutaj

I dobra dokumentacja z Mozilli: tutaj

— Mohsenme
źródło