Die Same-Origin-Policy ist eine Browser-Sicherheitsfunktion, die Dokumente und Skripts eines Ursprungs können mit Ressourcen interagieren die einen anderen Ursprung haben.
Ein Browser kann Ressourcen von mehreren Websites gleichzeitig laden und anzeigen. Möglicherweise haben Sie mehrere Tabs gleichzeitig geöffnet sind oder eine Website mehrere iFrames von unterschiedlichen Websites. Wenn es keine Beschränkung für Interaktionen zwischen diesen und ein Skript von einem Angreifer manipuliert wurde, im Browser eines Nutzers dargestellt wird.
Dies verhindert die Same-Origin-Policy, da der Lesezugriff auf Ressourcen, die von einem anderen Ursprung geladen wurden. „Aber Moment.“ sagen Sie: „Ich lade Bilder und Skripts anderer Quellen immer verwendet.“ Browser ermöglichen es einigen Tags, Ressourcen aus einer anderen Quelle einbetten. Diese Richtlinie ist größtenteils und Ihre Website kann Sicherheitslücken wie Clickjacking iFrames. Sie können das ursprungsübergreifende Lesen einschränken dieser Tags mithilfe eines Content Security Richtlinien:
Was gilt als Same-Origin?
Ein Ursprung wird durch das Schema (z. B. Protokoll, auch als Protokoll bezeichnet) definiert.
HTTP oder HTTPS), Port (falls angegeben) und Host. Wenn alle drei gleich sind
für zwei URLs gelten sie als Same Origin. Beispiel:
http://www.example.com/foo ist der gleiche Ursprung wie
http://www.example.com/bar
aber nicht https://www.example.com/bar
weil das Schema anders ist.
Was ist erlaubt und was ist blockiert?
Im Allgemeinen ist das Einbetten einer ursprungsübergreifenden Ressource zulässig, während das Lesen eines ursprungsübergreifende Ressource blockiert.
| iFrames |
Ursprungsübergreifende Einbettungen sind normalerweise zulässig (abhängig von der X-Frame-Options-Anweisung), ursprungsübergreifende Lesevorgänge (z. B. mithilfe von JavaScript für den Zugriff auf ein Dokument in einem iFrame) jedoch nicht.
|
| CSS |
Ursprungsübergreifender CSS-Code kann mithilfe eines <link>-Elements oder eines @import-Elements in einer CSS-Datei eingebettet werden. Möglicherweise ist der richtige Content-Type-Header erforderlich.
|
| Formulare |
Ursprungsübergreifende URLs können als action-Attributwert von Formularelementen verwendet werden. Eine Webanwendung kann Formulardaten in ein ursprungsübergreifendes Ziel schreiben.
|
| Bilder | Das Einbetten ursprungsübergreifender Bilder ist zulässig. Das Lesen ursprungsübergreifender Bilddaten, z. B. das Abrufen von Binärdaten aus einem ursprungsübergreifenden Bild mit JavaScript, wird jedoch blockiert. |
| Multimedia |
Ursprungsübergreifende Video- und Audioinhalte können mithilfe der Elemente <video> und <audio> eingebettet werden.
|
| Skript | Ursprungsübergreifende Skripts können eingebettet werden. Der Zugriff auf bestimmte APIs (z. B. ursprungsübergreifende Abrufanfragen) wird jedoch möglicherweise blockiert. |
TODO: Entwicklerwebsite – Think & Check-Test
Clickjacking verhindern
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Angriff, der als „Clickjacking“ bezeichnet wird bettet eine Website in ein iframe ein und überlagert
transparente Schaltflächen, die auf ein anderes Ziel verweisen. Nutzer werden ausgetrickst
und glauben, dass sie auf Ihre Anwendung zugreifen,
während sie gleichzeitig Daten an die
zu erkennen.
Wenn Sie andere Websites daran hindern möchten, Ihre Website in einen iFrame einzubetten, fügen Sie einen Inhalt hinzu
Sicherheitsrichtlinie mit frame-ancestors
an die HTTP-Header an.
Alternativ können Sie den HTTP-Headern X-Frame-Options hinzufügen.
MDN
finden Sie eine Liste mit Optionen.
Zusammenfassung
Hoffentlich sind Sie jetzt etwas erleichtert, für Sicherheit im Web. Auch wenn Browser versuchen, den Zugriff zu blockieren, auf ursprungsübergreifende Ressourcen zugreifen möchten, Anwendungen. Im nächsten Leitfaden erfahren Sie mehr über Cross-Origin Resource Sharing (CORS) und wie Sie dem Browser mitteilen, dass das Laden ursprungsübergreifender Ressourcen die aus vertrauenswürdigen Quellen stammen.