Fetch lokal nicht möglich
- Ersteller Bennyaa
- Erstellt am
Joshinator
Commander
- Registriert
- Dez. 2017
- Beiträge
- 2.337
Du hast ja schon verstanden dass der Mechanismus im Browser selbst greift.Bennyaa schrieb:
Das ist kein harter Sicherheitsmechanismus den der Server erzwingen kann, der Server antwortet nur mit "
ABC.de, DEF.de dürfen Ressourcen von mir laden", mehr als ein Vorschlag ist das nicht. Sollte Chrome morgen entscheide CORS nicht mehr zu berücksichtigen steht das Scheunentor offen.Wenn der Server keinen CORS-Header setzt gilt SOP (wurd hier schon gennant), same origin policy.
Browser Extensions können diesen Check im Browser deaktivieren, das sorgt einfach dafür das dem Browser egal ist was der Server im CORS-Header vorschlägt.
Da man aktiv CORS im Browser umgehen muss ist das aber kein Sicherheitsproblem, da kann man dem User direkt sagen installier meine .exe
Wenn ein "Hacker" der Banking-Website von
sparkasse.de Javascript unterschieben kann das alle Daten an mein-hacker-server.de sendet würde CORS das standardmäßig wirklich blockieren weil es nicht SOP ist.Jetzt liegt es beim Hacker dafür zu sorgen das sein Server sagt "
sparkasse.de darf mein-hacker-server.de Daten senden".Sein Server kann dann "problemlos" die Daten weitersenden weil Server CORS nicht unterliegen. Wenn jemand Code auf nem Server ausführen kann hat er sowieso Kontrolle.
Im Browser braucht es eben entsprechende Mechanismen weil man "fremden Code" ausführt.
Ich meinte damit folgendes:
Ich kann ja mit einem via Express erzeugten Server auf Port 3000 einen fetch zu einem Server auf Port 8080 absetzen.
Könnte jetzt nicht der Hacker von seinem Server das gleiche zum sparkassenserver machen?
Also quasi erst die Daten von meinem Browser an seinen eigenen Server senden und dann von seinem Server an den Sparkassen Server?
Verstehe ich doch richtig, dass Server zu Server IMMER geht und dort nicht geschaut wird, ob es SOP ist. Oder?
Das schaut doch nur der Browser, richtig?
Ich kann ja mit einem via Express erzeugten Server auf Port 3000 einen fetch zu einem Server auf Port 8080 absetzen.
Könnte jetzt nicht der Hacker von seinem Server das gleiche zum sparkassenserver machen?
Also quasi erst die Daten von meinem Browser an seinen eigenen Server senden und dann von seinem Server an den Sparkassen Server?
Verstehe ich doch richtig, dass Server zu Server IMMER geht und dort nicht geschaut wird, ob es SOP ist. Oder?
Das schaut doch nur der Browser, richtig?
Joshinator
Commander
- Registriert
- Dez. 2017
- Beiträge
- 2.337
Was du beschreibst ist ein sogenannter Proxy, genau das was man in der Schule damals benutzt hat um trotzdem auf Schülervz & Co zu kommen, oder genau das gleiche Prinzip was hinter Tor steckt.
Das Bankbeispiel macht aber keinen Sinn, warum sollte der Hacker denn die Daten als Proxy extra an die Sparkasse senden (wo er auch Cookies, IP & Co fälschen/kopieren muss)?
Wenn er Scripte in die Bankwebseite einbauen kann ist es wesentlich einfacher die Daten ganz normal an die Bank zu senden und parallel dazu einen weiteren Request zu seinem Server zu machen.
Aber da artet die Diskussion schon in eine ganz andere Richtung aus, CORS ist nicht der einzige Sicherheitsmechanismus der dazwischen springen sollte.
So eine Bank ist stark gegen XSS gesichert damit erst gar nicht fremde Scripte ausgeführt werden.
Mit CSP können Websites Whitelists erstellen damit der Browser erst gar nicht versucht Daten an eine unbekannte URL zu senden.
Für Webdev-Sicherheit ist OWASP eine tolle Quelle die so ziemlich alle Stolpersteine erklären und zeigen wie man die vermeidet.
Du verstehst das richtig, Server kennen kein CORS, bzw. richten sich standardmäßig nicht nach den CORS-Headern die gesendet werden.
Wozu auch, jeder Code der im Server sitzen würde um CORS zu erzwingen kann deaktiviert werden, und spätestens per Curl kann man CORS umgehen.
CORS (und CSP und alle anderen solcher Sicherheitsmechanismen) im Browser funktionieren weil der durchschnittliche User die nicht deaktivieren kann und der Browser so nicht zu einem Bot in nem Botnetz wird.
Im Endeffekt ist das wie die Frage: würdest du lieber eine pferde-große Ente bekämpfen oder 1000 enten-große Pferde.
Eine handvoll Server die Unsinn treiben kann man recht einfach aussperren, 1000 Browser die unwissend eine andere Seite per fetch DDoSen ist was aufwendiger.
Gibt genug legitime Usecases für Proxies, nicht nur um CORS zu umgehen wenn es gewünscht ist. Aber als Seitenbetreiber kann man Proxies (soll heißen Server) schnell aussperren wenn die zu viel lärm verursachen.
Ein Server ist zwar stärker als die meisten normalen Browser, aber die Maße machts.
Die größten DDoS-Attacken kommen nicht von Servern, sondern von unsicheren IoT Geräten, und durch CORS reihen sich Browser nicht einfach so in solche Botnetze ein.
Das Bankbeispiel macht aber keinen Sinn, warum sollte der Hacker denn die Daten als Proxy extra an die Sparkasse senden (wo er auch Cookies, IP & Co fälschen/kopieren muss)?
Wenn er Scripte in die Bankwebseite einbauen kann ist es wesentlich einfacher die Daten ganz normal an die Bank zu senden und parallel dazu einen weiteren Request zu seinem Server zu machen.
Aber da artet die Diskussion schon in eine ganz andere Richtung aus, CORS ist nicht der einzige Sicherheitsmechanismus der dazwischen springen sollte.
So eine Bank ist stark gegen XSS gesichert damit erst gar nicht fremde Scripte ausgeführt werden.
Mit CSP können Websites Whitelists erstellen damit der Browser erst gar nicht versucht Daten an eine unbekannte URL zu senden.
Für Webdev-Sicherheit ist OWASP eine tolle Quelle die so ziemlich alle Stolpersteine erklären und zeigen wie man die vermeidet.
Du verstehst das richtig, Server kennen kein CORS, bzw. richten sich standardmäßig nicht nach den CORS-Headern die gesendet werden.
Wozu auch, jeder Code der im Server sitzen würde um CORS zu erzwingen kann deaktiviert werden, und spätestens per Curl kann man CORS umgehen.
CORS (und CSP und alle anderen solcher Sicherheitsmechanismen) im Browser funktionieren weil der durchschnittliche User die nicht deaktivieren kann und der Browser so nicht zu einem Bot in nem Botnetz wird.
Im Endeffekt ist das wie die Frage: würdest du lieber eine pferde-große Ente bekämpfen oder 1000 enten-große Pferde.
Eine handvoll Server die Unsinn treiben kann man recht einfach aussperren, 1000 Browser die unwissend eine andere Seite per fetch DDoSen ist was aufwendiger.
Gibt genug legitime Usecases für Proxies, nicht nur um CORS zu umgehen wenn es gewünscht ist. Aber als Seitenbetreiber kann man Proxies (soll heißen Server) schnell aussperren wenn die zu viel lärm verursachen.
Ein Server ist zwar stärker als die meisten normalen Browser, aber die Maße machts.
Die größten DDoS-Attacken kommen nicht von Servern, sondern von unsicheren IoT Geräten, und durch CORS reihen sich Browser nicht einfach so in solche Botnetze ein.
Zuletzt bearbeitet:
kim88
Lt. Commander
- Registriert
- Sep. 2016
- Beiträge
- 1.851
Wenn etwas im Internet abrufen kann, kann man das per Server oder Script auch abfragen. Wenn man das nicht will muss man seinen Server entsprechend asichern. Z.b. nur per über eine bestimmte IP verfügbar etc.
Die Idee des Internet war/ist es ja unterschiedliche Computer miteinander zu verbinden.
CORS, CSP etc wurden ja erst eingeführt als man bemerkt hat das hier auch viel uncooles passieren kann. Bzw. vor der Einführung von JavaScript war das alles gar nicht nötig.
Die Idee des Internet war/ist es ja unterschiedliche Computer miteinander zu verbinden.
CORS, CSP etc wurden ja erst eingeführt als man bemerkt hat das hier auch viel uncooles passieren kann. Bzw. vor der Einführung von JavaScript war das alles gar nicht nötig.
Ähnliche Themen
