2011-07-19 11 views
12

http://en.wikipedia.org/wiki/Same_origin_policyJaki jest model zagrożenia dla tej samej polityki pochodzenia?

Ta sama polityka pochodzenia zapobiega skryptowi z jednej witryny rozmawiającej z inną witryną. Wiki mówi, że jest to "ważna koncepcja bezpieczeństwa", ale nie jestem pewien, jakiego zagrożenia mu zapobiega.

Rozumiem, że pliki cookie z jednej witryny nie powinny być udostępniane innym podmiotom, ale może to być (i jest) egzekwowane osobno.

Standard CORS http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing stanowi zgodny z prawem system do ominięcia tej samej polityki pochodzenia. Prawdopodobnie nie pozwala na jakiekolwiek zagrożenie, które blokuje ta sama polityka pochodzenia.

Patrząc na CORS, nie mam pojęcia, kto jest chroniony przed czym. CORS jest egzekwowany przez przeglądarkę, więc nie chroni żadnej witryny przed przeglądarką. Ograniczenia są określane przez witrynę, z którą skrypt chce rozmawiać, więc nie chroni ona użytkownika przed żadną z tych witryn.

Więc do czego służą te same zasady pochodzenia?

Odpowiedz

1

Jako przykład zapobiega to sprawdzaniu przez firmę Farmville salda na koncie bankowym. Lub, co gorsza, mieszanie z formularzem, który zamierzasz wysłać (po wprowadzeniu PIN/TAN), aby otrzymać wszystkie pieniądze.

CORS to głównie standard dla stron internetowych, które na pewno nie potrzebują tego rodzaju ochrony. Zasadniczo mówi "jest w porządku, aby skrypt ze strony internetowej mógł ze mną rozmawiać, żadne zabezpieczenia nie mogą być zepsute". Tak naprawdę pozwala na rzeczy, które byłyby zabronione przez SOP, w miejscach, w których ochrona nie jest potrzebna, a strony internetowe w wielu domenach są korzystne. Pomyśl o meshupach.

+0

Jak to zrobić bez dostępu do plików cookie? czy nie mam racji co do tego, że pliki cookie są chronione? –

+1

Pliki cookie można wysyłać z żądaniem CORS, ustawiając właściwość żądania 'withCredentials' na 'true'. W związku z tym, że JavaScript ma dostęp do plików cookie, nie ma żadnej korzyści z ustanowienia dodatkowych barier. Miła lektura na ten temat znajduje się tutaj: http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ – Waldheinz

4

Artykuł @ EricLaw wspomina: "Same Origin Policy Part 1: No Peeking" jest dobry.

Oto prosty przykład, dlaczego potrzebujemy „samą politykę wydania”:

to możliwe, aby wyświetlić inne strony internetowe w swoją stronę za pomocą iframe (AN „Frame inline” miejsc innego dokumentu HTML w ramce). Załóżmy, że wyświetlasz www.yourbank.com. Użytkownik wprowadza swoje dane bankowe. Jeśli potrafisz odczytać wewnętrzny HTML tej strony (który wymaga użycia skryptu), możesz łatwo odczytać informacje o koncie bankowym i bum. Naruszenie bezpieczeństwa.

Dlatego potrzebujemy tej samej reguły pochodzenia, aby upewnić się, że jedna strona internetowa nie może użyć skryptu do odczytania informacji z innej strony internetowej.

0

Celem tej samej polityki pochodzenia jest uniknięcie zagrożenia niebezpieczną witrynę M czytanie informacji z zaufanych witryn Akorzystając z autorytetu (tj ciasteczka zezwoleń) z użytkownikiem A. Jest to polityka przeglądarki, a nie polityka serwera lub standard HTTP i ma na celu zminimalizowanie ryzyka związanego z wysyłaniem plików cookie przeglądarki z witryny A podczas kontaktowania się z witryną A.

Pamiętaj, że nic nie stoi na przeszkodzie, aby M uzyskać dostęp do A poza przeglądarką. Może wysyłać tyle żądań, ile chce. Nie zrobi tego jednak z autorytetem nieświadomego użytkownika o numerze A, co może się zdarzyć w przeglądarce.

Należy również pamiętać, że polityka zapobiega wyświetlaniu M z odczytu z A.Nie chroni serwera A przed skutkami żądania. W szczególności przeglądarka zezwoli na używanie między domenami POSTS - ciasteczek i wszystko od M do A. To zagrożenie nazywa się Cross-Site Request Forgery; nie jest ona łagodzona przez Zasady Same Origin, dlatego tak ważne jest, aby serwery chroniły się przed nią.