nausika

sicherheit

Sicherheit.

Letzte Aktualisierung

Nausika nimmt Sicherheit ernst. Diese Seite ist der zentrale Ort für Sicherheitsforscher, KI-Client-Entwickler und verbundene Nutzer, um zu verstehen, wie man eine Schwachstelle meldet, welche Antwort zu erwarten ist und was im oder außerhalb des Scopes liegt. Der maschinenlesbare Kontakt liegt auf /.well-known/security.txt.

Eine Schwachstelle melden

Schreibe an [email protected] mit so viel Detail wie möglich: betroffener Endpoint oder Tool, ein Reproduktionsrezept, der beobachtete Impact und ob du glaubst, dass die Lücke in freier Wildbahn ausnutzbar ist. Wir bestätigen jeden Bericht innerhalb von 2 Werktagen.

Wir bieten derzeit keine PGP-Verschlüsselung an. Schick die Mail im Klartext und wir melden uns, um einen sicheren Kanal zu koordinieren, falls der Bericht Material enthält, das beim Transport nicht offen liegen sollte. Wir betreiben kein bezahltes Bug Bounty.

Bitte teste keine Schwachstellen auf eine Weise, die den Service für andere Nutzer beeinträchtigt (Denial of Service, automatisiertes Scanning mit hoher Anfragerate, Versuche, auf Daten anderer Nutzer zuzugreifen). Wenn du beim normalen Benutzen von Nausika ein Problem entdeckst, ist das in Ordnung — meld es einfach.

Patch-Response-SLA

Die Schwere wird vom Maintainer im Dialog mit dem Reporter bewertet, nach branchenüblichen Triage-Kriterien (CVSS-ähnliches Reasoning, fokussiert auf den realen Impact für das Datenmodell und die Angriffsfläche von Nausika).

  • Kritisch — Remote Code Execution, Authentifizierungs-Bypass am MCP-Endpoint, cross-tenant Datenexfiltration, Übernahme eines bestehenden Nutzerkontos: Patch innerhalb von 7 Tagen; Hotfix-Deploy auf mcp.nausika.app am selben Tag, wo möglich.
  • Hoch — Privilege Escalation (z. B. Nutzer → Admin), Leck sensibler Daten (OAuth-Token, Session-Cookies), persistente Injection (stored XSS im Admin-UI): Patch innerhalb von 14 Tagen.
  • Mittel — Denial of Service durch einen einzelnen Tool-Aufruf, Offenlegung nicht-personenbezogener Daten, reflected Injection: Patch innerhalb von 30 Tagen.
  • Niedrig — Abweichungen von Best Practices ohne nachweisbaren Exploit, Hardening, theoretische Probleme: in einem regulären Release adressiert, in der Regel innerhalb von 90 Tagen.

Koordinierte Offenlegung

Wir bevorzugen koordinierte Offenlegung. Sobald eine Schwachstelle bestätigt ist, bitten wir Reporter, die öffentliche Veröffentlichung mindestens 30 Tage ab Bestätigung zurückzuhalten (oder bis der Patch ausgerollt ist, je nachdem, was zuerst eintritt), damit verbundene Nutzer nicht vor der Verfügbarkeit eines Fixes der Ausnutzung in freier Wildbahn ausgesetzt sind.

Wir nennen den Reporter bei der Offenlegung auf /log, sofern der Reporter nichts anderes wünscht. Anonyme Berichte sind willkommen und wir behandeln sie mit derselben Triage-Disziplin wie benannte.

Unterstützte Versionen

Nausika wird aus einem einzigen öffentlichen Endpoint auf mcp.nausika.app bedient, deployt aus dem aktuellsten Main-Branch-Build. Es wird nur die aktuell deployte Version unterstützt; es gibt keine parallelen Wartungs-Branches und keine On-Premise-Distribution. Wenn ein Patch erscheint, erscheint er gleichzeitig für alle.

Self-hosted Forks oder inoffizielle Deployments sind außerhalb des Scopes des obigen SLAs — der Quellcode ist privat und wir verteilen ihn derzeit nicht.

Außerhalb des Scopes

  • Schwachstellen in Drittdiensten, von denen wir abhängen — Railway, Cloudflare, Resend, GitHub OAuth, Google OAuth, Open-Meteo, NOAA, Wikimedia, OpenStreetMap. Bitte direkt beim Upstream-Anbieter melden; wenn das Problem darin liegt, wie Nausika sie integriert (z. B. ein fehlender Redirect-URI-Check unsererseits), liegt es im Scope.
  • Berichte, die physischen Zugriff erfordern auf das Gerät eines Nutzers oder einen kompromittierten Browser/OS, es sei denn, ein Nausika-spezifisches Verhalten verschlimmert die Situation.
  • Fehlendes Rate-Limit auf Read-only-Endpoints unterhalb der dokumentierten serviceweiten Limits — sie werden als Performance-Arbeit, nicht als Sicherheitsproblem geführt.
  • „Findings" aus Best Practices ohne nachweisbaren Impact (fehlende Security-Header auf statischen Assets, Version-Disclosure auf Drittbibliotheken, die wir bereits in regelmäßigem Takt patchen, etc.) — wir lesen sie und prüfen sie, aber sie qualifizieren nicht für das obige SLA.

Was wir schützen, in einfachen Worten

Zwei verschiedene Asset-Klassen prägen unser Triage:

  • Nutzerbezogene Daten — deine Konto-E-Mail, OAuth-Token, Bootsprofil, gespeicherte Routen, Bewertungen, Favoriten, eingereichte Vorschläge. Cross-tenant-Zugriff auf eines davon wird als kritisch behandelt.
  • Öffentliche, aber kuratierte Daten — Orte, Attribute, Attributionsmetadaten, Bilder. Manipulationen, die beeinflussen, was andere Nutzer sehen (z. B. unautorisierte Schreibzugriffe auf places), werden als hoch behandelt; Lesezugriff darauf ist konstruktionsbedingt offen.

Nausika speichert keine Zahlungsdaten, Gesundheitsdaten, behördlichen ID-Daten oder Biometrie. Siehe Datenschutz für das vollständige Datenmodell und die Aufbewahrungsregel.

Hardening-Stand

Zur Transparenz: die Dinge, die wir kontinuierlich tun, nicht als Reaktion auf einzelne Berichte.

  • OAuth 2.1 mit PKCE für öffentliche Clients; opake Bearer-Token gehasht in unserer Datenbank gespeichert (kein JWT-Geheimnis, das abfließen kann).
  • Anti-SSRF-Validierung bei jedem Fetch aus nutzergelieferten URLs (Bild-Proxy, Ortsvorschläge).
  • Strikte CORS-Allow-List am MCP-Endpoint; Same-Origin-Anforderung an Konnektor-Icons gemäß MCP-Spezifikation.
  • Datenbankzugriff strikt über parametrisierte Queries (tagged template literals); keine string-konkatenierte SQL irgendwo im request-scoped Code.
  • 90 Tage Aufbewahrung der vollständigen Request-Logs, 30 Tage Aufbewahrung der Operational-Logs, automatische Bereinigung via Scheduled Job. Siehe Datenschutz.
  • Schema-Version-Guard am MCP-Service: der öffentliche Konnektor verweigert den Start gegen eine Datenbank, die älter ist als das erwartete Schema, um veraltete Deploys zu verhindern.

Wartung und Rückwärtskompatibilität

Sicherheitspatches erfordern manchmal Breaking Changes. Wenn das passiert, folgen wir den Ankündigungsregeln, die in der Roadmap beschrieben sind: 60 Tage Vorankündigung auf /log für Breaking-Interface-Änderungen, mit der Ausnahme von aktiver Ausnutzung, wo wir den Fix sofort ausliefern und die Änderung rückwirkend erklären.

Das umfassendere Versprechen, Nausika zu warten — Service-Verfügbarkeit, Sunset-Ankündigung, öffentliches Log — lebt in der Roadmap.