Zum Hauptinhalt springen
Deutsch
|
English

XPERMITTEDCROSSDOMAINPOLICIES - Detailbeschreibung

Administration

Administration

Überblick

Parameter: XPERMITTEDCROSSDOMAINPOLICIES
Kategorie: Custom
Standardwert: none
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Der Parameter steuert den HTTP-Antwort-Header X-Permitted-Cross-Domain-Policies, der bestimmt, welche Cross-Domain-Richtliniendateien (crossdomain.xml) auf dem Server erlaubt sind. Diese Richtliniendateien wurden früher von Adobe Flash und Adobe Reader verwendet, um zu entscheiden, ob Inhalte von anderen Domains geladen werden dürfen. Der Header schützt vor unerwünschtem Einbetten der Websiteinhalte in PDF-Dokumente und Flash-Anwendungen auf anderen Websites.

Wofür wird dieser Parameter verwendet?

  • Schutz vor unerwünschter Cross-Domain-Kommunikation durch Flash und PDF

  • Kontrolle über Cross-Domain-Richtliniendateien auf dem Server

  • Verhinderung, dass externe Anwendungen unautorisiert auf Portal-Inhalte zugreifen

  • Erfüllung von Sicherheitsstandards für Web-Anwendungen

  • Reduzierung der Angriffsfläche durch Einschränkung von Cross-Domain-Policies

  • Schutz vor Legacy-Technologie-Risiken

Technische Details (für Administratoren)

Format: Text (String)
Standardwert: none

Gültige Werte:

  • none = Keine Richtliniendateien sind auf dem Zielserver erlaubt, auch nicht die Master-Richtliniendatei (höchste Sicherheit, empfohlen)

  • master-only = Nur die Hauptrichtliniendatei crossdomain.xml im Root-Verzeichnis ist erlaubt

  • by-content-type = Nur Richtliniendateien mit Content-Type: text/x-cross-domain-policy sind erlaubt (nur HTTP/HTTPS)

  • by-ftp-filename = Nur Richtliniendateien mit dem Namen crossdomain.xml sind erlaubt (nur FTP)

  • all = Alle Richtliniendateien auf dieser Zieldomäne sind erlaubt (niedrigste Sicherheit)

Wichtige Hinweise:

  • Der Header wird bei jeder HTTP-Antwort des Portals gesendet

  • Änderungen werden sofort wirksam, kein Portal-Neustart erforderlich

  • Falls der Parameter leer ist, wird der Header nicht hinzugefügt

  • Der Parameter wirkt sich auf alle Seiten und Benutzer des Portals aus

  • Adobe Flash ist seit 2020 End-of-Life, der Header bleibt aber aus Sicherheitsgründen relevant

  • PDF-Reader können weiterhin Cross-Domain-Policies verwenden

Technische Implementierung:

Wenn der Parameter einen Wert enthält, wird dieser im HTTP-Header gesendet:

X-Permitted-Cross-Domain-Policies: none

Zusammenspiel mit anderen Parametern:

Hintergrund zu Cross-Domain-Policies:

Cross-Domain-Policy-Dateien (crossdomain.xml) wurden von Adobe eingeführt, um Flash-Anwendungen und PDF-Dokumenten Cross-Domain-Zugriffe zu ermöglichen. Der X-Permitted-Cross-Domain-Policies-Header gibt an, ob und welche solcher Richtliniendateien auf dem Server vorhanden sein dürfen.

Wann sollten Sie diesen Wert ändern?

Wert auf "none" belassen (Standard), wenn:

  • Keine Cross-Domain-Policy-Dateien auf dem Server verwendet werden

  • Maximale Sicherheit gewünscht ist

  • Keine Legacy-Flash- oder PDF-Anwendungen integriert sind

  • Moderne Web-Standards verwendet werden

  • Keine spezifischen Anforderungen für Cross-Domain-Policies vorliegen

Wert auf "master-only" ändern, wenn:

  • Eine crossdomain.xml-Datei im Root-Verzeichnis des Servers vorhanden ist

  • Kontrollierte Cross-Domain-Zugriffe für bestimmte Legacy-Anwendungen erforderlich sind

  • Die Richtliniendatei zentral verwaltet wird

Wert auf "by-content-type" ändern, wenn:

  • Cross-Domain-Policies dynamisch mit dem korrekten Content-Type bereitgestellt werden

  • Zusätzliche Sicherheit durch Content-Type-Prüfung gewünscht ist

Wert NICHT ändern, wenn:

  • Sie nicht genau verstehen, welche Auswirkungen dies hat

  • Keine Legacy-Anwendungen Cross-Domain-Zugriffe benötigen

  • Das Portal keine Cross-Domain-Policy-Dateien verwendet

Wichtige Hinweise

  1. Standard ist sicherste Option
    Der Wert "none" ist die restriktivste und sicherste Einstellung. Änderungen sollten nur erfolgen, wenn konkrete technische Anforderungen vorliegen.

  2. Flash ist End-of-Life
    Adobe Flash wurde Ende 2020 eingestellt. Der Header bleibt dennoch relevant für PDF-Reader und aus Sicherheitsgründen als Best Practice.

  3. Leerer Wert deaktiviert Header
    Wenn der Parameter leer ist, wird der X-Permitted-Cross-Domain-Policies-Header nicht gesendet. Dies ist nicht empfohlen, da der Header eine zusätzliche Sicherheitsebene darstellt.

  4. Cross-Domain-Policy-Dateien nicht benötigt
    Das eTASK FM-Portal verwendet keine Cross-Domain-Policy-Dateien (crossdomain.xml). Der Standard-Wert "none" ist daher korrekt.

  5. Browser ignorieren diesen Header
    Moderne Webbrowser nutzen andere Mechanismen (CORS) für Cross-Domain-Zugriffe. Der Header ist spezifisch für Flash und PDF-Reader.

  6. Sicherheitsaudit-Anforderung
    Viele Sicherheitsaudits und Scanning-Tools prüfen auf das Vorhandensein dieses Headers. Der Standard-Wert "none" erfüllt diese Anforderungen.

  7. Kombination mit anderen Sicherheitsheadern
    Für umfassenden Schutz sollten mehrere Sicherheitsheader konfiguriert werden: X-Frame-Options, Content-Security-Policy, X-Content-Type-Options und X-Permitted-Cross-Domain-Policies.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter hat direkte Auswirkungen auf die Sicherheit der Anwendung.

Sicherheitsrisiken bei falscher Konfiguration:

Wert auf "all" setzen:

  • Alle Cross-Domain-Policy-Dateien auf dem Server werden erlaubt

  • Ermöglicht potentiell unautorisierten Cross-Domain-Zugriff

  • Erhöhtes Risiko für Cross-Site-Scripting über Flash/PDF

  • Niedrigste Sicherheitsstufe

Wert leer lassen:

  • Header wird nicht gesendet

  • Client-Anwendungen verwenden Standard-Verhalten

  • Keine explizite Sicherheitsrichtlinie

Wert auf "none" setzen (Standard):

  • Höchste Sicherheit

  • Keine Cross-Domain-Policy-Dateien erlaubt

  • Minimale Angriffsfläche

Best Practice für Sicherheit:

  1. Standard beibehalten - XPERMITTEDCROSSDOMAINPOLICIES = "none"

  2. Header immer senden - Parameter nicht leer lassen

  3. Keine Policy-Dateien bereitstellen - Keine crossdomain.xml-Dateien auf dem Server

  4. Regelmäßig prüfen - Sicherstellen, dass keine unbefugten Policy-Dateien erstellt wurden

  5. Kombination mit anderen Headern - Mehrschichtiger Sicherheitsansatz

Compliance-Aspekte:

Der X-Permitted-Cross-Domain-Policies-Header ist relevant für:

  • OWASP Sicherheitsstandards

  • Penetrationstests und Sicherheitsaudits

  • IT-Sicherheitsrichtlinien (BSI, ISO 27001)

  • Best Practices für Web-Anwendungssicherheit

Praktisches Beispiel

Ausgangssituation:

Ein Facility-Management-Unternehmen mit 700 Mitarbeitern betreibt eTASK FM seit 4 Jahren erfolgreich. Die IT-Abteilung führt ein externes Sicherheitsaudit durch, das von einem Kunden im Rahmen eines Großauftrags gefordert wird.

Der Sicherheitsauditor scannt die HTTP-Header des Portals:

X-Frame-Options: sameorigin
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
Content-Security-Policy: ...

Audit-Bewertung:

Der Auditor prüft den X-Permitted-Cross-Domain-Policies-Header:

"Der Header ist korrekt konfiguriert. Der Wert 'none' verhindert, dass Cross-Domain-Policy-Dateien verwendet werden können. Dies schützt vor potentiellen Cross-Domain-Angriffen über Legacy-Technologien wie Flash oder PDF-Reader. Best Practice eingehalten."

Prüfung:

Der Auditor versucht, eine crossdomain.xml-Datei vom Server abzurufen:

GET https://etask.firma.de/crossdomain.xml
Ergebnis: 404 Not Found

Keine Policy-Datei vorhanden. Der Header "none" ist konsistent mit der Server-Konfiguration.

Audit-Ergebnis:

Der Parameter XPERMITTEDCROSSDOMAINPOLICIES bleibt unverändert bei "none". Das Unternehmen erhält die Sicherheitszertifizierung und kann den Großauftrag annehmen.

Alternative Szenarien:

Szenario A - Legacy-Integration:
Ein anderes Unternehmen betreibt eine alte Flash-basierte Reporting-Anwendung, die auf Portal-Daten zugreifen muss. In diesem speziellen Fall wurde der Wert auf "master-only" gesetzt und eine kontrollierte crossdomain.xml-Datei im Root-Verzeichnis bereitgestellt. Nach Migration der Flash-Anwendung auf eine moderne Web-Technologie wurde der Parameter wieder auf "none" zurückgesetzt.

Szenario B - Sicherheitsaudit-Anforderung:
Ein Unternehmen hatte den Parameter nicht konfiguriert (leer). Bei einem Penetrationstest wurde bemängelt, dass der X-Permitted-Cross-Domain-Policies-Header fehlt. Nach Setzen auf "none" wurde die Anforderung erfüllt und das Sicherheitszertifikat erteilt.

Empfohlene Einstellung

Für Standard-Installationen: none (Standard beibehalten)

Begründung:

  • Höchste Sicherheit durch Verbot aller Cross-Domain-Policy-Dateien

  • Keine Legacy-Technologien im Portal vorhanden

  • Erfüllt moderne Sicherheitsstandards

  • Wird von Sicherheitsaudits positiv bewertet

  • Keine funktionalen Einschränkungen für das Portal

Niemals empfohlen:

  • all - Erlaubt alle Policy-Dateien (Sicherheitsrisiko)

  • Leerer Wert - Header wird nicht gesendet

Best Practices:

  1. Standard beibehalten - "none" ist für die meisten Szenarien optimal

  2. Header immer senden - Parameter nicht leer lassen

  3. Regelmäßig prüfen - Sicherstellen, dass keine crossdomain.xml-Dateien auf dem Server vorhanden sind

  4. Dokumentieren - Bei Abweichungen vom Standard Gründe festhalten

  5. Migration planen - Legacy-Technologien durch moderne Alternativen ersetzen

  6. Kombination mit anderen Headern - Mehrschichtiger Sicherheitsansatz

  7. Sicherheitsaudits nutzen - Regelmäßige Überprüfung der Header-Konfiguration

War dieser Artikel hilfreich?