Sicherheit

Der Grundsatz: nichts zu stehlen

Die wirksamste Maßnahme gegen den Diebstahl von Zugangstoken ist, keine im Browser zu haben. ProSportsOS folgt dem Backend-for-Frontend-Muster aus RFC 10017: Access-, Refresh- und ID-Token bleiben serverseitig und liegen dort mit AES-256-GCM verschlüsselt. Der Browser erhält ausschließlich ein zufälliges, bedeutungsloses Cookie mit dem Präfix __Host-.

Damit entfällt eine ganze Angriffsklasse — „Token per Cross-Site Scripting aus dem localStorage auslesen“ — nicht, weil sie abgewehrt wird, sondern weil es nichts auszulesen gibt.

Anmeldung

• Passkeys (WebAuthn). Der private Schlüssel verlässt das Gerät nie und ist an die Adresse dieser Seite gebunden. Eine nachgebaute Anmeldeseite kann ihn deshalb nicht verwenden — anders als ein Passwort.
• Authorization Code mit PKCE (S256). Pflicht für jeden Kanal, auch für die späteren Apps.
• Pushed Authorization Requests (RFC 9126). Die Parameter der Anmeldeanfrage laufen serverseitig zwischen den Diensten; sie landen nicht in Browserverlauf, Referrer oder Proxy-Protokollen.
• Aussteller-Prüfung (RFC 9207). Verhindert Mix-up-Angriffe, bei denen die Antwort eines fremden Anbieters in den eigenen Vorgang eingeschleust wird.
• Passwörter — falls genutzt — gegen Leak-Listen geprüft. Der Abgleich läuft über das k-Anonymitäts-Verfahren: Es werden nur die ersten fünf Zeichen eines Hashwerts übertragen, und der Abruf geht über unseren Server, damit Ihre IP-Adresse den Drittdienst nicht erreicht.

Sitzungen

Cookie

__Host-Präfix, HttpOnly, Secure, SameSite=Lax

Speicherung

In der Datenbank liegt nur der HMAC des Cookie-Werts — ein Datenbankleck gibt keine übernehmbaren Sitzungen preis.

Leerlauf

30 Minuten ohne Aktivität beenden die Sitzung.

Höchstdauer

8 Stunden, unabhängig von Aktivität.

Nach jeder Anmeldung

Neues Sitzungs-Handle (Schutz gegen Session Fixation).

Sensible Schritte

Verlangen eine frische Bestätigung, nicht nur eine bestehende Anmeldung.

Schutz vor fremden Ursprüngen

Jede zustandsändernde Anfrage muss zwei unabhängige Bedingungen erfüllen: eine vertrauenswürdige Herkunft (bevorzugt über Sec-Fetch-Site, ersatzweise Origin oder Referer) und ein sitzungsgebundenes CSRF-Token im Header. Der sonst übliche Kurzschluss „kein Herkunftsheader, also vertrauen wir“ ist bewusst nicht vorhanden — unklare Fälle werden abgelehnt.

Die Seite lädt ausschließlich eigene Ressourcen. Die Content-Security-Policy erlaubt Skripte nur mit einer pro Anfrage neu erzeugten Nonce; es gibt keine Host-Erlaubnisliste, die man umgehen könnte.

Native Apps

Die kommenden Apps erhalten sender-gebundene Zugangstoken nach RFC 9449 (DPoP). Die App erzeugt beim ersten Start ein Schlüsselpaar in Secure Enclave (iOS) beziehungsweise StrongBox (Android) und beweist bei jeder Anfrage den Besitz des privaten Schlüssels. Ein kopiertes Token allein ist damit wertlos.

Die Anmeldung läuft im System-Browser (ASWebAuthenticationSession beziehungsweise Custom Tabs), niemals in einem eingebetteten WebView — nur so sieht die App die Zugangsdaten nicht, und nur so funktionieren Passkeys überhaupt.

Besondere Kategorien personenbezogener Daten

Verletzungshistorien, ärztliche Befunde und Belastungswerte sind Gesundheitsdaten im Sinne von Artikel 9 DSGVO. Für sie gilt ein grundsätzliches Verarbeitungsverbot mit engen Ausnahmen — eine Einwilligung oder eine Regelung im Arbeits- beziehungsweise Spielervertrag reicht nicht automatisch aus.

Was die Plattform dafür mitbringt: nachvollziehbare Zugriffsprotokolle, Auskunft und Löschung als Funktion statt als Vorgang, Betrieb ohne Drittanbieter und eine Anmeldung, die geteilte Konten praktisch ausschließt. Was sie nicht ersetzt: die fachliche Festlegung, wer im Verein welche Befunde sehen darf, und deren Niederschlag im Verarbeitungsverzeichnis. Das ist je Organisation zu klären.

Protokollierung und Datensparsamkeit

• Statt der vollständigen IP-Adresse wird ein gekürztes Netzpräfix gespeichert (IPv4 auf /24, IPv6 auf /48) — und auch das nur als HMAC.
• Statt des vollständigen Browser-Kennstrings nur eine grobe Angabe wie „Firefox / Windows“.
• Sicherheitsereignisse werden 90 Tage aufbewahrt und sind im Konto einsehbar.
• Es gibt keinen Analysedienst, kein Werbenetzwerk und keine externe Schriftquelle.

Was dieses Konzept nicht abdeckt

Schwachstellen melden

Meldungen sind ausdrücklich willkommen und werden nicht verfolgt, solange sie sich an die Hinweise in security.txt halten. Kontakt: security@prosportsos.com.