• 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

VPS Starter Arubacloud
0 głosów
565 wizyt
pytanie zadane 16 listopada 2017 w Sieci komputerowe, internet przez Artek Stary wyjadacz (11,800 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

+2 głosów
odpowiedź 16 listopada 2017 przez Comandeer Guru (599,730 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 Stary wyjadacz (11,800 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?
1
komentarz 16 listopada 2017 przez Comandeer Guru (599,730 p.)

SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

Serwer udostępnia zasoby każdemu, kto chce je pobrać (oczywiście jeśli nie wymaga się autoryzacji użytkownika). Przeglądarka jednak może odmówić ściągnięcia danego zasobu jeśli serwer nie poinformuje jej wprost, że może ten zasób ściągnąć.

Wartość nagłówka Access-Control-Allow-Origin jest ustalana przez programistę danej aplikacji, który określa z jakich stron mogą być pobierane zasoby.

komentarz 16 listopada 2017 przez Artek Stary wyjadacz (11,800 p.)

Postaram się jeszcze raz zebrać to do kupy, chcę to dogłębnie zrozumieć.

1.Mechanizm CORS ma za zadanie ochronę serwera przed tym aby jego dane nie były pobierane przez niepowołane witryny, osoby.

2. Czy ja dobrze rozumiem, że to przeglądarka decyduje o tym czy dany zasób pobrać?(na podstawie porównania nagłówków) Nie lepiej byłoby aby to serwer decydował o tym czy udostępnić dany zasób?

 

Ja bym to widział tak:

Przeglądarka wysyła żądanie z nagłówkiem "origin: witryna-a.pl". Serwer sprawdza ten nagłówek i to on decyduje czy udostępni zasób czy też nie. Jeżeli udostępnia zasób to go po prostu wysyła a jeżeli nie to informuje przeglądarkę, że zasób jest niedostępny.

 

Nie rozumiem dlaczego to przeglądarka decyduje czy pobrać jakiś zasób czy też nie. A co jeżeli ktoś zmieni ustawienia przeglądarki i wyśle nieprawdziwą wartość nagłówka tak aby pasowała? Albo co jeżeli ktoś zmieni ustawienia przeglądarki tak aby pobierała zasoby bez patrzenia na wartość nagłówka Access-Control-Allow-Origin ?

1
komentarz 17 listopada 2017 przez Comandeer Guru (599,730 p.)

Nie bardzo da się zmienić wartość nagłówka Origin ani wyłączyć CORS w przeglądarce. Inna rzecz, że nie jest to mechanizm zabezpieczający serwer a przeglądarkę. Przeglądarki bowiem działają ograniczone przez podstawową zasadę Same Origin Policy, która oznacza, że tylko strony z tego samego originu (w uproszczeniu można przyjąć, że chodzi o tę samą domenę) mają pełen zestaw uprawnień do dostępu i wykorzystywania danych z konkretnej strony. Najlepiej to widać po tym, jak bardzo ograniczone są iframe.

Dlatego też jeśli chcemy odpowiednim typom zasobów dać większe uprawnienia, trzeba przeglądarce powiedzieć, że te zasoby można wykorzystać w obrębie danego origina. Bardzo fajnie opisano to na MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

komentarz 17 listopada 2017 przez Artek Stary wyjadacz (11,800 p.)

Teraz ogłupiałem już. Cenię sobie Twoje odpowiedzi i nie twierdzę, że się mylisz, ale na stackoverflow napisali, że jest to mechanizm chroniący serwer.

 

CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data.

Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, any other website could show your traffic data by simply AJAXing to your endpoints; anyone could easily "steal" your data and thus your users and your money.

 https://security.stackexchange.com/questions/108835/how-does-cors-prevent-xss

Więc sam już nie wiem.

Poza tym czy ktoś odpowiednio zmotywowany nie mógłby napisać własnego programu wysyłającego żądania wraz z odpowiednim nagłówkiem origin?

2
komentarz 17 listopada 2017 przez Comandeer Guru (599,730 p.)
Rzeknę tak: CORS jest mechanizmem czysto przeglądarkowym. Skrypty, np. w PHP, mają głęboko gdzieś, jakie nagłówki CORS serwer wysyła. Jeśli skrypt PHP połączy się z danym serwerem, to po prostu pobierze dane – tyle. Jedynie przeglądarki respektują mechanizm CORS, więc nie można za bardzo mówić, że jest to mechanizm chroniący serwery. Owszem, nie pozwoli on pobrać przeglądarce danych jeśli nagłówki się nie zgadzają, ale na tym jego rola się kończy.
komentarz 17 listopada 2017 przez Comandeer Guru (599,730 p.)
komentarz 19 listopada 2017 przez Artek Stary wyjadacz (11,800 p.)
No dobrze, ja rozumiem to co napisałeś. Ale skoro nie jest to mechanizm chroniący serwery, to do czego właściwie służy?
2
komentarz 19 listopada 2017 przez Comandeer Guru (599,730 p.)
Do udostępniania przeglądarkom zasobów z innych originów bez łamania zasady Same Origin Policy, która jest podstawowym mechanizmem bezpieczeństwa w przeglądarce.
komentarz 19 listopada 2017 przez Artek Stary wyjadacz (11,800 p.)

Popraw mnie jeżeli mylę się w jakimś punkcie.

Czyli tak:

1.Elementy <img>, <script> oraz <iframe>(ten akurat z pewnymi ograniczeniami) mogą bez problemu i żadnych ceregieli pobierać dane z innych domen(originów).

2. SOP ma na celu uniemożliwienie kodowi JavaScript witryny zła-strona.pl  grzebanie w DOM'ie, ciasteczkach itd. witryny przechowującej cenne dane np. facebook.com albo mój-bank.com, którą aktualnie mam otwartą w innej karcie/oknie. Czy może coś jeszcze?

3.Gdyby np. witryna mój-bank.pl w nagłówku  Access-Control-Allow-Origin  podała wartość "zła-strona.pl" to wtedy zła strona poprzez JS będzie miała dostęp do DOM'u cookies i innych danych witryny mój-bank.pl

 

Dobrze to rozumiem?

2
komentarz 19 listopada 2017 przez Comandeer Guru (599,730 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 Stary wyjadacz (11,800 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 Guru (599,730 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 Stary wyjadacz (11,800 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 Guru (599,730 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

0 głosów
1 odpowiedź 136 wizyt
pytanie zadane 4 września 2019 w HTML i CSS przez MAXIM7 Obywatel (1,990 p.)
+1 głos
2 odpowiedzi 197 wizyt
pytanie zadane 22 czerwca 2018 w Sieci komputerowe, internet przez Przemek Zembrzuski Gaduła (3,240 p.)
0 głosów
1 odpowiedź 675 wizyt
pytanie zadane 1 grudnia 2017 w JavaScript przez Q_Nick Mądrala (5,010 p.)

92,452 zapytań

141,262 odpowiedzi

319,085 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

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

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...