Kan iemand mij de meerwaarde van CORS uitleggen?

[BasieP]

Ik moet voor me werk regelmatig met api's van andere partijen koppelen, en dit doe ik zoveel mogelijk in javascript.

Sommige externe partijen zetten netjes de CORS headers op hun dienst zodat alles werkt. Maar voor misschien wel meer diensten moet ik proxies maken.
Dwz. Ik doe vanuit JS een request naar mijn eigen server die op zijn buurt weer een normale request doet naar de API van de dienst.

Dit is erg vervelend.

Al deze ellende wordt ons opgedrongen doordat alle browsers nu CORS ondersteunen (waarbij in mijn ogen ondersteunen geen goed word is omdat je het niet kan uitzetten als website)

Kan iemand me misschien uitleggen waarom ik elke keer zoveel ellende moet doormaken?
ofwel: wat is de meerwaarde van CORS?

[Juup]

Dankzij Cross-origin resource sharing kan de server aangeven wie van de resources gebruik mag maken.
Dit is een van de maatregelen tegen o.a. CSRF problemen.

[ Voor 17% gewijzigd door Juup op 04-02-2015 18:40 ]

[Barryvdh]

Idd, zonder CORS zou je makkelijker cross site requests kunnen uitvoeren, wat je normaal gesproken niet wil toestaan. Maar voor web apis lijkt het logischer om zoiets wel toe te staan inderdaad.

[BasieP]

Juup schreef op woensdag 04 februari 2015 @ 18:39:
Dankzij Cross-origin resource sharing kan de server aangeven wie van de resources gebruik mag maken.
Dit is een van de maatregelen tegen o.a. CSRF problemen.

Het klinkt heel leuk, maar zelfs als een server CORS niet ondersteund kan ik gewoon de resource downloaden.
Alleen browsers hebben nu (bijna) allemaal CORS ondersteuning, dus het frustreerd de gemiddelde javascript /frontend developer. Qua beveiliging heb je er niets aan..

Cross Side scripting kun je niet tackelen en dat is volgens mij ook helemaal geen probleem. Een server hoort zijn eigen data zelf te beschermen. Je kunt er niet vanuit gaan dat nadat partij x het gedownload heeft hij het niet toont omdat jij een header hebt toegevoegd waarin staat dat ie het niet mag tonen

[ Voor 20% gewijzigd door BasieP op 23-04-2015 19:38 ]

[stager]

Jouw client zou moeten voorkomen dat er ajax-requests worden gemaakt naar site b als je site a aan het bezoeken bent. Met CORS kan je dit een stukje open zetten.

Je zou ook nog kunnen overwegen om json-p te gebruiken of een iframe (aargh) en dan met window.postMessage objecten overknallen.

Los daarvan kan je webservice nog gebruikt worden buiten een webbrowser om, je moet hem dus sowieso dichttimmeren.

[RobIII]

BasieP schreef op donderdag 23 april 2015 @ 19:37:
[...]

Het klinkt heel leuk, maar zelfs als een server CORS niet ondersteund kan ik gewoon de resource downloaden.

Daar gaat 't niet om
Het gaat er om dat een browser by default een cross domain request (voor bepaalde resource types zoals bijvoorbeeld JS) niet toestaat vanwege de SOP; met CORS kun je aangeven dat je een uitzondering maakt voor domein X (hence de cross origin, waarbij je origin als domain mag lezen).

Natuurlijk kun je met een stukkie PHP/Python/wget/C#/whatever de resource opvragen, maar vanuit de sandbox van je browser lukt je dat zonder CORS niet (althans, niet voor alle resource types; een image of CSS is geen probleem, een stuk JS, een (web)font of andere "enge" dingen wel). Een AJAX request naar een ander domein moest je "vroegah" oplossen met allerlei ranzige hacks zoals JSONP, of, wat jij nu doet: met "proxies". Nu heb je gewoon CORS.

De why van CORS wordt hier wel goed uitgelegd:

The use-case for CORS is simple. Imagine the site alice.com has some data that the site bob.com wants to access. This type of request traditionally wouldn’t be allowed under the browser’s same origin policy. However, by supporting CORS requests, alice.com can add a few special response headers that allows bob.com to access the data.

Et voila; u hoeft geen proxy meer te bouwen en hebt toch geen last van de SOP

[ Voor 34% gewijzigd door RobIII op 23-04-2015 23:16 ]

[Cartman!]

Ik denk inderdaad dat de TS het concept van CORS en same domainorigin policy niet begrijpt CORS is wat mij betreft juist heel relaxed!

[ Voor 4% gewijzigd door Cartman! op 25-04-2015 15:20 ]

[RobIII]

Cartman! schreef op donderdag 23 april 2015 @ 21:47:
Ik denk inderdaad dat de TS het concept van CORS en same domain policy niet begrijpt CORS is wat mij betreft juist heel relaxed!

Je bedoelt Same origin policy
Precies de reden waarom ik even een demo'tje in elkaar heb geflanst

De "No CORS" knop doet een X-domain request en zal een response krijgen waar GEEN Access-Control-Allow-Origin header in zit; de "CORS" knop doet exact het zelfde request maar zal een response krijgen waar WEL een Access-Control-Allow-Origin header in zit. De "Wrong domain" knop zal wél een CORS header sturen maar voor een ander (lees: verkeerd) domein en dus ook falen.

Open ook vooral effe je console en bekijk je console output en/of de daadwerkelijke request + bijbehorende response maar eens wanneer je op 1 van beide knoppen mept

[ Voor 49% gewijzigd door RobIII op 23-04-2015 22:33 ]

[BasieP]

Cartman.. leuk is dat zeg.. mensen in een hokje gooien en er een label op plakken.
Je voegt zelfs niets toe aan het topic anders dan in de groep gooien dat jij vind dat ik het niet snap..
Doe anders even normaal.

@RobIII

Ik begrijp CORS prima, ik werk er al een aantal jaar mee, maar het is gewoon verschrikkelijk vervelend dat ik nu niet vanuit mijn browser kan bepalen welke sites ik ophaal. Stel:
Ik heb een site (www.mijneerstesite.nl) en wil daarop een paar dingen tonen van anders sites. Bijvoorbeeld de tekst van een van mijn andere sites (www.mijntweedesite.nl)
Nu is dat makkelijk, want ik kan dan op mijn tweede site dmv CORS het domein van mijn eerste site toevoegen als toegestane site.

Echter, stel nou dat ik die tweede site niet gemaakt heb. Dan is er gewoon geen andere manier dan via een ranzige truuk (Bijv. een proxy) om stiekem toch die data te tonen op mijn site.
Ik doe dan een ajax call naar mijn eigen site, en die download de pagina die ik wil en geeft die terug.

Als ik dat 'netjes' wil, moet ik de maker van die andere site overtuigen om de juiste CORS headers toe te voegen. Wanneer je geen authorisatie gebruik mag je lekker * gebruiken en alle domains toevoegen, maar dat heeft bijna geen enkele website.
Om een voorbeeld te noemen: Wij gebruiken Jenkins als buildserver op mijn werk.
Deze heeft geen juiste CORS headers, maar bieden wel een JSON api aan. Hoe relax is dat.. Nou niet,,
Je kunt er namelijks niks mee tenzij je een proxy bouwt.

Dan hebben we het nog niet eens over sites die authorisatie vereisen.
In dat geval mag je namelijk geen wildcards gebruiken om domeinen toe te staan. Dan ben je helemaal de pineut.

Ow en ja ik begrijp dat dit probleem vooral in bedrijfsnetwerken voorkomt. Waar je juist graag allerlei api's van elkaar wilt gebruiken, maar niet in staat bent dat pakket van die externe partij aan te passen om die stomme header toe te voegen.


Om even aan te geven dat het ook anders kan:

Waarom hebben ze niet gemaakt dat je op je eigen pagina een lijst met trusted domains toevoegd?

Dus bijv:

HTML:

<head>
<meta trustedDomain="http://google.com; http://*.tweakers.net; http://mijntweedesite.nl" />
</head>

Ook dan ben je als eigenaar van de site in control over welke domeinen er dmv ajax calls geraadpleegd mogen worden, maar dan hoef je hiervoor niet aanpassingen te maken op al die domeinen, maar hou je het op de site zelf.

[ Voor 17% gewijzigd door BasieP op 25-04-2015 15:00 ]

[Cartman!]

Omdat jij dan een site kan maken die malafide zaken kan uitvoeren bij andere sites. Nu bepaalt de eigenaar wie er wel en geen data naar zijn site mag toesturen op die manier. Stukje veiligheid dus voor de gebruiker vooral.

En waarom ik denk/dacht dat je CORS niet snapt komt vooral door de zin:

Al deze ellende wordt ons opgedrongen doordat alle browsers nu CORS ondersteunen (waarbij in mijn ogen ondersteunen geen goed word is omdat je het niet kan uitzetten als website)

Eerst kon je het helemaal niet en nu is er CORS uitgevonden waardoor het wel kan (mits de site het ondersteunt). Dus je haalt oorzaak/gevolg door elkaar zegmaar.

[Janoz]

BasieP schreef op zaterdag 25 april 2015 @ 14:53:
Ik begrijp CORS prima, ik werk er al een aantal jaar mee, maar het is gewoon verschrikkelijk vervelend dat ik nu niet vanuit mijn browser kan bepalen welke sites ik ophaal. Stel:
Ik heb een site (www.mijneerstesite.nl) en wil daarop een paar dingen tonen van anders sites. Bijvoorbeeld de tekst van een van mijn andere sites (www.mijntweedesite.nl)
Nu is dat makkelijk, want ik kan dan op mijn tweede site dmv CORS het domein van mijn eerste site toevoegen als toegestane site.

Echter, stel nou dat ik die tweede site niet gemaakt heb. Dan is er gewoon geen andere manier dan via een ranzige truuk (Bijv. een proxy) om stiekem toch die data te tonen op mijn site.
Ik doe dan een ajax call naar mijn eigen site, en die download de pagina die ik wil en geeft die terug.

Je snapt CORS wel, maar niet het probleem welke opgelost wordt. Jij bent niet degene die bepaalt of die andere site toegankelijk zou mogen zijn. Wat nu als die andere site rabobank.nl, paypal, gmail.com of topsecret.intranet is? En dat je die vanuit de browser (dus met de context van de gebruiker, niet je site) zomaar kan bevragen? Ik neem aan dat je begrijpt dat dit toch iets van een security issue is?

[RobIII]

Je ziet het precies verkeerd om: het is de SOP die jou zo dwars zit; CORS lost daar juist iets van op. En SOP is er met reden (zie Janoz hierboven, wikipedia etc.). Wat als jij een site, zeg deze pagina, injecteert met een XSS en daarna mijn GMail uitleest?