Rolf B: CORS for Dummies

Hallo alle,

ich bin, was CORS anbetrifft, ein Analphabet und bitte um Auskunft. Die Erklärungen bei Mozilla begreife ich nicht - vor allem deshalb, weil die URLs aus dem Text nicht mit denen in den Beispielen übereinstimmen und es deshlab ein Rätsel ist, über welchen Server geredet wird.

Szenario:

Abgerufen wird die URL http://foo.example.com/index.html. Diese lädt ein Script nach: http://foo.example.com/daten.js.

Ja, http. Weil...

daten.js soll einen Zugriff auf http://localhost:54321/dings/bums/123 machen, um auf dem Client eine bestimmte Funktion auszulösen.

Würde foo.example.com per https kommen, wäre dieser Zugriff die Hölle, weil man dann auf jedem Gerät, wo das passieren soll, HTTP Zertifikate für localhost bereitstellen müsste.

Bisher lief das unter bad old IE und soll jetzt auf einen Chromium-Browser übertragen werden. Der passt natürlich auf CORS auf.

Meine Fragen:

  • ist es für CORS relevant, ob http oder https verwendet wird? Sprich: Wenn irgendwann, wie ich schon lange fordere und andere boykottieren, endlich Transportsicherheit eingeführt wird und der Zertifikatekrieg gewonnen wird, würde das die erforderlichen CORS Maßnahmen verändern?

  • Wer muss den CORS Header Access-Control-Allow-Origin setzen?

    • Muss foo.example.com sagen, dass Code, der von ihm kommt, Cross-Origin Requests machen darf?
    • Muss oder kann foo.example.com sagen, dass Code, der von ihm kommt, nur bestimmte Ziel-Origins anprechen darf? Wenn ja, muss dann auch der Port festgelegt werden (was knifflig wird weil der variabel ist)?
    • Muss localhost:54321 den an ihn gestellten Request damit beantworten, dass foo.example.com (oder meinetwegen auch *) das darf?
    • Müssen es beide tun?
  • Reicht Access-Control-Allow-Origin für einfache GET Requests? Oder muss ich GET per Access-Control-Allow-Method explizit freischalten?

Self-typisch, aber absolut überflüssig sind Nebendiskussionen zu http vs https und CORS-Zugriffe auf localhost. Beides kann fragwürdig sein, aber das hilft mir keinen Millimeter weiter, die Konstruktion des Szenarios liegt außerhalb meines Einflusses und es ist ein Intranet mit strikt gemanagten Clients, nicht das WWW.

Rolf

--
sumpsi - posui - obstruxi
  1. Muss foo.example.com sagen, dass Code, der von ihm kommt, Cross-Origin Requests machen darf?

    Ja.

    Und wohin.

    Muss localhost:54321 den an ihn gestellten Request damit beantworten, dass foo.example.com (oder meinetwegen auch *) das darf?

    Nö.

    Beispiel:

    Du macht eine Webseite, z.B. mit User-Content oder Daten Dritter und befürchtest, dass Benutzer (z.B. in Kommentaren) JS-Code oder sonstwas einbauen, was dann Code oder anderes Zeug von dritten Webservern einbindet.

    Mit etwas wie

    Content-Security-Policy: default-src 'self' cdn.example.org;
    

    erlaubst nur dass Zeug vom gleichen HTTP-Host oder von cdn.example.org geholt und vor allem in die Webseite eingebaut wird. Der Browser überwacht darauf hin die Requests, welche von JS oder sonstwas in der Webseite ausgelöst werden.

    Das ist also sowas wie eine zweite Verteidigungslinie. Macht man vor allem wenn man den „Truppen an der Front“ (dem Framework...) nicht vertraut.

    Macht man das so wie oben bekommt man tolle Buttons.

    1. Hallo Raketenwilli,

      ah, super. Der Name dieses Headers fiel mir heute nicht mehr ein.

      Habe von Dedlfix auch noch eine Info erhalten, damit ist es mir jetzt wohl klar geworden.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Wollte es gerade noch nachtragen:

        Nach dem Test gibt der Observer von Mozilla Tipps, was man noch anstellen kann. z.B. Hashs von Skripten und allem, was per src=... geladen wird, bilden und diese mittels integrity="Hashverfahren-Hash" in die Webseite einbauen (Das macht aber nicht „Muh“, sondern absurd viel Mühe und kann die Webseite lahm legen... gerade das gezeigte Bespiel birgt diese Gefahr unter mehreren Aspekten: Skript vom CDN, könnte mal gepacht werden ... Peng!)