• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Pytanie odnośnie atrybutu crossorigin dla elementu <script> oraz ogólnie o CORS

0 głosów
166 wizyt
pytanie zadane 16 listopada 2017 w Sieci komputerowe, internet przez Artek Mądrala (7,160 p.)

Pierwsze pytanie : jakie warunki muszą zostać spełnione aby przeglądarka otrzymała zasób poprzez żądanie CORS?

Czy wystarczy aby wartości nagłówków Access-Control-Allow-Origin i Origin były takie same?

Jakie znaczenie w tym procesie mają tzw "user credentials" czyli

for the purposes of this specification means cookies, HTTP authentication, and client-side SSL certificates that would be sent based on the user agent's previous interactions with the origin.

https://www.w3.org/TR/cors/#user-credentials

 

Jak dokładnie wygląda sytuacja gdy ustawimy atrybut crossorigin na annonymous a jak gdy use-credentials?

 

2 odpowiedzi

+3 głosów
odpowiedź 16 listopada 2017 przez Comandeer Mentor (455,080 p.)
wybrane 16 listopada 2017 przez Artek
 
Najlepsza

Tak, żeby zezwolić na CORS, to serwer, z którego pobieramy zasób, musi wymieniać naszą domenę w nagłówku HTTP Access-Control-Allow-Origin.

CORS ma dwa tryby: anonimowy i z przesyłem danych uwierzytelniających. To drugie znaczy tyle, że będą przekazywane stronie, która ściąga dane, ciasteczka i inne tego typu informacje. Tak samo działa też atrybut [crossorigin], niemniej on przydaje się dopiero w połączeniu z mechanizmem SRI, skryptami wczytywanymi jako moduły (script[type=module]) lub obrazkami zaciąganymi z innych domen, a które chcemy użyć na canvas.

0 głosów
odpowiedź 16 listopada 2017 przez Artek Mądrala (7,160 p.)
Pozwolę sobie na podsumowanie w takim razie. Gdyby coś się nie zgadzało proszę koniecznie mnie poprawić.

Posiłkowałem się tym artykułem :

https://spring.io/understanding/CORS

Gdy żądanym zasobem z innego serwera jest np. obraz, dźwięk lub wideo itp. to taki zasób jest udostępniany "od ręki" bez żadnych ceregieli ponieważ tego typu zasoby nie stanowią zagrożenia dla bezpieczeństwa.

Gdy żądamy skryptu sytuacja jest nieco bardziej skomplikowana gdyż istnieje ryzyko, że ktoś chce "wstrzyknąć" na naszą witrynę niepożądany kod i przejąć kontrolę nad naszą stroną. I w tym momencie w sukurs przychodzi nam mechanizm uwierzytelniania.

Klient wysyła żądanie a  w nagłówku podaje atrybut Origin wraz z wartością np. Origin : witryna-a.pl

Serwer rozważa wartość atrybutu origin i podejmuje decyzję czy odpowiedzieć na żądanie czy nie. Jeżeli serwer zgadza się na odpowiedź to wysyła zasób i nagłówek Access-Control-Allow-Origin wraz z wartością.

Jeżeli Access-Control-Allow-Origin i Origin są takie same to przeglądarka dostarcza żądany zasób.

 

Zastanawia mnie jak serwer podejmuje decyzje. Czy serwer posiada jakąś listę witryn, którym udostępnia zasoby, a może jest jakiś algorytm który to ustala? Czy może jeszcze inaczej?

Zastanawia mnie również dlaczego przeglądarka porównuje atrybuty Origin i Access-Control-Allow-Origin skoro serwer zgodził się udostępnić zasób?

 

Czym jest mechanizm SRI? Szukałem w google ale o dziwo znajduje mi jedynie informacje o lekach....?

Czy mógłbyś jakoś bardziej rozpisać na temat "ciasteczek i innych tego typu informacji" oraz wykorzystaniu ich?
2
komentarz 19 listopada 2017 przez Comandeer Mentor (455,080 p.)

ad. 1) Akurat iframe ZAWSZE jest ograniczone przez SOP, więc NIGDY nie może tych danych pobierać. Z img i script jest ten problem, że są one starsze niż CORS i obsługa CORS została do nich dorobiona później. W teorii w tym momencie włączenie CORS (dodanie atrybutu [crossorigin]) może im ten dostęp ograniczyć. W przypadku obrazków CORS oznacza je jako zaufane i pozwala użyć w canvas. W przypadku normalnych skryptów [crossorigin] określa, czy strona będzie miała dostęp do błędów rzucanych przez załączany skrypt. Domyślnie ma ciut ograniczny, ale [crossorigin=anonymous] ten dostęp całkowicie wyłącza. [crossorigin=use-credentials] z kolei wymusza, żeby nagłówek Access-Control-Allow-Origin zawierało wprost daną domenę, inaczej całkowicie zablokuje dostęp do skryptu. Dodatkowo przy żądaniu danego zasobu z zewnętrznego serwera, przeglądarka domyślnie serwuje wszystkie nagłówki, łącznie z ciasteczkami itd. Przy [crossorigin=anonymous] tego typu dane nie są wysyłane.

ad. 2) Nie, SOP działa w obrębie jednej karty, nie pomiędzy różnymi kartami.

ad. 3) JS ma zawsze dostęp do tego typu rzeczy.

komentarz 20 listopada 2017 przez Artek Mądrala (7,160 p.)

2. Tzn. Działa w obrębie jednej karty ale ma za zadanie 

Same Origin Policy prevents a web site's scripts from accessing and interacting with scripts used on other sites.

 http://searchsecurity.techtarget.com/definition/Same-Origin-Policy-SOP

Lub inaczej wyjaśnione:

Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered your password before submitting the form.

But of course Facebook wants to use JavaScript to enhance the user experience. So it is important that the browser can detect that this JavaScript is trusted to access Facebook resources. That's where the same origin policy comes into play: If the JavaScript is included from a HTML page on facebook.com, it may access facebook.com resources.

Now replace Facebook with your online banking website, and it will be obvious that this is an issue.

 https://security.stackexchange.com/a/8269

Zgadzasz się z takim wyjaśnieniem?

 

3.JS tak, ale ja mam na myśli 

Same Origin Policy prevents a web site's scripts from accessing and interacting with scripts used on other sites.

komentarz 20 listopada 2017 przez Comandeer Mentor (455,080 p.)

ad. 1) Nie zgodzę się. Obydwie definicje wydają się wadliwe. Pierwsza dotyczy tylko skryptów, a akurat skrypty mogą omijać SOP… Druga definicja mówi o osobnych kartach przeglądarki, co nie ma sensu, bo osobne karty są… no, osobnymi kartami. Polecam spojrzeć jak to wygląda na MDN: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy – rozróżnienie zachodzi w obrębie jednej karty, gdy mieszają się zasoby z różnych originów.

 

komentarz 22 listopada 2017 przez Artek Mądrala (7,160 p.)

Trochę mnie zaskoczyłeś swoją wypowiedzią biorąc pod uwagę, że tamte odpowiedzi na stack-overflow mają ponad 200 głosów na tak. No ale o.k  Niech będzie, że Ci wierzę.

Czyli tak:

1.  Skrypty z jednej karty nie mają możliwości wpływania na strony otwarte w innej karcie. Nie ma to nic wspólnego z SOP. To jakby dwa odrębne światy.

2. Informacje z MDN jak dla mnie są zbyt ogólnikowe. Poszukałem i znalazłem coś takiego. :

Same-origin policy is needed to prevent CSRF. Imagine this scenario:

  1. Bank manager Joe Fatcat has an account on his bank's administrative backend. This account lets him access confidential account info for anyone who banks at TBtF Bank. He can even reset someone's pin number, transfer funds, change account ownership, etc.
  2. Now, TBtF Bank lays off Jack the IT Guy. Now he's Jack the Digruntled Ex-IT-Guy, and he wants to take revenge on his former employer. Jack doesn't have access to the bank's administrative backend, but he knows Joe does.
  3. So Jack sends his boss an email with a link to a page Jack created. On the page, there's some JavaScript like:

 

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);
  1. The next day, Joe arrives at his office and logs into his administrative account as he always does and leaves the tab open in the background.
  2. Joe sees an email containing links to pictures of Natalie Portman covered in hot grits. So naturally he clicks on it, opening the malicious webpage.
  3. The browser runs the JavaScript on the page and makes an AJAX POST request to TBtF Bank's administrative backend site. Because Joe is already logged into the site and has an active session, the bank application accepts the command and wires a gazillion dollars to Jack's offshore bank account.

And Jack could have just as easily used the same technique to harvest thousands of account numbers and pins or any other information Joe the bank manager has access to via his account.

Luckily, the same-origin policy protects us from these types of attacks most of the time, since Jack's malicious page is hosted on a different domain from the bank application, it's not allowed to make XHRs to the bank application. Though the malicious page could still contain an image that makes a GET request to the bank application, so it's important that actions with side effects are not initiated via GET requests and that applications check the referrer header of requests they receive and take advantage of anti-CSRF tokens.

Jak również :

 

Basically it means - only scripts that are served from the same domain can access each others objects and properties without restriction (so if you have a .js file with named functions defined, you can call it from any other file hosted on the same domain).

So, if you are serving a script from a different domain restriction do apply.

This policy exists because it is too easy to inject a link to a javascript file (say some javascript code that injects a link to such a file) that is on a different domain. This is a security risk - you really only want code that comes from the site you are on to execute and not just any code that is out there.

shareimprove this answer

answered Jul 13 '12 at 16:27

Oded

377k60676858

 
4  

only scripts that are served from the same domain can access each others objects. Then, why can you include jQuery from a CDN and have it access the DOM on your page? – Rocket Hazmat Jul 13 '12 at 17:49 

    

@Rocket: Correct. It's the domain of the page the script executes from rather than where the JS file is hosted that matters. In fact, before CORS was standardized, JSONP was how you made cross-domain AJAX requests, which basically links to an off-site JS file as a way of getting data from another domain (in JSON form). – Lèse majesté Jul 13 '12 at 17:55

https://stackoverflow.com/questions/11474336/same-origin-policy-in-layman-terms

To o to chodzi? Czy może coś jeszcze należałoby dodać?

komentarz 22 listopada 2017 przez Comandeer Mentor (455,080 p.)
Pierwsza zacytowana odpowiedź dotyczy niemal wyłącznie Ajaksa, a termin SOP jest szerszy od tego i dotyczy np. ramek na stronie.

Druga odpowiedź nie wiem, czego dotyczy, ale w świetle całej naszej dyskusji nie ma sensu. Skryptów domyślnie SOP jako tako nie obowiązuje i dopiero wymuszenie dla nich CORS czy też narzucenie ograniczeń z poziomu CSP coś może zmienić.

Podobne pytania

+1 głos
2 odpowiedzi 105 wizyt
pytanie zadane 22 czerwca 2018 w Sieci komputerowe, internet przez Przemek Zembrzuski Gaduła (3,260 p.)
0 głosów
1 odpowiedź 110 wizyt
pytanie zadane 25 listopada 2018 w PHP, Symfony, Zend przez darek_kce Gaduła (3,180 p.)
0 głosów
1 odpowiedź 76 wizyt
pytanie zadane 26 grudnia 2017 w Systemy operacyjne, programy przez Bakr Mądrala (6,670 p.)
Porady nie od parady
Komentarze do pytań nie służą do odpowiadania, od tego jest wydzielona sekcja odpowiedzi. Funkcją komentarzy jest natomiast możliwość uzyskania dodatkowych informacji na temat samego posta.Komentarze

64,051 zapytań

110,441 odpowiedzi

231,298 komentarzy

47,818 pasjonatów

Przeglądających: 249
Pasjonatów: 12 Gości: 237

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto dwie polecane książki warte uwagi. Pełną listę znajdziesz tutaj.

...