From 4ab365b110f2f1f2b736326b7059244a32115089 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:45:38 +0100 Subject: unslug de: move --- files/de/web/http/caching/index.html | 73 ++++++++++ files/de/web/http/caching_faq/index.html | 73 ---------- .../index.html | 37 ------ .../cors/errors/corsfehltquelleerlauben/index.html | 59 --------- .../corsmissingallowheaderfrompreflight/index.html | 37 ++++++ .../cors/errors/corsmissingalloworigin/index.html | 59 +++++++++ files/de/web/http/public_key_pinning/index.html | 147 +++++++++++++++++++++ 7 files changed, 316 insertions(+), 169 deletions(-) create mode 100644 files/de/web/http/caching/index.html delete mode 100644 files/de/web/http/caching_faq/index.html delete mode 100644 files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html delete mode 100644 files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html create mode 100644 files/de/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html create mode 100644 files/de/web/http/cors/errors/corsmissingalloworigin/index.html create mode 100644 files/de/web/http/public_key_pinning/index.html (limited to 'files/de/web/http') diff --git a/files/de/web/http/caching/index.html b/files/de/web/http/caching/index.html new file mode 100644 index 0000000000..79aa913713 --- /dev/null +++ b/files/de/web/http/caching/index.html @@ -0,0 +1,73 @@ +--- +title: HTTP Caching FAQ +slug: Web/HTTP/Caching_FAQ +tags: + - Cache + - HTTP + - Necko + - NeedsContent + - header +translation_of: Web/HTTP/Caching +--- +

Was wird im Cache gespeichert?

+ +

Der Mozilla Cache beinhaltet alle Dokumente, die via HTTP vom Benutzer heruntergeladen wurden. Dies mag sich zunächst widersprüchlich anhören, dieses Verhalten ermöglicht jedoch das Vor- und Zurück-Navigieren, Speichern, sowie die Anzeige des Quelltextes etc. im Browser, ohne dabei zusätzliche Serveranfragen zu benötigen. Somit verbessert es auch die Offline-Nutzung von temporär gespeicherten Inhalten im Cache.

+ +

Was ist mit Dokumenten die mit "Cache-control: no-cache"  in der Kopfzeile (Header) gesendet werden?

+ +

Auch "no-cache" Dokumente werden von uns aufgrund der oben genannten Gründe im Cache gespeichert.

+ +

Sorgt das nicht dafür, dass abgelaufene Inhalte bereitgestellt werden?

+ +

Nein, denn jedes Dokument, das im Mozilla Cache gespeichert wird, erhält eine Gültigkeitsdauer. Lädt Mozilla dieses Dokument für eine normale Ansicht, wird die Gültigkeit berücksichtigt. Wenn nötig, wird ein aus dem Cache zu ladendes Dokument mit dem Server abgeglichen und gegebenenfalls neu geladen, bevor es dem Benutzer angezeigt wird.

+ +

Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?

+ +

Mozilla strebt danach, RFC 2616 zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Jede der folgenden Antwort-Kopfzeilen generiert eine stets abgelaufene Gültigkeitsdauer, z.B. "00:00:00 UTC, January 1, 1970":

+ +
Cache-control: no-cache
+Cache-control: no-store
+Pragma: no-cache
+Expires: 0
+ +

Bemerkenswerter Weise sind die Werte Expires: 0 und Pragma: no-cache technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, geschieht die Berechnung der Gültigkeitsdauer nach dem Algorithmus, welcher in RFC 2616, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.

+ +

Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene Age-Angabe in der Antwort-Kopfzeile beeinflusst, die z.B. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorithmus, der versucht, Fehler bei der Zeitverschiebung zu verhindern, wird in RFC 2616, Abschnitt 13.2.3 beschrieben.

+ +

Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile Cache-control: max-age=N angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer Expires-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in Date enthaltenen Wertes. Sollte sich letztlich keine Expires-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem Last-Modified Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert Date abzüglich des Wertes Last-Modified geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des RFC 2616 vorgeschlagen wird. 

+ +

Die Gültigkeitsdauer berechnet sich somit folgendermaßen:

+ +
ablaufZeit = reaktionsZeit + neuheitsLebenszeit - aktuellesAlter
+ +

Wobei reaktionsZeit dem Zeitwert entspricht, zu dem der Browser die Antwort erhalten hat.

+ +

Gibt es weitere Faktoren, welche die Revalidation beinflussen?

+ +

Die Revalidation wird ausgelöst, sobald ein User die Seite neu lädt (z.B. mittels des Neu-Laden-Knopfes). Ebenso wird sie beim normalen browsen ausgelöst, wenn in den Antwort-Kopfzeilen Cache-control: must-revalidate enthalten ist. Ein weiterer Faktor sind die Einstellungen des Cache-Management im Bereich Erweitert->Netzwerk der Firefox-Einstellungen. Hier kann als Option gewählt werden, dass Dokumente bei jedem Laden neu validiert werden ("Nachfragen, wenn Websites Daten für die Verwendung im Offline-Modus speichern möchten").

+ +

Wie funktioniert die Cache-Valdiation?

+ +

Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angewendet werden, wenn der Server entweder eine starke Valdiation (strong validation) oder eine schwache Valdiation (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des RFC 2616 beschrieben.

+ +

Der ETag-Wert in den Antwort-Kopfzeilen ist ein Wert, der nicht für den User Agent einsehbar ist (opaque-to-the-useragent) und als starker Validator genutzt werden kann (strong validator). Ist der ETag-Wert in den Antwort-Kopfzeilen vorhanden, kann der Browser einen If-None-Match-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.

+ +

Der Last-Modified-Wert in den Antwort-Kopfzeilen kann als schwacher Validator (weak validator) genutzt werden. Er wird als schwach eingestuft, da er nur eine 1-Sekunden-Lösung ermöglicht. Wenn der Last-Modified-Wert in den Antwort-Kopfzeilen enthalten ist, kann der Browser einen If-Modified-Since-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.

+ +

Sobald eine Validierungs-Anfrage gestellt wurde, kann der Server diese entweder ignorieren und mit einem normalen 200 OK-Statuscode antworten, oder aber einen 304 Not Modified-Statuscode zurückgeben um den Browser anzuweisen, die im Cache befindliche Kopie des Dokumentes zu verwenden. Letzere kann ebenfalls Werte in der Antwort-Kopfzeile enthalten, welche die Gültigkeit des Dokumentes im Cache aktualisieren.

+ +

Was ist mit...?

+ +

Ich beabsichtige, diese Dokumentation in Zukunft zu erweitern. Fühlen Sie sich frei, mir eine E-Mail mit Ihren Fragen oder Kommentaren zu schreiben.

+ +
+

Informationen zum Original-Dokument

+ + +
+ +

 

diff --git a/files/de/web/http/caching_faq/index.html b/files/de/web/http/caching_faq/index.html deleted file mode 100644 index 79aa913713..0000000000 --- a/files/de/web/http/caching_faq/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: HTTP Caching FAQ -slug: Web/HTTP/Caching_FAQ -tags: - - Cache - - HTTP - - Necko - - NeedsContent - - header -translation_of: Web/HTTP/Caching ---- -

Was wird im Cache gespeichert?

- -

Der Mozilla Cache beinhaltet alle Dokumente, die via HTTP vom Benutzer heruntergeladen wurden. Dies mag sich zunächst widersprüchlich anhören, dieses Verhalten ermöglicht jedoch das Vor- und Zurück-Navigieren, Speichern, sowie die Anzeige des Quelltextes etc. im Browser, ohne dabei zusätzliche Serveranfragen zu benötigen. Somit verbessert es auch die Offline-Nutzung von temporär gespeicherten Inhalten im Cache.

- -

Was ist mit Dokumenten die mit "Cache-control: no-cache"  in der Kopfzeile (Header) gesendet werden?

- -

Auch "no-cache" Dokumente werden von uns aufgrund der oben genannten Gründe im Cache gespeichert.

- -

Sorgt das nicht dafür, dass abgelaufene Inhalte bereitgestellt werden?

- -

Nein, denn jedes Dokument, das im Mozilla Cache gespeichert wird, erhält eine Gültigkeitsdauer. Lädt Mozilla dieses Dokument für eine normale Ansicht, wird die Gültigkeit berücksichtigt. Wenn nötig, wird ein aus dem Cache zu ladendes Dokument mit dem Server abgeglichen und gegebenenfalls neu geladen, bevor es dem Benutzer angezeigt wird.

- -

Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?

- -

Mozilla strebt danach, RFC 2616 zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Jede der folgenden Antwort-Kopfzeilen generiert eine stets abgelaufene Gültigkeitsdauer, z.B. "00:00:00 UTC, January 1, 1970":

- -
Cache-control: no-cache
-Cache-control: no-store
-Pragma: no-cache
-Expires: 0
- -

Bemerkenswerter Weise sind die Werte Expires: 0 und Pragma: no-cache technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, geschieht die Berechnung der Gültigkeitsdauer nach dem Algorithmus, welcher in RFC 2616, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.

- -

Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene Age-Angabe in der Antwort-Kopfzeile beeinflusst, die z.B. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorithmus, der versucht, Fehler bei der Zeitverschiebung zu verhindern, wird in RFC 2616, Abschnitt 13.2.3 beschrieben.

- -

Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile Cache-control: max-age=N angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer Expires-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in Date enthaltenen Wertes. Sollte sich letztlich keine Expires-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem Last-Modified Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert Date abzüglich des Wertes Last-Modified geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des RFC 2616 vorgeschlagen wird. 

- -

Die Gültigkeitsdauer berechnet sich somit folgendermaßen:

- -
ablaufZeit = reaktionsZeit + neuheitsLebenszeit - aktuellesAlter
- -

Wobei reaktionsZeit dem Zeitwert entspricht, zu dem der Browser die Antwort erhalten hat.

- -

Gibt es weitere Faktoren, welche die Revalidation beinflussen?

- -

Die Revalidation wird ausgelöst, sobald ein User die Seite neu lädt (z.B. mittels des Neu-Laden-Knopfes). Ebenso wird sie beim normalen browsen ausgelöst, wenn in den Antwort-Kopfzeilen Cache-control: must-revalidate enthalten ist. Ein weiterer Faktor sind die Einstellungen des Cache-Management im Bereich Erweitert->Netzwerk der Firefox-Einstellungen. Hier kann als Option gewählt werden, dass Dokumente bei jedem Laden neu validiert werden ("Nachfragen, wenn Websites Daten für die Verwendung im Offline-Modus speichern möchten").

- -

Wie funktioniert die Cache-Valdiation?

- -

Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angewendet werden, wenn der Server entweder eine starke Valdiation (strong validation) oder eine schwache Valdiation (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des RFC 2616 beschrieben.

- -

Der ETag-Wert in den Antwort-Kopfzeilen ist ein Wert, der nicht für den User Agent einsehbar ist (opaque-to-the-useragent) und als starker Validator genutzt werden kann (strong validator). Ist der ETag-Wert in den Antwort-Kopfzeilen vorhanden, kann der Browser einen If-None-Match-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.

- -

Der Last-Modified-Wert in den Antwort-Kopfzeilen kann als schwacher Validator (weak validator) genutzt werden. Er wird als schwach eingestuft, da er nur eine 1-Sekunden-Lösung ermöglicht. Wenn der Last-Modified-Wert in den Antwort-Kopfzeilen enthalten ist, kann der Browser einen If-Modified-Since-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.

- -

Sobald eine Validierungs-Anfrage gestellt wurde, kann der Server diese entweder ignorieren und mit einem normalen 200 OK-Statuscode antworten, oder aber einen 304 Not Modified-Statuscode zurückgeben um den Browser anzuweisen, die im Cache befindliche Kopie des Dokumentes zu verwenden. Letzere kann ebenfalls Werte in der Antwort-Kopfzeile enthalten, welche die Gültigkeit des Dokumentes im Cache aktualisieren.

- -

Was ist mit...?

- -

Ich beabsichtige, diese Dokumentation in Zukunft zu erweitern. Fühlen Sie sich frei, mir eine E-Mail mit Ihren Fragen oder Kommentaren zu schreiben.

- -
-

Informationen zum Original-Dokument

- - -
- -

 

diff --git a/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html b/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html deleted file mode 100644 index d40ac7b5b5..0000000000 --- a/files/de/web/http/cors/errors/corsfehlenderallowheaderauspreflight/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: >- - Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile 'Access-Control-Allow-Headers' - aus dem CORS-Preflight-Kanal -slug: Web/HTTP/CORS/Errors/CORSFehlenderAllowHeaderAusPreflight -tags: - - CORS - - CORSMissingAllowHeaderFromPreflight - - Cross-Origin - - Fehler - - HTTP - - HTTPS - - Meldungen - - Sicherheit - - Ursachen -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight ---- -
{{HTTPSidebar}}
- -

Grund

- -
Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile ‘Access-Control-Allow-Headers’ aus dem CORS-Preflight-Kanal
- -

Was ist schiefgelaufen?

- -

Der Access-Control-Allow-Headers Header wird vom Server gesendet, damit der Client weiß welche Header er für {{Glossary("CORS")}} Requests unterstützt. Der Wert für Access-Control-Allow-Headers ist eine durch Komma getrennte Liste von Header-Namen, wie z.B. "X-Custom-Information" oder jeder der Standart-Header (aber kein Basic-Header, die immer erlaubt sind).

- -

Dieser Fehler tritt auf, wenn versucht wird einen Preflight auszuführen mit einem Header, der nicht ausdrücklich erlaubt ist, d.h. der nicht im Access-Control-Allow-Headers Header enthalten ist, der vom Server gesendet wird. Um dies zu beheben, muss der Server so angepasst werden, dass er den angegebenen Header zulässt, oder man vermeidet es diesen Header zu verwenden.

- -

Siehe auch

- - diff --git a/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html b/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html deleted file mode 100644 index 8ccb987535..0000000000 --- a/files/de/web/http/cors/errors/corsfehltquelleerlauben/index.html +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: >- - Grund: CORS header 'AccessGrund: CORS-Kopfzeile 'Access-Control-Allow-Origin' - fehlt -slug: Web/HTTP/CORS/Errors/CORSFehltQuelleErlauben -tags: - - CORS - - CORSMissingAllowOrigin - - Cross-Origin - - Error - - Fehler - - Gründe - - HTTP - - HTTPS - - Konsole - - Nachrichten - - Sicherheit - - troubleshooting -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin ---- -
{{HTTPSidebar}}
- -

Grund

- -
 Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt
- -

Was ist schief gelaufen?

- -

Der Antwort auf die {{Glossary("CORS")}}-Anfrage fehlt der benötigte {{HTTPHeader("Access-Control-Allow-Origin")}}-Header, welcher verwendet wird, um herauszufinden, ob die Ressource vom Inhalt, der im momentanen Origin arbeitet, verwendet werden kann oder nicht.

- -

Wenn der Server unter Ihrer Kontrolle steht, fügen Sie die Quelle der anfragenden Seite zu der Liste der Domains hinzu, die Zugriff haben, indem Sie Sie zum Header-Wert Access-Control-Allow-Origin ergänzen.

- -

Um zum Beispiel einer Seite unter https://amazing.site zu erlauben, auf die Ressource mithilfe von CORS zuzugreifen, sollte der Header lauten:

- -
Access-Control-Allow-Origin: https://amazing.site
- -

Mithilfe der "*"-Wildcard kann man eine Seite so konfigureren, dass Sie jeder anderen Webseite Zugriff gewährt. Dies sollte man ausschließlich für öffentliche APIs tun. Private APIs sollten niemals "*" verwenden, sondern stattdessen eine spezifische Domain oder eine Liste von Domains. Zudem funktioniert die Wildcard nur für Requests, die mit dem {{htmlattrxref("crossorigin")}}-Attribut, gesetzt auf "anonymous", erstellt wurden.

- -
Access-Control-Allow-Origin: *
- -
-

Warnung: Die Wildcard dazu zu benutzen, um allen Websites Zugriff auf eine private API zu geben, ist - aus wohl offensichtlichen Gründen - keine gute Idee.

-
- -

Fügen Sie z.B. in Apache eine Zeile wie die Folgende zur Konfiguration des Servers hinzu (im zugehörigen <Directory>, <Location>, <Files>, oder <VirtualHost>-Abschnitt). Die Konfigurationseinstellungen findet man üblicherweise in einer .conf-Datei (httpd.conf und apache.conf sind übliche Namen dafür), oder in einer .htaccess-Datei.

- -
Header set Access-Control-Allow-Origin 'origin-list'
- -

Für Nginx lautet der Befehl, um den Header zu setzen:

- -
add_header 'Access-Control-Allow-Origin' 'origin-list'
- -

Siehe auch

- - diff --git a/files/de/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html b/files/de/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html new file mode 100644 index 0000000000..d40ac7b5b5 --- /dev/null +++ b/files/de/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html @@ -0,0 +1,37 @@ +--- +title: >- + Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile 'Access-Control-Allow-Headers' + aus dem CORS-Preflight-Kanal +slug: Web/HTTP/CORS/Errors/CORSFehlenderAllowHeaderAusPreflight +tags: + - CORS + - CORSMissingAllowHeaderFromPreflight + - Cross-Origin + - Fehler + - HTTP + - HTTPS + - Meldungen + - Sicherheit + - Ursachen +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight +--- +
{{HTTPSidebar}}
+ +

Grund

+ +
Grund: fehlendes Token ‘xyz’ in CORS-Kopfzeile ‘Access-Control-Allow-Headers’ aus dem CORS-Preflight-Kanal
+ +

Was ist schiefgelaufen?

+ +

Der Access-Control-Allow-Headers Header wird vom Server gesendet, damit der Client weiß welche Header er für {{Glossary("CORS")}} Requests unterstützt. Der Wert für Access-Control-Allow-Headers ist eine durch Komma getrennte Liste von Header-Namen, wie z.B. "X-Custom-Information" oder jeder der Standart-Header (aber kein Basic-Header, die immer erlaubt sind).

+ +

Dieser Fehler tritt auf, wenn versucht wird einen Preflight auszuführen mit einem Header, der nicht ausdrücklich erlaubt ist, d.h. der nicht im Access-Control-Allow-Headers Header enthalten ist, der vom Server gesendet wird. Um dies zu beheben, muss der Server so angepasst werden, dass er den angegebenen Header zulässt, oder man vermeidet es diesen Header zu verwenden.

+ +

Siehe auch

+ + diff --git a/files/de/web/http/cors/errors/corsmissingalloworigin/index.html b/files/de/web/http/cors/errors/corsmissingalloworigin/index.html new file mode 100644 index 0000000000..8ccb987535 --- /dev/null +++ b/files/de/web/http/cors/errors/corsmissingalloworigin/index.html @@ -0,0 +1,59 @@ +--- +title: >- + Grund: CORS header 'AccessGrund: CORS-Kopfzeile 'Access-Control-Allow-Origin' + fehlt +slug: Web/HTTP/CORS/Errors/CORSFehltQuelleErlauben +tags: + - CORS + - CORSMissingAllowOrigin + - Cross-Origin + - Error + - Fehler + - Gründe + - HTTP + - HTTPS + - Konsole + - Nachrichten + - Sicherheit + - troubleshooting +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +--- +
{{HTTPSidebar}}
+ +

Grund

+ +
 Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt
+ +

Was ist schief gelaufen?

+ +

Der Antwort auf die {{Glossary("CORS")}}-Anfrage fehlt der benötigte {{HTTPHeader("Access-Control-Allow-Origin")}}-Header, welcher verwendet wird, um herauszufinden, ob die Ressource vom Inhalt, der im momentanen Origin arbeitet, verwendet werden kann oder nicht.

+ +

Wenn der Server unter Ihrer Kontrolle steht, fügen Sie die Quelle der anfragenden Seite zu der Liste der Domains hinzu, die Zugriff haben, indem Sie Sie zum Header-Wert Access-Control-Allow-Origin ergänzen.

+ +

Um zum Beispiel einer Seite unter https://amazing.site zu erlauben, auf die Ressource mithilfe von CORS zuzugreifen, sollte der Header lauten:

+ +
Access-Control-Allow-Origin: https://amazing.site
+ +

Mithilfe der "*"-Wildcard kann man eine Seite so konfigureren, dass Sie jeder anderen Webseite Zugriff gewährt. Dies sollte man ausschließlich für öffentliche APIs tun. Private APIs sollten niemals "*" verwenden, sondern stattdessen eine spezifische Domain oder eine Liste von Domains. Zudem funktioniert die Wildcard nur für Requests, die mit dem {{htmlattrxref("crossorigin")}}-Attribut, gesetzt auf "anonymous", erstellt wurden.

+ +
Access-Control-Allow-Origin: *
+ +
+

Warnung: Die Wildcard dazu zu benutzen, um allen Websites Zugriff auf eine private API zu geben, ist - aus wohl offensichtlichen Gründen - keine gute Idee.

+
+ +

Fügen Sie z.B. in Apache eine Zeile wie die Folgende zur Konfiguration des Servers hinzu (im zugehörigen <Directory>, <Location>, <Files>, oder <VirtualHost>-Abschnitt). Die Konfigurationseinstellungen findet man üblicherweise in einer .conf-Datei (httpd.conf und apache.conf sind übliche Namen dafür), oder in einer .htaccess-Datei.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

Für Nginx lautet der Befehl, um den Header zu setzen:

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list'
+ +

Siehe auch

+ + diff --git a/files/de/web/http/public_key_pinning/index.html b/files/de/web/http/public_key_pinning/index.html new file mode 100644 index 0000000000..337b9b600e --- /dev/null +++ b/files/de/web/http/public_key_pinning/index.html @@ -0,0 +1,147 @@ +--- +title: HTTP Public Key Pinning (HPKP) +slug: Web/Security/Public_Key_Pinning +tags: + - Anleitung + - HPKP + - HTTP + - Sicherheit + - Webentwicklung +translation_of: Web/HTTP/Public_Key_Pinning +--- +
{{HTTPSidebar}}
+ +

Die Public Key Pinning Erweiterung für HTTP ({{Glossary("HPKP")}}) ist ein Sicherheitsfeature, das einem Webclient mitteilt, einen spezifischen kryptographischen Schlüssel mit einem bestimmten Webserver in Verbindung zu bringen um {{Glossary("MITM")}} mit gefälschten Zertifikaten zu vermeiden.

+ +

Um die Echtheit des öffentlichen Schlüssels eines Servers in {{Glossary("TLS")}}-Sessions sicherzustellen, wird dieser in ein X.509-Zertifikat gepackt, welches meistens von einer Zertifizierungsstelle ({{GLossary("CA")}}) signiert wird. Webclients wie Browser vertrauen vielen Zertifizierungsstellen, die Zertifikate für beliebige Domainnamen erstellen können. Wenn ein Angreifer dazu in der Lage ist, eine einzelne Zertifizierungsstelle zu infiltrieren, kann er MITM-Angriffe auf verschiedene TLS-Verbindungen starten. HPKP kann diese Gefahr für das {{Glossary("HTTPS")}}-Protokoll dadurch umgehen, dass dem Client mitgeteilt wird, welcher öffentliche Schlüssel zu einem bestimmten Webserver gehört.

+ +

HPKP is ein Trust on First Use ({{Glossary("TOFU")}}) ("Bei der ersten Benutzung vertrauen") Verfahren. Beim ersten Webseitenbesuch übermittelt der Server einen HTTP-Header um dem Client zu zeigen, welche öffentliche Schlüssel zu ihm gehören. Der Client speichert diese Information für eine angegebene Zeit. Wenn der Client die Webseite erneut besucht, erwartet er, dass mindestens ein Zertifikat der Zertifikatkette einen öffentlichen Schlüssel enthält, dessen Fingerprint dem Client bereits per HPKP bekannt ist. Wenn der Server einen unbekannten öffentlichen Schlüssel liefert, sollte der Client einen Fehler anzeigen.

+ +

Firefox (und Chrome) deaktivieren die Pin Validierung für Pinned Hosts mit Zertifikatketten, die bei einem benutzerdefinierten trust anchor terminieren (anstatt bei einem eingebauten trust anchor). Dies bedeutet, dass alle Pinning-Nichteinhaltungen für Nutzer ignoriert werden, welche ein Root-Zertifikat importiert haben.

+ +

HPKP aktivieren

+ +

Dieses Feature kann einfach aktiviert werden indem ein {{HTTPHeader("Public-Key-Pins")}} HTTP-Header beim Aufruf der Seite über HTTPS zurückgegeben wird:

+ +
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]
+
+ +
+
pin-sha256
+
Der Parameter beinhaltet einen Base64 codierten Subject Public Key Information ({{Glossary("SPKI")}}) Fingerprint. Es ist auch möglich mehrere Pins zu verschiedenen öffentlichen Schlüsseln zu definieren. Einige Browser werden hier zukünftig neben SHA-256 evtl. weitere Hash-Algorithmen erlauben. Weiter unten ist beschrieben, wie diese Informationen entweder aus dem Zertifikat oder der Schlüsseldatei extrahiert werden können.
+
max-age
+
Die Zeit (in Sekunden) in Sekunden, die ein Browser sich merken soll, dass auf diese Seite nur bei Benutzung eines der öffentlichen Schlüssel zugegriffen werden darf.
+
includeSubdomains {{ optional_inline() }}
+
Wenn dieser optionale Parameter angegeben wird, wird die Regel auch auf alle Subdomains der Site angewandt.
+
report-uri {{ optional_inline() }}
+
Wenn dieser optionale Parameter angegeben wird, werden Pinvalidierungsfehlschläge an die angegebene URL gemeldet.
+
+ +
+

Anmerkung: Die aktuelle Spezifikation verlangt die Aufnahme eines zweiten Pins für einen Backup-Schlüssel, der noch nicht in der Produktion verwendet wird. Dies ermöglicht es, den öffentlichen Schlüssel des Servers zu ändern, ohne die Zugänglichkeit für Clients zu beeinträchtigen, die die Pins bereits bemerkt haben. Dies ist z.B. dann wichtig, wenn der alte Schlüssel beschädigt wird.

+
+ +

Base64-enkodierte Public Key Informationen extrahieren

+ +
+

Note: Während das folgende Beispiel zeigt, wie man einen Pin auf ein Serverzertifikat setzt, wird empfohlen, den Pin auf das Zwischenzertifikat der CA zu setzen, die das Serverzertifikat ausgestellt hat, um Verlängerungen und Rotationen von Zertifikaten zu erleichtern.

+
+ +

First you need to extract the public key information from your certificate or key file and encode them using Base64.

+ +

The following commands will help you extract the Base64 encoded information from a key file, a certificate signing request, or a certificate.

+ +
openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

The following command will extract the Base64 encoded information for a website.

+ +
openssl s_client -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

Beispiel für ein HPKP-Header

+ +
Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="https://www.example.net/hpkp-report"
+ +

In this example, pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=" pins the server's public key used in production. The second pin declaration pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=" also pins the backup key. max-age=5184000 tells the client to store this information for two month, which is a reasonable time limit according to the IETF RFC. This key pinning is also valid for all subdomains, which is told by the includeSubdomains declaration. Finally, report-uri="https://www.example.net/hpkp-report" explains where to report pin validation failures.

+ +

Setting up your webserver to include the HPKP header

+ +

The concrete steps necessary to deliver the HPKP header depend on the web server you use.

+ +
+

Note: These examples use a max-age of two months and include all subdomains. It is advised to verify that this setup will work for your server.

+
+ +
+

HPKP hat das Potential Nutzer für eine lange Zeit auszusperren, wenn es inkorrekt genutzt wird! Die Benutzung von Backup-Zertifikaten und/oder das Pinnen der Zertifizierungsstelle wird dringend empfohlen.

+
+ +

Apache

+ +

HPKP kann im Apache Webserver beispielsweise mit der folgenden Konfiguration aktiviert werden. Die Parameter müssen dann nur noch auf das Zielsystem angepasst werden. Das Apache Modul mod_headers wird benötigt.

+ +
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
+
+ +

Nginx

+ +

Adding the following line and inserting the appropriate pin-sha256="..." values will enable HPKP on your nginx. This requires the ngx_http_headers_module.

+ +
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';
+ +

Lighttpd

+ +

The following line with your relevant key information (pin-sha256="..." fields) will enable HPKP on lighttpd.

+ +
setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")
+ +

Note: This requires the mod_setenv server.module loaded which can be included by the following if not already loaded.

+ +
server.modules += ( "mod_setenv" )
+ +

IIS

+ +

Add the following line to the Web.config file to send the Public-Key-Pins header:

+ +
<system.webServer>
+  ...
+
+  <httpProtocol>
+    <customHeaders>
+      <add name="Public-Key-Pins" value="pin-sha256=&quot;base64+primary==&quot;; pin-sha256=&quot;base64+backup==&quot;; max-age=5184000; includeSubDomains" />
+    </customHeaders>
+  </httpProtocol>
+
+  ...
+</system.webServer>
+ +

Browserkompatibilität

+ + + +

{{Compat("http.headers.Public-Key-Pins")}}

+ +

Spezifikationen

+ + + + + + + + + + + + +
SpezifikationTitel
{{RFC("7469", "Public-Key-Pins", "2.1")}}Public Key Pinning Erweiterung für HTTP
+ +

Siehe auch

+ + -- cgit v1.2.3-54-g00ecf