Zum Hauptinhalt springen
Deutsch
|
English

SECURECOOKIESETTING - Detailbeschreibung

Administration

Administration

Überblick

Parameter: SECURECOOKIESETTING
Kategorie: Custom
Standardwert: 1 (aktiviert)
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Der Parameter legt fest, ob alle vom Portal gesetzten Cookies mit dem Secure-Flag versehen werden. Cookies mit diesem Flag werden vom Browser nur über verschlüsselte HTTPS-Verbindungen übertragen und nie über unverschlüsselte HTTP-Verbindungen. Das Secure-Flag wird nur gesetzt, wenn das Portal über HTTPS läuft und dieser Parameter auf 1 steht.

Wofür wird dieser Parameter verwendet?

  • Schutz von Session-Cookies und anderen sensiblen Informationen vor Abfangen über unverschlüsselte Verbindungen

  • Verhinderung von Cookie-Diebstahl bei Man-in-the-Middle-Angriffen

  • Erfüllung von Sicherheitsstandards und Compliance-Anforderungen

  • Schutz der Benutzer-Authentifizierung vor unbefugtem Zugriff

  • Einhaltung von Best Practices für sichere Webanwendungen

  • Gewährleistung, dass Cookies nur über sichere Kanäle übertragen werden

Technische Details (für Administratoren)

Format: Ganzzahl (Integer)
Standardwert: 1

Gültige Werte:

  • 1 = Secure-Flag wird gesetzt (alle Cookies nur über HTTPS, empfohlen)

  • 0 = Secure-Flag wird nicht gesetzt (Cookies auch über HTTP übertragbar)

Wichtige Hinweise:

  • Das Secure-Flag wird nur gesetzt, wenn BEIDE Bedingungen erfüllt sind:

    1. Das Portal läuft über HTTPS (USESSL = 1)

    2. SECURECOOKIESETTING ist auf 1 gesetzt

  • Wenn das Portal über HTTP läuft, wird das Secure-Flag nie gesetzt (unabhängig von diesem Parameter)

  • Betrifft alle vom Portal gesetzten Cookies (Session, Authentication, etc.)

  • Der Parameter wirkt sich auf alle Benutzer des Portals aus

Zusammenspiel mit anderen Parametern:

Wann sollten Sie diesen Wert ändern?

Wert auf 1 belassen (Standard), wenn:

  • Das Portal über HTTPS läuft (Standardfall für Produktivumgebungen)

  • Sicherheitsstandards eingehalten werden sollen

  • Keine spezifischen Gründe für eine Änderung vorliegen

  • Session-Cookies vor Abfangen geschützt werden sollen

Wert auf 0 ändern, wenn:

  • Das Portal temporär über HTTP betrieben werden muss (nur Entwicklungs-/Testumgebungen)

  • Entwickler lokal ohne SSL-Zertifikat arbeiten

  • Migration von HTTP zu HTTPS durchgeführt wird und eine Übergangsphase benötigt wird

Wichtig: In Produktivumgebungen sollte dieser Wert IMMER auf 1 stehen und das Portal über HTTPS laufen.

Wert NICHT auf 0 ändern, wenn:

  • Das Portal produktiv über HTTPS läuft

  • Echte Benutzerdaten verarbeitet werden

  • Compliance-Anforderungen bestehen

  • Keine technische Notwendigkeit für HTTP vorliegt

Wichtige Hinweise

  1. HTTPS ist Voraussetzung
    Das Secure-Flag wird nur gesetzt, wenn das Portal über HTTPS läuft. Auch wenn dieser Parameter auf 1 steht, werden Cookies ohne HTTPS nicht als "Secure" markiert.

  2. Standard nicht ohne Grund ändern
    Der Standardwert 1 ist für Produktivumgebungen obligatorisch. Änderungen auf 0 sollten nur in kontrollierten Entwicklungs- oder Testumgebungen erfolgen.

  3. Sicherheitsrisiko bei Wert 0
    Wenn dieser Parameter auf 0 gesetzt wird, können Cookies auch über unverschlüsselte HTTP-Verbindungen übertragen werden. Dies ermöglicht potentiell das Abfangen von Session-Cookies durch Angreifer.

  4. Bestehende Cookies bleiben unverändert
    Bereits im Browser gespeicherte Cookies werden nicht rückwirkend geändert. Die neue Einstellung gilt nur für neu gesetzte Cookies.

  5. Kombination mit SameSite
    Für maximale Sicherheit sollten Cookies sowohl das Secure-Flag als auch ein geeignetes SameSite-Attribut haben. Dies wird über den Parameter SAMESITECOOKIESETTING gesteuert.

  6. Browser-Verhalten
    Moderne Browser erzwingen zunehmend das Secure-Flag für Cookies, die von HTTPS-Seiten gesetzt werden. Der Standard-Wert 1 entspricht diesem Trend.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

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

Sicherheitsrisiken bei falscher Konfiguration:

Wert auf 0 setzen in Produktivumgebung:

  • Cookies können über unverschlüsselte HTTP-Verbindungen abgefangen werden

  • Session-Hijacking wird ermöglicht (Angreifer können Sessions übernehmen)

  • Authentifizierungs-Cookies sind anfällig für Man-in-the-Middle-Angriffe

  • Benutzerkonten können kompromittiert werden

  • DSGVO-Compliance ist gefährdet

  • Verstoß gegen Sicherheits-Best-Practices

Wert auf 1 setzen ohne HTTPS:

  • Keine negativen Auswirkungen, aber auch kein Sicherheitsgewinn

  • Das Secure-Flag wird nicht gesetzt, da HTTPS nicht aktiv ist

  • Portal funktioniert weiterhin, ist aber nicht optimal abgesichert

Best Practice für Sicherheit:

  1. Standard beibehalten - SECURECOOKIESETTING = 1

  2. HTTPS verwenden - Portal muss über HTTPS erreichbar sein

  3. Regelmäßig prüfen - Sicherstellen, dass Cookies tatsächlich das Secure-Flag haben

  4. Entwicklung vs. Produktion trennen - Nur in Entwicklungsumgebungen Wert 0 verwenden

  5. Monitoring - Überwachen, ob unverschlüsselte HTTP-Zugriffe versucht werden

Compliance-Aspekte:

Das Secure-Flag für Cookies ist relevant für:

  • DSGVO (Datenschutz-Grundverordnung)

  • Technische und organisatorische Maßnahmen (TOM)

  • IT-Sicherheitsstandards (BSI, ISO 27001)

  • Payment Card Industry Data Security Standard (PCI DSS)

Praktisches Beispiel

Ausgangssituation:

Ein Facility-Management-Unternehmen mit 600 Mitarbeitern betreibt eTASK FM seit 3 Jahren erfolgreich über HTTPS. Die IT-Abteilung führt ein routinemäßiges Sicherheits-Audit durch und überprüft die Cookie-Konfiguration.

Der IT-Administrator öffnet die Browser-Entwicklertools und prüft die gesetzten Cookies:

ASP.NET_SessionId: Secure ✓, HttpOnly ✓, SameSite=Lax
.ASPXAUTH: Secure ✓, HttpOnly ✓, SameSite=Lax

Alle Cookies haben das Secure-Flag gesetzt. Der Parameter SECURECOOKIESETTING steht auf dem Standardwert 1.

Audit-Ergebnis:

"Die Cookie-Konfiguration entspricht den aktuellen Sicherheitsstandards. Das Secure-Flag schützt vor Cookie-Diebstahl über unverschlüsselte Verbindungen. Keine Änderungen erforderlich."

Neues Entwicklungsprojekt:

Einige Wochen später richtet die IT-Abteilung eine neue Entwicklungsumgebung auf einem lokalen Server ohne SSL-Zertifikat ein. Entwickler können sich nicht anmelden, da die Browser die Cookies blockieren.

Problem:

Die Entwicklungsumgebung läuft über HTTP (http://dev-server/), aber SECURECOOKIESETTING ist auf 1. Cookies ohne HTTPS und mit Secure-Flag werden von modernen Browsern teilweise blockiert.

Analyse:

Der Administrator prüft die Konfiguration:

  • Portal läuft über HTTP

  • SECURECOOKIESETTING = 1

  • Cookies werden gesetzt, aber teilweise vom Browser blockiert

Lösung für Entwicklungsumgebung:

Der Administrator ändert in der Entwicklungsumgebung SECURECOOKIESETTING auf 0:

  • Cookies werden ohne Secure-Flag gesetzt

  • Entwickler können sich anmelden

  • Entwicklung kann fortgesetzt werden

Wichtiger Hinweis:

Diese Änderung wird NUR in der Entwicklungsumgebung vorgenommen. Die Produktivumgebung behält den Wert 1 bei.

Dokumentation:

Der Administrator dokumentiert die Änderung:

  • Parameter: SECURECOOKIESETTING = 0

  • Umgebung: Nur Entwicklung (dev-server)

  • Grund: Kein SSL-Zertifikat auf Entwicklungsserver

  • Produktivumgebung: Unverändert (Wert 1)

Ergebnis:

  • Entwicklung funktioniert reibungslos auf lokalem Server

  • Produktivumgebung bleibt optimal abgesichert

  • Klare Trennung zwischen Entwicklung und Produktion

  • Keine Sicherheitsrisiken für echte Benutzerdaten

Alternative Lösung:

Ein anderes Unternehmen verwendet auch in der Entwicklungsumgebung HTTPS mit selbst-signierten Zertifikaten:

  • SECURECOOKIESETTING bleibt auf 1 (auch in Entwicklung)

  • Entwickler akzeptieren einmalig das selbst-signierte Zertifikat im Browser

  • Identische Konfiguration in Entwicklung und Produktion

  • Vermeidung von konfigurationsbedingten Unterschieden

Dieser Ansatz erfordert mehr Aufwand bei der Einrichtung, vermeidet aber Konfigurationsunterschiede zwischen Umgebungen.

Empfohlene Einstellung

Für Produktivumgebungen: 1 (Standard beibehalten)

Begründung:

  • Cookies werden nur über verschlüsselte HTTPS-Verbindungen übertragen

  • Schutz vor Cookie-Diebstahl und Session-Hijacking

  • Erfüllung von Sicherheitsstandards und Compliance-Anforderungen

  • Etablierte Best Practice für sichere Webanwendungen

  • Voraussetzung für sichere Benutzer-Authentifizierung

Niemals in Produktion:

  • Wert 0 in Produktivumgebung (kritisches Sicherheitsrisiko)

  • Produktivumgebung ohne HTTPS betreiben

Best Practices:

  1. Standard beibehalten - SECURECOOKIESETTING = 1 in Produktion

  2. HTTPS verwenden - Portal über verschlüsselte Verbindung betreiben

  3. Regelmäßig prüfen - Cookie-Konfiguration in Browser-Tools überprüfen

  4. Dokumentieren - Abweichungen vom Standard begründen und festhalten

  5. Testen - Nach Änderungen Login und Session-Verwaltung testen

  6. Monitoring - Überwachen, dass alle Cookies korrekt konfiguriert sind

War dieser Artikel hilfreich?