it-swarm.com.de

Warum blockieren Browser nicht standardmäßig standortübergreifende POSTs?

Mit der Same-Origin-Richtlinie (SOP) blockieren Browser die Skripterstellung von einem Origin, um sich mit einem anderen zu messen, es sei denn, sie werden ausdrücklich angewiesen, dies nicht zu tun. Standortübergreifende POSTs sind jedoch weiterhin zulässig, wodurch der Vektor für CSRF-Angriffe erstellt wird. Die Verteidigung besteht aus Fälschungsschutzmarken.

Aber warum folgen Browserentwickler beim Umgang mit POSTs nicht einfach der gleichen SOP-Philosophie?

45
Andrada2

Theoretisch ist Ihr Vorschlag durchaus vernünftig. Wenn Browser alle Cross Origin POST -Anfragen standardmäßig blockieren und eine CORS-Richtlinie zum Entsperren erforderlich wären), würden viele der CSRF-Schwachstellen auf magische Weise verschwinden. Als Entwickler würden Sie nur Sie müssen sicherstellen, dass der Serverstatus bei GET-Anforderungen nicht geändert wird. Es werden keine Token benötigt. Das wäre schön.

Aber so wurde das Internet damals nicht aufgebaut, und es gibt jetzt keine Möglichkeit, es zu ändern. Es gibt viele legitime Verwendungszwecke von Cross Origin POST -Anfragen. Wenn Browser die Regeln während des Spiels plötzlich ändern und dies verbieten, funktionieren Websites, die sich auf die alten Regeln stützen, nicht mehr Wir versuchen so weit wie möglich zu vermeiden. Leider müssen wir mit unserer Vergangenheit leben.

Gibt es also eine Möglichkeit, das System so zu optimieren, dass es besser funktioniert, ohne etwas zu beschädigen? Eine Möglichkeit wäre, ein neues HTTP-Verb einzuführen, nennen wir es PEST, das genauso funktioniert wie POST nur, dass alle PEST-Anfragen vorab ausgeführt werden und den CORS-Richtlinien unterliegen. Das ist nur ein dummer Vorschlag, den ich erfunden, aber es zeigt, wie wir die Standards entwickeln können, ohne sie zu brechen.

62
Anders

Das Problem ist nicht die Anforderungsmethode: CSRF kann auch mit einer GET-Anforderung durchgeführt werden. Das Problem besteht stattdessen darin, dass Authentifizierungsinformationen wie (Sitzungs-) Cookies oder der Header Authorization automatisch in die standortübergreifende Anforderung aufgenommen werden, wodurch CSRF möglich wird. Daher würde die Abschwächung nicht darin bestehen, die Verwendung solcher Methoden in standortübergreifenden Anforderungen zu verbieten, sondern diese Authentifizierungsinformationen nicht zu senden.

Bei Cookies gibt es einen Vorschlag für ein samesite flag , der sicherstellen würde, dass das Cookie nicht innerhalb von standortübergreifenden Anfragen gesendet wird. Leider ist das Flag derzeit nur verfügbar in Chrome , wird aber ab Mai 2018 für Firefox mit v60 verfügbar sein. Außerdem wäre es viel besser gewesen, wenn diese Einschränkung standardmäßig aktiviert wäre und sein müsste explizit geändert, um weniger sicher zu sein (wie in CORS), anstatt standardmäßig unsicher zu sein. Nur dies würde eine ernsthafte Änderung des aktuellen Verhaltens bedeuten und wahrscheinlich viele bestehende Anwendungen beschädigen.

23
Steffen Ullrich

Ich stimme Anders teilweise nicht zu

Aber so wurde das Internet damals nicht aufgebaut, und es gibt jetzt keine Möglichkeit, es zu ändern.

Die Entwickler der wichtigsten Browser haben die Möglichkeit, das Internet zu ändern und Webentwickler in die gewünschte Richtung zu führen. Veraltete standortübergreifende POST -Daten wären möglich, wenn sie als große Bedrohung angesehen würden. Es gibt Beispiele für solche Fortschritte bei anderen Dingen, obwohl sie weder plötzlich noch schnell sind:

  • Blitz. Während es früher als die Zukunft des Webs angesehen wurde, haben große Browser angekündigt, es in Zukunft nicht mehr zu unterstützen, und Webentwickler passen sich an.

  • HTTPS wurde von den Browsern langsam erzwungen, mit kleinen Schritten zur Warnung, dass einfaches HTTP unsicher ist. Wir werden vielleicht irgendwann eine Welt sehen, in der einfaches HTTP langsam zu Tode erstickt.

Ich würde mir wünschen, dass dies dazu führt, dass Sicherheit Vorrang vor Kompatibilität hat. Natürlich wäre eine so große Veränderung nicht etwas, das man über Nacht tun könnte, sondern indem man Alternativen gibt und entmutigend zuerst. Der Weg, um dies zu erreichen, könnte folgendermaßen aussehen:

  1. Einführung eines Richtlinienheaders mit gleichem Ursprung für POST -Anfragen, der eine ausdrückliche Zustimmung ermöglicht.
  2. Beginn der Warnung vor möglichen Sicherheitsproblemen auf Cross-Site POST ohne Zustimmung.
  3. Websites, die diese Funktionalität noch benötigen, beginnen sich langsam anzupassen, um die Warnung zu entfernen.
  4. Nach einer langen Übergangszeit könnte die Aktion rauer geändert werden.

Das Entmutigen von POST auf einfachem HTTP kommt dem Entmutigen von standortübergreifendem POST ziemlich nahe, da beide gegen die Standards verstoßen. Dies ist nur ein bewusster Verlust der Abwärtskompatibilität zur Erhöhung der Sicherheit.

9
Esa Jokinen