ANTICROSSSITEREQUESTFORGERY - Detailbeschreibung

Open

Überblick

Parameter:ANTICROSSSITEREQUESTFORGERY
Kategorie: Custom (Benutzerdefiniert)
Standardwert: 0 (deaktiviert)
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Dieser Parameter aktiviert einen Sicherheitsmechanismus zum Schutz vor Cross-Site Request Forgery (CSRF)-Angriffen. CSRF ist eine Angriffsmethode, bei der ein Angreifer versucht, ungewollte Aktionen im Namen eines angemeldeten Benutzers auszuführen. Wenn aktiviert, überprüft das Portal bei jeder Anfrage einen speziellen Sicherheitstoken, um sicherzustellen, dass die Anfrage tatsächlich vom Benutzer stammt und nicht von einer fremden Website eingeleitet wurde.

Wofür wird dieser Parameter verwendet?

• Schutz vor Cross-Site Request Forgery (CSRF)-Angriffen auf das Portal

• Validierung der Herkunft von Benutzeranfragen durch Token-Prüfung

• Erhöhung der Sicherheit bei sensiblen Aktionen wie Datenänderungen

• Verhinderung unberechtigter Aktionen durch manipulierte externe Links

• Erfüllung von Sicherheitsanforderungen und Compliance-Vorgaben

Technische Details (für Administratoren)

Format: Numerischer Wert (0 oder 1)
Standardwert: 0 (deaktiviert)

Gültige Werte:

• 0 = Anti-CSRF-Schutz ist DEAKTIVIERT (Standard)

• 1 = Anti-CSRF-Schutz ist AKTIVIERT

Wichtige Hinweise:

• Bei Aktivierung wird bei jeder Anfrage ein Anti-Forgery-Token validiert

• Das System prüft den Referer-Header, um sicherzustellen, dass Anfragen von der gleichen Domain kommen

• Bei aktiviertem Schutz werden automatisch JavaScript-Bibliotheken eingebunden, die Tokens verwalten

• Der Parameter arbeitet mit dem ALLOWEDREFERERS-Parameter zusammen, um externe Login-Dienste (z.B. Microsoft Azure) zu erlauben

• Anfragen ohne gültigen Token werden blockiert und im Log protokolliert

Zusammenspiel mit anderen Parametern:

Der Parameter benötigt ALLOWEDREFERERS, wenn externe Authentifizierungsdienste (z.B. Azure Active Directory) verwendet werden. In ALLOWEDREFERERS werden vertrauenswürdige Domains eingetragen, von denen Weiterleitungen erlaubt sind.

Wann sollten Sie diesen Wert ändern?

Wert auf 1 setzen (CSRF-Schutz aktivieren), wenn:

• Sie erhöhte Sicherheitsanforderungen für Ihr Portal haben

• Compliance-Vorgaben oder Sicherheitsrichtlinien dies erfordern

• Ihr Portal über das Internet öffentlich erreichbar ist

• Sie sensible Daten verwalten, die besonders geschützt werden müssen

• Sicherheitsaudits die Aktivierung von CSRF-Schutz empfehlen

Wert auf 0 belassen (CSRF-Schutz deaktiviert), wenn:

• Das Portal nur im internen Netzwerk ohne Internetzugang betrieben wird

• Sie Kompatibilitätsprobleme mit bestimmten Integrationen vermeiden möchten

• Noch keine vollständige Konfiguration der erlaubten Referer erfolgt ist

• In der Testphase Probleme mit der Token-Validierung auftreten

Wichtige Hinweise

1. Konfiguration von ALLOWEDREFERERS erforderlich
   Wenn Sie externe Authentifizierungsdienste wie Azure Active Directory verwenden, müssen Sie die entsprechenden Domains im Parameter ALLOWEDREFERERS eintragen (z.B. https://login.microsoftonline.com). Andernfalls werden Rücksprünge vom Login-Dienst blockiert.

2. Auswirkung auf bestehende Integrationen
   Die Aktivierung kann Auswirkungen auf bestehende Schnittstellen und externe Anwendungen haben, die auf das Portal zugreifen. Testen Sie die Aktivierung zunächst in einer Testumgebung.

3. Logging bei blockierten Anfragen
   Blockierte Anfragen werden im Applikationsprotokoll erfasst. Überwachen Sie nach der Aktivierung das Log, um legitime Anfragen zu identifizieren, die möglicherweise durch fehlende Referer-Einträge blockiert werden.

4. Keine nachträgliche Deaktivierung empfohlen
   Wenn Sie den Schutz einmal aktiviert haben, sollten Sie ihn aus Sicherheitsgründen nicht wieder deaktivieren, es sei denn, es treten gravierende technische Probleme auf.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, die Aktivierung dieses Parameters hat direkte und wichtige Sicherheitsauswirkungen. Der Parameter implementiert einen wesentlichen Schutzmechanismus gegen eine häufige Angriffsart.

Positive Aspekte:

• Effektiver Schutz vor Cross-Site Request Forgery (CSRF)-Angriffen

• Verhindert ungewollte Aktionen durch manipulierte externe Links

• Blockiert unbefugte Zugriffe von fremden Websites

• Erfüllt moderne Sicherheitsstandards für Webanwendungen

• Schützt Benutzer vor unbemerkten, schädlichen Aktionen

Zu beachten:

• Bei fehlerhafter Konfiguration können legitime Anfragen blockiert werden

• Externe Integrationen müssen in ALLOWEDREFERERS konfiguriert werden

• Erhöhter Implementierungsaufwand bei der Ersteinrichtung

Datenschutzrechtliche Bewertung: - Erhöhter Schutz personenbezogener Daten durch Verhinderung unbefugter Änderungen - Reduziertes Risiko von Datenschutzverletzungen durch CSRF-Angriffe

Empfehlung: Aktivieren Sie diesen Schutz unbedingt für produktive Systeme, insbesondere wenn das Portal über das Internet erreichbar ist. Konfigurieren Sie ALLOWEDREFERERS korrekt für alle verwendeten externen Dienste und überwachen Sie nach der Aktivierung das Log auf blockierte legitime Anfragen.

Praktisches Beispiel

Ausgangssituation: Ihr eTASK.FM-Portal ist über das Internet erreichbar und verwendet Azure Active Directory zur Anmeldung. Sie möchten das Portal vor CSRF-Angriffen schützen, bei denen ein Angreifer versucht, über eine präparierte E-Mail oder Website Aktionen im Namen angemeldeter Benutzer auszuführen.

Konfiguration: ANTICROSSSITEREQUESTFORGERY = 1 (aktiviert)
ALLOWEDREFERERS = https://login.microsoftonline.com

Nach der Änderung:

• Bei jedem Seitenaufruf wird automatisch ein Anti-Forgery-Token generiert

• Das Portal prüft bei jeder Anfrage, ob ein gültiger Token vorhanden ist

• Anfragen von fremden Websites werden erkannt und blockiert

• Rücksprünge vom Azure-Login werden erlaubt, da die Domain in ALLOWEDREFERERS eingetragen ist

• Blockierte Angriffsversuche werden im Log protokolliert

Ergebnis: Ein Angreifer kann nicht mehr durch manipulierte Links oder E-Mails Aktionen im Portal auslösen. Selbst wenn ein Benutzer auf einen schädlichen Link klickt, wird die Anfrage blockiert, da sie keinen gültigen Anti-Forgery-Token enthält. Legitime Anfragen vom Azure-Login funktionieren weiterhin einwandfrei.

Alternative Szenarien:

Szenario A - Internes Portal ohne externe Authentifizierung:

• ANTICROSSSITEREQUESTFORGERY = 0 (deaktiviert)

• Portal nur im Intranet erreichbar

• Geringeres Risiko, einfachere Konfiguration

Szenario B - Portal mit mehreren externen Diensten:

• ANTICROSSSITEREQUESTFORGERY = 1 (aktiviert)

• ALLOWEDREFERERS = https://login.microsoftonline.com,https://login.partner.com

• Mehrere vertrauenswürdige Domains für verschiedene Integrationen

Empfohlene Einstellung

Für Standard-Installationen:1(aktiviert)

Begründung:

• CSRF-Angriffe gehören zu den häufigsten Bedrohungen für Webanwendungen

• Moderne Sicherheitsstandards fordern den Schutz vor CSRF

• Der Schutzmechanismus ist ausgereift und bewährt

• Minimaler Performance-Overhead bei deutlichem Sicherheitsgewinn

Ausnahmen (Deaktivierung mit Wert 0):

• Rein interne Portale ohne Internetzugang in stark abgesicherten Netzwerken

• Testumgebungen während der Entwicklungsphase

• Temporäre Deaktivierung zur Fehleranalyse bei technischen Problemen

• Legacy-Integrationen, die nicht mit Token-Validierung kompatibel sind

IC2863