Was soll denn eigentlich das mit der "same-origin policy"?

Aktuelle Programmier- und Auszeichnungssprachen HTML / CSS / JavaScript
1

Als jemand der keine Ahnung von Web-Entwicklung (sondern nur mit richtiger Programmierung) hat, muss ich diese Frage stellen. Vielleicht klingt die naiv, aber irgendwie drängt sich mir der Verdacht auf, dass jeder (ja, jeder - also auch die Leute, die sich damit auskennen) diese Frage nur mit einem unspezifischen, händewedelnden „Naja, das ist irgendwas mit Sicherheit“ beantworten können.

Welchen Zweck hat die Same-Origin-Policy?

Und um das vorweg zu nehmen, was durch das Extended Mind nahe liegt, hier ein Zitat von der Wikipedia-Seite:

Den Hintergrund für die große Bedeutung der SOP bildet im Wesentlichen die Kombination aus zwei Tatsachen:

  • Skriptsprachen im Browser haben über das Document Object Model (DOM) direkten Zugriff auf die gesamte Kommunikation zwischen Browser und Web-Server. Dies beinhaltet sowohl das Auslesen als auch die Manipulation von Daten und betrifft neben dem Empfangen auch das Senden von Daten.
  • Das Vertrauensverhältnis zwischen Browser (bzw. Anwender) und verschiedenen Webseiten kann extrem unterschiedlich sein.

Daraus ergibt sich die Anforderung, dass keine Informationen aus einem Kontext (zum Beispiel der Verbindung des Browsers zu der Seite einer Bank) von einem Skript aus einem anderen Kontext zugreifbar oder manipulierbar sein darf. Um dies zu erreichen, wird beim Zugriff eines Skriptes auf ein Objekt einer Webseite die Herkunft (origin) von beiden verglichen.

Jaja, bla bla :roll_eyes:

Auch auf die Gefahr hin, dass ich gleich ganz bescheiden zurückrudern muss, rufe ich mal ganz laut

bullshit!

Die Frage, ob auf der Seite einer Bank irgendein Script läuft, dem ich vielleicht nicht vertrauen könnte, hängt nicht davon ab, wo dieses Script liegt, sondern wer dafür verantwortlich ist, dass genau dieses Script genau von dort auf genau dieser Seite geladen wird.

Das ganze wirkt für mich im Moment wie eine Hochsicherheits-Tresortür mit Zahlenschloss. Und weil es nervt, dauern die Zahl einzugeben, oder man sie auch auch mal vergessen könnte, und abends ja auch die Putzfrau in den Tresorraum muss, wird eben ein Keil unter die Tür geklemmt, damit sie immer ein Stück offen steht. Darauf übertragen bedeutet das: Jeder, der irgendwelche resourcen ~„von woanders laden will“, wird sich im Zweifelsfall genötigt sehen, irgendwelche CORS-Policies zu etablieren, damit ~„es eben doch funktioniert“, mit denen aber letztendlich das ausgehebelt wird, was damit erreicht werden sollte (falls das denn „Sicherheit“ sein sollte - irgendwie zweifle ich da dran…)

Kann mich jemand erleuchten?

1 „Gefällt mir“
2

XSS - SOP ist richtig und wichtig, um es möglichen Angreifern zu erschweren. Morgen (heute) kann ich mehr dazu schreiben. Mit dem Wikipedia-Artikel liegst du aber nicht daneben, das ist leider Kauderwelsch.

e/ https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important

e2/ XSS hat nicht direkt etwas damit zu tun…

3

Die Argumentation, die auch in dem Wikipedia-Artikel steckt (mit etwas „Hintergrundwissen“ und vieeeel gutem Willen) ist ja die, die dort nochmal an einem Beispiel beschrieben wird:

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.

Da jetzt ein passendes Beispiel oder eine Analogie zu finden, ist schwierig, aber grob: Das Problem besteht darin, dass jeder sich aus meinem Kühlschrank rausnehmen kann, was er will. Die Lösung (SOP) ist, dass man einen Personalausweis-Scanner in den Kühlschrank einbaut, damit nur noch ich ihn aufmachen kann. Ich finde, das Problem besteht eher darin, dass jemand mein effing Haus betreten kann, um überhaupt erst an den Kühlschrank ranzukommen.

Wenn das Problem dadurch verursacht wird, dass irgendwelche Tabs aus anderen Tabs kreuz und quer Daten lesen und schreiben (und Requests absetzen) können, dann sollten doch lieber die Tabs in eine Art „Sandbox“, anstatt irgendein „Allow-Origin“-OPTIONS-preflight-Ping-Pong zwischen Client und Server zu starten, bei dem sie mit irgendwelchem Pattern-Matching gegen URL-Strings ausbaldovern, ob das, was da passieren soll, OK ist.

(Jaja, „das hat sich so ergeben“, „das wurde mal so definiert“, „das ist jetzt halt so“, und „das kann man nicht mehr ändern“. Irgendwelche Gremien und Konsortien definieren Standards, ich weiß, ich weiß. Aber wirklich Sinn ergibt das ganze für mich zumindest bisher nicht: Es setzt meiner Ansicht nach einfach an der falschen Stelle an. Der „origin“ (im Sinne eines URL-Strings) ist ja nicht die Ursache des Problems…)

1 „Gefällt mir“
4

Du verstehst da was nicht ganz richtig. Du bist ja jetzt hier auf https://forum.byte-welt.net eingeloggt. Das heißt, es ist ein cookie gespeichert, der auf Serverseite mit einer Session verknüpft ist. Bei jedem Request, der gemacht wird, wird dieser Cookie mit geschickt. Zum Beispiel wenn du ein Posting abschickst.
Diese Requests können auch von JavaScript aus geschickt werden. Was jetzt der Browser macht, ist, dass er prüft ob das Script, dass den Request abschickt, von dem selben Server geladen wurde (SOP), auf das es zugreifen will. Würde der Browser das nicht machen, könnte ich dir einen link zu https://forum.fake-byte-welt.net schicken und sobald du diesen aufmachst könnte ich in deinem Namen ein Posting hier abschicken.
Will man, dass auch Resourcen von anderen Servern auf einen Endpoint zugreifen können, kann man dem Browser dies mitteilen indem man auf eine OPTIONS anfrage mit entsprechenden Headern antwortet. Denn bevor der Browser den Zugriff verweigert, macht er erstmal diesen Call um rauszufinden wer denn zugreifen darf.

5

Guter Einwand, @anon65336368 ! Das CORS Flag mussten wir auch schon mal machen, weil wir zwei Server als Backend hatten. Inwieweit wir dadurch die Sicherheit „beeinträchtigt“ hatten, kann ich dir nicht mal genau sagen (obwohl ich auch eine Vorlesung zu IT-Sicherheit gehört habe.) Aber ich könnte mir natürlich so etwas vorstellen wie, BWN ist in der Art „kompromittiert“, dass ein böses JS deine neusten Posts von Facebook ausliest (wo du angemeldet bist) und diese an BWN sendet. Mit der SOP wüsste der Browser, dass BWN das gar nicht darf…

/e Um im Bilde des Kühlschranks zu bleiben, stell dir einfach einen Türsteher bei dem Kühlschrank vor, der sagen kann, „Du kommst hier nicht rein“ oder „Du kommst hier rein“, nachdem er deinen Ausweis gesehen hat. Nun hast du natürlich mehrere Kühlschränke und mehrere Ausweise, du bist aber für die Integrität der Ausweise zu deiner eigenen Sicherheit selbstverantwortlich, da der Türsteher dich sonst verprügeln könnte…

6

(Der Link zum CORS-Weikipedia-Eintrag: Jaja, natürlich findet man das - und man liest es sich durch, und denkt sich *genervt*: „Was soll das denn für’n Shyce sein?“. So, wie ich das sehe, wird durch CORS (auf haarsträubendst komplizierte Weise) ein Problem gelöst, das erst durch die SOP geschaffen wurde - welche wiederum eine haarsträubende „Lösung“ für ein Problem ist, das mit etwas Vor- und Voraussicht vor ca. 30 Jahren hätte vermieden werden können…)

Well, yes, but actually, no. Wenn ich auf fake-byte-welt.net gehe, dann kann dort ein Script geladen werden, das versucht, hier ein böses Posting abzusetzen. Das Script braucht dafür aber ein Cookie. Wo kommt das Cookie her? In einem Tab, in dem fake-byte-welt.net geöffnet ist, sollte nichts und niemand Zugriff auf dieses Cookie haben. Es ist doch vollkommen egal, welcher Script oder welche Resource von welcher Stelle geladen wird. Genauso wie ich Excel aufmachen kann, und davon ausgehen können muss, dass Excel nicht meinen Browser, der zufälllig auch offen ist, hijackt, um ein böses Posting abzusetzen, sollte man doch davon ausgehen können, dass irgendwelche Browser-Tabs sich nicht gegenseitig hijacken können.

(Nochmal: Ich kenn’ mich halt mit den Technologien nicht aus, und vielleicht ist das naiv, aber … so, wie es bisher beschrieben wurde, klingt das, als wäre es auch möglich, dass sich irgendein böses Script in Tab A sich durch den DOM einer Seite in Tab B hangelt, und da irgendwo die „Post“-Funktion aufruft, die dann ja - von der richtigen Seite, mit dem richtigen Cookie, mit dem richtigen Origin - einen bösen Post absetzen könnte. Vermutlich wird das auch verhindert, aber doch bestimmt nicht durch irgendwelches Pattern-Matching auf URL-Strings…? (und wenn doch, könnte ich nur fragen: „WTF?!? Warum?“))

Ein etwas konkreteres Beispiel, bei dem vielleicht (!) sowohl meine Verwirrung als auch meine Planlosigkeit (und vielleicht etwas Zynismus) erkennbar werden:

Angenommen, man erstellt eine Webseite. Die läuft irgendwann auf example.com. Und sie hat, natürlich, ein <script>http://whatever.com/jquery.js</script> eingebettet - weil … jQuery!!!111 :roll_eyes: . Und dann will man mit jQuery ein GET machen. Das geht nicht, weil … SOP … kein CORS… was auch immer. Das ist gut!!!111 Wegen der Sicherheit!!!111. Naja, man kann dann einfach in dieser Abscheulichkeit von Code, die man dafür schreiben muss, an irgendeiner Stelle ein contentType: 'jsonp' einfügen, und dann funktioniert es. Ist ja klar, dass es sonst nicht funktioniert. Wegen der Sicherheit!!!111 Aber JSON mit Padding, das geht. Ich meine, Padding!!! - ist doch klar, dass es damit dann geht. Padding rules!

(Irgendwo ist irgendwann irgendwas auf ganz, ganz, verstörende Art schief gelaufen…)

1 „Gefällt mir“
7

So funktioniert halt das Internet nicht. Cookies sind nicht Tabs zugeordnet sondern der Domäne, die es gesetzt hat. Bei jedem Request auf diese Domäne werden die dann wieder mitgeschickt. Das ist alles hier definiert.

Es ist ja nicht so, dass der Tab fake-byte-welt.net auf die Cookies aus dem Tab byte-welt.net zugreift, sondern von der Seite wird legentlich ein POST request auf byte-welt.net/make-posting gemacht. RFC konform hängt nun der Browser alle gespeicherten cookies dran.

Wenn das nicht alles so wäre, dann würden Dinge wie Tracking Cookies, aber auch einbetten von Youtube, Twitter, etc. nicht funktionieren.

Du machst nicht aus jQuery den POST sondern nutzt jquery um aus einem Script, dass wieder auf deinem Server liegt das POST zu machen

8

Nun, man könnte sich jetzt dieses 37seitige IETF-Dokument durchlesen, im Vorfeld schon wissend, dass dort mindestens 10 Dokumente verlinkt sind, die jeweils 50 Seiten haben, und die man erst lesen müßte, um zu „verstehen“, was dort beschrieben wird (dieser „Baum“, bei dem man nie weiß, wie tief man gehen muss, um sagen zu können: „Ja, ich kenne mich damit ein bißchen aus“…). Aber wenn man einfach nur ein GET foo.com machen will, dann sollte das, was in dem Dokument steht, nicht relevant sein.

Das, was ich zu den Tabs geschrieben habe, war nur der Versuch, auf die Argumentation einzugehen, die bisher verwendet wurde: ~„Ohne SOP können Tabs gegenseitig böse Sachen machen“. Dass ein Cookie zu einer Domäne gehört ist ja OK. Ich erkenne aber keinen Zusammenhang zu SOP.

Dann nochmal auf den Punkt gebracht: Ich mache von example.com aus ein GET othersite.com. Das geht nicht, wegen SOP. Aber wenn ich bei dem Request irgendwo contentType: jsonp einfüge, dann geht es. Nun kann ich mir sowas wie JSONP Security concerns durchlesen, und mir denken: Joa, … da wird mindestens 4 mal auf die „same-origin-policy“ verwiesen, um zu rechtfertigen, warum das unsicher ist. Aber mir ist nicht klar, warum die SOP unsicher sein soll.

Also ganz konkret: Angenommen, man könnte einen Schalter umlegen, durch den weltweit GET somesite.com-Requests nicht mehr durch die SOP eingeschränkt würden. Was könnte ein böser Mensch dann machen? Daten von Websiten lesen? Oh jeh! :exploding_head:

Dass bei einem POST (!!!) ein Cookie mitgeschickt werden muss, sollte doch eigentlich ausreichen. Wenn man FAKE-forum.org besucht und dann nach REAL-forum.org ein POST absetzen will, dann sollte es das (ohne Cookie) nicht können - aber das sollte doch nicht in der Verantwortung von REAL-forum.org liegen, zu überprüfen, wo der request herkommt, sondern auf Seite des Clients, sicherzustellen, dass die fake-Seite nicht an das Cookie rankommt…?!

9

Du vermischt ein paar Sachen. Erstmal es geht nicht um Tabs, HTTP kennt keine Tabs. Bleiben wir erstmal bei dem fake-forum.com Es würde folgender Inhalt reichen:

<html>
   <head><title>fake bytewelt</title></head>
  <body>
    <script>
    var xhr = new XMLHttpRequest();
    xhr.open("POST", 'https://forum.byte-welt.net/posts.json', true);
    xhr.send('{"title":"HACKED", "raw":"Gesendet von fake"}');
    </script>
   </body>     
</html>

Das würde reichen um in deinem Namen ein Posting hier in byte-welt.net zu schreiben. Die cookies die zu byte-welt.net gehören werden automatisch vom Browser gesetzt. Du kannst nicht für einen Request cookies setzten, du kannst nur von deinem JavaScript aus cookies in den Store schreiben, aber die gelten dann nur für deine Domäne, also ist es unmöglich cookies für andere Domänen zu manipulieren. Durch SOP würde der Request aber erst gar nicht abgesetzt.

Das mit JSONP ist ein anderes Thema. Das mit dem SOP gilt NICHT für <script> du könntest jetzt um Daten von einem Server laden mit dem Script-Tag also sowas <script src='http:/example.com/users/123'/> dieser Request wird immer durchgehen, nur hast du dann die Daten als String geholt und kannst damit nichts anfangen. JSONP macht folgendes, du kannst einen callback angeben der ausgeführt wird, wenn die Daten zurück kommen.

<script src='http://example.com/users/123?callback=handler'/>
<script>
function handler(user) {
    alert(user)
}
</script>

Der Server antwortet dir jetzt

callback('{"id":123, "name":....}')

Und der Browser wird dann den callback aufrufen. Aber der Server muss das auch unterstützen.

Der Server überprüft bei CORS gar nichts. Er antwortet lediglich auf einen OPTIONS call, welche Domänen auf ihn zugreifen können und wenn da keine Antwort kommt, dann gilt Same origin policy.

Ich hoffe es ist jetzt klarer geworden.

10

Nun, dieses „OPTIONS“-Ping-Pong war das, was ich meinte. (Und mein Vergleich mit dem Tresor oben bezog sich darauf, dass ich sicher bin, dass es viele gibt, die ihren Server dann zurückgeben lassen „Joa, jeder darf hier mal ran“). „Sicherheit als Default“ und „Rechte als explizit zu konfigurierende Ausnahme“ ist ja OK. „Klarer“ ist jetzt ein bißchen das „wie“ und ein bißchen das „was“, aber …

Warum? Ich weiß, das ist die naive Frage, die man immer stellen kann. Warum wird bei dem angedeuteten Codeschnipsel nicht das hier gemacht:

<html>
   <head><title>fake bytewelt</title></head>
  <body>
    <script>
    var xhr = new XMLHttpRequest();
    xhr.open("POST", 'https://forum.byte-welt.net/posts.json', true);

    // PSEUDOCODE (!), natürlich, für etwas, was nur auf "byte-welt.net"
    // geht, aber nicht auf "fake-forum.com":
    xhr.setCookieFor(window.location);

    xhr.send('{"title":"HACKED", "raw":"Gesendet von fake"}');
    </script>
   </body>     
</html>

Ich meine, der Browser weiß, was er gerade anzeigt.

(Ein Argument, das ich im Moment für ein sehr starkes Argument halte, bei dem ich aber nicht sicher bin, ob es ein starkes Argument ist: Sowas wie Postman kennt das SOP/CORS-Problem nicht. Das sieht für mich stark danach aus, als wäre das SOP ein Versuch, ein Problem (auf der Ebene der Netzwerkkommunikation oder des Protokolls) zu lösen, das im Kern (ganz offensichtlich) in den Browserimplementierungen liegt…)

11

Nein, das ist eine reine Client Funktionalität. Spricht, wenn der Browser diese Informationen, wie ORIGIN, CSP etc. nicht interpertiert, dann hast du diesen Schutz auch nicht.

12

Man müsste hier etwas finden, das garantiert eindeutig ist für byte-welt.net, aber geheim ist. In Javascript gibt es number, string, objects… Und alles lässt sich irgendwie erzeugen. Du müsstest was finden, das ein Angreifer nicht erzeugen kann. Mir fehlt dazu gerade eine Idee.

Es geht hier echt nur darum, dass Szenario mit dem fake-forum zu verhindern. Also das ich dir einen Link schicke, und der Browser macht einen Request der von mir Manipulatiert ist in deinem Namen. Um nix anderes. Das spielt im Postman keine Rolle, denn um da den Cookie zu setzen, muss ich erstmal dran kommen.

13

Da werd’ ich mal versuchen, meinen Kopf drumzuwickeln. Im Moment klingt es, als würde sich der Browser demnach vor sich selbst schützen - d.h. als hätte sich der Browser das ganze SOP/CORS/OPTIONS-Gedöhns sparen können, wenn er nicht an anderer Stelle ~„irgendwelchen gefährlichen Zugriffe“ erlauben würde.

Auch zu…

Die Frage, die ich mir gerade z.B. stelle: Wenn nun in Postman in der nächsten Version ein „Render HTML Response Like A Website“-Feature dazukommt, ist das dann ein Problem? Nein? Und wenn man Scripte da drin ausführen kann? Nein? Und wenn da Cookies gesetzt werden können? Und wenn die Scripte weitere POSTs absetzen können? … … Ich sehe kein Problem, ausser, wenn dort zwei Postman-Instanzen laufen und die aus irgendeinem Grund kreuz und quer miteinander reden dürfen, oder Cookies irgendwo hin „geleakt“ werden - nämlich, indem sie automatisch in einer Schicht der Implementierung eingefügt werden, über die man selbst keine Kontrolle hat.

Der Browser aber doch schon:

Nun, das war pseudocode. Natürlich wäre das kein String, der da übergeben wird, sondern ein magisches

xhr.letTheRuntimeEngineAkaBrowserSetCookieForCurrentWindowLocation();

was der Browser dann in seiner Allmacht (d.h. seinem Wissen über die aktuelle Seite und die Cookies) entsprechend ausführt. Also obiges eben anstelle des

xhr.letTheRuntimeEngineAkaBrowserSetCookieForRequestTarget();

was (den bisherigen Erklärungen nach) dort anscheinend ja gemacht wird…

14

naja ein Grund ist ja, dass das cookie aus einer vorherigen session ( selbst nachdem der computer heruntergefahren wurde ) noch da ist. Das ist für mich als user sehr angenehm, weil ich mich am byte-welt forum in einem neuen Tab, oder wenn ich den browser neustarte, nicht neu anmelden muss. Das heist eine Zuordnung von Tab zu cookie ist nicht gewünscht als User.

15

Ja, wie gesagt, offenbar liegt das alles zu weit hinter meinem Horizont. Aber genauso, wie der Browser beim Rausschicken eines requests an byte-welt.net automagisch das cookie einsetzen kann, kann/könnte er das doch abhängig davon machen, auf welcher Seite man gerade ist. Ich meine, … jaja, wieder naiver Pesudocode:

void theBrowserShouldSendOut(Request request, String targetUrl) {
    request.addCookie(cookieFor(targetUrl));
    sendOut(request);
}

ändern zu

void theBrowserShouldSendOut(Request request, String targetUrl) {
    if (currentPage.equals(targetUrl)) {
        request.addCookie(cookieFor(targetUrl));
    }
    sendOut(request);
}

Problem gelöst. SOP abgeschafft. Alles sicher. Alle glücklich.

(Jaja, bewußt übertrieben naiv - ich kapier’s halt nicht … :roll_eyes: Es erscheint mir einfach „zu kompliziert“, und als hätte man da seeeehr lange irgendwelche unüberlegten Lösungen für Probleme (und weitere unüberlegte Lösungen für die aus der Unüberlegtheit der ersten Lösung resultierenden Probleme) übereinander gestapelt…)

16

Na, du musst bedenken, dass es eine Zeit gab :older_man: , vor 20-30 Jahren :older_man: , in der es sehr „Hip“ war, auf Seiten der großen Portale (z. B. Web De) ganz viele andere Seiten einzubetten, also ganz viele Frames usw. (auch unsichtbare…) zu anderen Seiten auf einer Seite darzustellen. Heute werden Seiten nicht mehr so „überladen“ - d. h., es ist unwahrscheinlicher, dass sich Ressourcen zweier unterschiedlicher Frames in irgendeiner Weise „überschneiden“ können; sprich praktisch, dass ein sensibler Cookie der Seite A an eine Seite B gelangen kann.

17

Also dem würde ich spontan wiedersprechen. Denn gerade heute sind solche Standards, und deren korrekte Umsetzung unglaublich wichtig.

  1. XSS Attacken sind OWASP TOP 10 (Platz 7)
    OWASP Top Ten | OWASP Foundation

  2. Zwar verwendet man heute seltener iFrames, möchte man meinen, aber es gibt sie weiterhin und dazu sind weitere Techniken (HTML Inhejction, DOM Shadowing, und und und) heute möglich, um das zu machen.

  3. Wenn man sich eine komperzielle Webseite anschaut, dann sieht man folgendes.

grafik
grafik544×1311 68.7 KB

Und da habe ich einen Ad-Blocker noch aktiviert. Da erkenne ich auf den ersten Blick MEHRERE Hosts, die mit meiner originalen Anfrage http://heise.de nicht viel zu tu haben.

Und es gibt Anwendnungen, z.B. die im Rahmen des Online Zugangs Gesetztes (OZG) entwickelt werden, die höchst persönliche Daten von mir verarbeiten sollen. Und selbst in diesem Forum hätte ich schon gerne, dass wenn ich die Seite aufrufe nicht jeder 0815 Bot 100 XSS Postings hinterlällst, und im Falle eines Administrotors dessen Account übernimmt oder in meinem Fall ggf. aus der Sandbox ausbricht und andere Sachen anrichtet.

Jenachdem welche Anwendung man entwickelt oder welche Technik man einsetzt, muss man das als Professional machen. Daneben gibt es ja Seiten, wie OWASP oder das Bundesamt für Sicherheit in der Informationstechnik (BSI) die entsprechend Empfehlungen ausprechen, wie man sichere Webanwendungen baut. Ich empfehle diese entsprechended zu lesen, wenn man professionelle Anwendungen, entwickelt.

18

Die Ziele stehen ja außer Frage. Ich verstehe nur (immernoch) nicht (hinreichend), warum man den steinigen Weg der SOP gegangen ist. Aussagen wie die von Wikipedia…

  • Die SOP ist als Sicherheitsmechanismus nicht ausreichend wirksam. …
  • Andererseits sind die von der SOP gezogenen Grenzen in vielen Fällen unerwünscht. …

… decken sich damit: Man macht ~„irgendwas“, was bewirkt, dass Dinge, die eigentlich einfach sein sollten, auf einmal schwierig bis unmöglich werden, und das vorgegebene Ziel wird nur sehr bedingt erreicht. Das ist doch also ganz offensichtlich nicht wirklich so durchdacht, wie man es sich wünschen würde.

Was nun in dem geposteten Screenshot für eine Information steckt, ist mir nicht klar: Ja, wenn man eine Seite besucht, lädt die Seite vielleicht scripte von einer anderen Seite runter.

(Schon darüber könnte man lange reden. Ich finde, das sollte sie nicht. Warum liegt der Script nicht auf der eigentlichen Seite? Jaja, wenn 10 Seiten alle bar.com/jquery.js einbetten, ist das durch caching & Co beim Laden schneller, als wenn es wirklich 10 mal geladen werden müßte. Aber spätestens auf der Seite einer Bank (oder bei allem, was eben sicherheitskritisch ist - selbst, wenn es nur um das Absetzen eines Posts geht) würde ich erwarten, dass der Betreiber der Seite ~„die volle Verantwortung“ übernimmt, und die Daten selbst hostet. Aber das führt jetzt vielleicht zu weit…)

Der Punkt ist: Ob dieses Script nun von good.com runtergeladen wird oder von bad.com spielt eigentlich keine Rolle. Wenn ich auf REAL-forum.com bin soll das Script z.B. einen POST absetzen können (mit Cookie und allem drum und dran). Wenn ich auf FAKE-forum.com bin, soll es das nicht können.

Nochmal ganz konkret: Ist meine „Annahme“ richtig, dass das alles im Kern dadurch verursacht wird, dass…

  • Scripte zum Beispiel (!) über Tabs hinweg im Browser rumpfuschen können (vielleicht zweitrangig)
  • und Cookies direkt vom Browser nur anhand der Ziel-URL in die Request gepackt werden?

Oder am (naiven Pseudocode) Beispiel von oben: Sehe ich es richtig, dass an irgendeiner Stelle im Browser sowas gemacht wird wie

request.addCookieFor(targetUrl);

und die ganzen Probleme nicht existieren würden, wenn diese Zeile

request.addChookieFor(currentlyViewnUrl);

lauten würde? (Jaja, das ist zu plakativ, um es mit „Ja“ oder „Nein“ beantworten zu können - es geht um die grundsätzliche Richtung…)

Najaaa. Natürlich gibt es Leute, die sich damit auskennen müssen. Aber für normale (auch „professionelle“) Anwendungsentwickler sollte es eine Schicht (im Sinne einer Abstraktionsebene) geben, auf der sie sich nicht mehr damit auseinandersetzen müssen. Der Vergleich ist nicht perfekt, aber IMHO gut genug, um ihn hier anzubringen: Wenn du in ein Auto steigen und losfahren willst, dann muss du dir nicht sowas wie § 41 StVZO - Einzelnorm durchlesen - auch nicht als „professioneller“ Autofahrer (Taxifahrer). Du musst nur wissen: „Mittleres Pedal = Langsamer“. Und das ist auch gut so.

1 „Gefällt mir“
19

Deine Annahme ist so halb richtig. Es stimmt, dass man damit einem Problem begegnet, dass es so nicht gäbe, wenn man das so macht, wie du vorschlägst. Aber dann würden andere Sachen, wie tracking cookies nicht funktionieren. Ob das gut ist, steht auf einem anderen Blatt.

Wenn man das alles so sehen würde, dass irgendjemand das mal so beschlossen hat, dass das so alles ist, dann sieht das auch alles nach einer doofen Lösung aus. Aber dem ist halt nicht so. Irgendwann hat jemand gedacht, wenn du einen Request machst musst du die cookies mitschicken, die die Domäne dir mal geschickt hast. Dann kam jemand und hat eine Javascript API spezifiziert, die sich genau so verhält wie wenn ich ne URL in den Browser eingebe.Irgendwer hat dann nen Angriff gestartet und dann hat sich jemand eine Lösung ausgedacht. Da es aber schon gewollte Use-Cases gab, wie tracking cookies konnte man das nicht einfach verbieten.
Du musst das im Kontext sehen, ich glaub nicht das die Leute dumm sind, sondern es Umstände gibt, in denen man Probleme lösen muss.

1 „Gefällt mir“
20

Von „dumm“ war ja nicht die Rede. Zumindest nicht direkt :wink: Das passt im wesentlichen zu dem, was ich ja oben schon geschrieben hatte:

(und man könnte die Liste der Sprüche noch erweitern mit „nachher ist man immer schlauer“ und so).

Aber so (rückblickend, und ohne fachlich tiefe Ahnung davon zu haben) wirkt es halt … *räusper* … befremdlich.

(Und ich könnte mir vorstellen, dass vor 20 Jahren jemand in einem Meeting mit der gebotenen Vorsicht und dem kritischen Blick gesagt hat: „Hey, das ist vielleicht keine so gute Idee, und könnte diese-und-jene Probleme verursachen“, aber dann als Nörgler, Bremser und Schwarzseher abgestempelt wurde, und übergangen wurde, von den dynamisch-engagierten lösungsorientierten „(einfach-mal-irgendwie)-Machern“… :roll_eyes: )

Naja. Jetzt haben wir halt den Salat, und jedes Framework darf sich mit CORS-Konfigurationen rumschlagen, es können tools und libraries entwickelt werden, mit denen man die SOP umgehen kann, und jeder Browser kann ein verstecktes kleines Flagchen haben, mit dem man es ausschalten kann. Das sichert immerhin Arbeitsplätze…

1 „Gefällt mir“