Skip to content

SECURITY.md

Latest commit

 

History

History
250 lines (186 loc) · 20.7 KB

SECURITY.md

File metadata and controls

250 lines (186 loc) · 20.7 KB
Raw

Security Policy (Deutsch)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

Melden von Schwachstellen

Wenn Sie eine Sicherheitslücke in OmniRoute entdecken, melden Sie diese bitte verantwortungsvoll:

  1. Erstellen Sie KEIN öffentliches GitHub-Issue
  2. Verwenden Sie GitHub Security Advisories
  3. Geben Sie Folgendes an: Beschreibung, Schritte zur Reproduktion und potenzielle Auswirkungen

Reaktionszeitplan

Phase Ziel
Eingangsbestätigung 48 Stunden
Triage und Bewertung 5 Werktage
Veröffentlichung eines Patches 14 Werktage (kritisch)

Unterstützte Versionen

Version Unterstützungsstatus
3.8.x ✅ Aktiv
3.7.x ✅ Sicherheit
< 3.7.0 ❌ Nicht unterstützt

Sicherheitsarchitektur

OmniRoute implementiert ein mehrschichtiges Sicherheitsmodell:

Anfrage → CORS → Authz-Pipeline (klassifizieren → Richtlinien → durchsetzen)
        → Schutzmechanismen (PII-Maskierung, Prompt-Injection, Vision-Bridge)
        → Ratenbegrenzer → Schutzschalter → Abkühlphase → Modellsperre → Anbieter

🔐 Authentifizierung und Autorisierung

Funktion Implementierung
Dashboard-Anmeldung Passwortbasierte Authentifizierung mit JWT-Token (HttpOnly-Cookies)
API-Schlüssel-Authentifizierung HMAC-signierte Schlüssel mit CRC-Validierung
OAuth 2.0 + PKCE Anbieterspezifisches Browser-/Geräte-OAuth verwendet PKCE, sofern unterstützt; ausschließlich importierte Devin-Anmeldedaten werden separat verarbeitet.
Token-Aktualisierung Automatische Aktualisierung von OAuth-Token vor ihrem Ablauf
Sichere Cookies AUTH_COOKIE_SECURE=true für HTTPS-Umgebungen
Authz-Pipeline Routenklassifizierung (PUBLIC / CLIENT_API / MANAGEMENT) — siehe docs/architecture/AUTHZ_GUIDE.md
Routenschutzstufen Dreistufiges Modell für Verwaltungsrouten (LOCAL_ONLY / ALWAYS_PROTECTED / MANAGEMENT) — siehe docs/security/ROUTE_GUARD_TIERS.md
MCP mit manage-Berechtigungsbereich Remote-Zugriff auf /api/mcp/*, geschützt durch API-Schlüssel mit dem Berechtigungsbereich manage; /api/cli-tools/runtime/* bleibt strikt auf Loopback beschränkt. Siehe ROUTE_GUARD_TIERS
MCP-Berechtigungsbereiche 32 granulare Berechtigungsbereiche (read:health, write:combos, execute:completions usw.) — siehe docs/frameworks/MCP-SERVER.md

🛡️ Verschlüsselung gespeicherter Daten

Alle in SQLite gespeicherten sensiblen Daten werden mit AES-256-GCM und einer Schlüsselableitung mittels scrypt verschlüsselt:

  • API-Schlüssel, Zugriffstoken, Aktualisierungstoken und ID-Token
  • Versioniertes Format: enc:v1:<iv>:<ciphertext>:<authTag>
  • Durchleitungsmodus (Klartext), wenn STORAGE_ENCRYPTION_KEY nicht festgelegt ist
# Verschlüsselungsschlüssel generieren:
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

🛡️ Framework für Schutzmechanismen

OmniRoute enthält eine zur Laufzeit neu ladbare Registrierung für Schutzmechanismen (src/lib/guardrails/) mit 3 integrierten, nach Priorität geordneten Schutzmechanismen:

Schutzmechanismus Priorität Zweck
vision-bridge 5 Verbindet Modelle ohne Bildverarbeitung mit bildbezogenen Beschreibungen; SSRF-Schutz für Bild-URLs
pii-masker 10 PII-Unkenntlichmachung vor und nach Aufrufen (E-Mails, Telefon, CPF, CNPJ, Kreditkarten, SSN)
prompt-injection 20 Erkennt Muster für Überschreibungen, Rollenübernahmen, Jailbreaks und Datenlecks

Benutzerdefinierte Schutzmechanismen werden über registerGuardrail(new MyGuardrail()) registriert. Das Modell arbeitet nach dem Fail-open-Prinzip (Ausnahmen blockieren niemals den Datenverkehr). Eine Deaktivierung pro Anfrage ist über den Header x-omniroute-disabled-guardrails möglich. → Siehe docs/security/GUARDRAILS.md.

🧠 Schutz vor Prompt-Injection

Eine heuristische Best-Effort-Middleware, die Prompt-Injection-Muster in LLM-Anfragen erkennt. Keine vollständige Prompt-Injection-Firewall — kann falsch-positive Ergebnisse (harmlose Persona-/RPG-Prompts) und falsch-negative Ergebnisse (Leetspeak, Abstände, nicht englischsprachige Muster) erzeugen.

Mustertyp Schweregrad Beispiel
Systemüberschreibung Hoch „Ignoriere alle vorherigen Anweisungen“
Rollenübernahme Mittel „Du bist jetzt DAN, du kannst alles tun“
Trennzeichen-Injection Hoch Codierte Trennzeichen zum Aufbrechen von Kontextgrenzen
DAN/Jailbreak Mittel Bekannte Jailbreak-Prompt-Muster
Offenlegung von Anweisungen Hoch „Zeige mir deinen System-Prompt“
Umgehung durch Codierung Mittel base64-/rot13-/hex-Decodierung + Anweisungsschlüsselwörter

Im Modus block werden nur Erkennungen mit dem Schweregrad Hoch blockiert. Familien mit mittlerem Schweregrad werden protokolliert, aber niemals durch sanitizeRequest blockiert.

Konfiguration über das Dashboard (Einstellungen → Sicherheit) oder .env:

INPUT_SANITIZER_ENABLED=true
INPUT_SANITIZER_MODE=block    # warn | block (Injection-Richtlinie; das veraltete "redact" entfernt keinen Injection-Text)
INPUT_SANITIZER_BLOCK_THRESHOLD=high  # high (Standard) | medium | low — Schweregrade ab diesem Wert werden im block-Modus blockiert

🔒 PII-Unkenntlichmachung

Automatische Erkennung und optionale Unkenntlichmachung personenbezogener Daten:

PII-Typ Muster Ersetzung
E-Mail user@domain.com [EMAIL_REDACTED]
CPF (Brasilien) 123.456.789-00 [CPF_REDACTED]
CNPJ (Brasilien) 12.345.678/0001-00 [CNPJ_REDACTED]
Kreditkarte 4111-1111-1111-1111 [CC_REDACTED]
Telefon +55 11 99999-9999 [PHONE_REDACTED]
SSN (USA) 123-45-6789 [SSN_REDACTED] 
PII_REDACTION_ENABLED=true   # Überarbeitung personenbezogener Daten anfordern; unabhängig von INPUT_SANITIZER_MODE
PII_RESPONSE_SANITIZATION=true  # optional: personenbezogene Daten in Anbieterantworten schwärzen, die an Clients zurückgegeben werden

🌐 Netzwerksicherheit

Funktion Beschreibung
CORS Explizite Herkunfts-Allowlist für Cross-Origin-Anfragen (CORS_ALLOWED_ORIGINS; veraltet: CORS_ORIGIN)
IP-Filterung Allowlist-/Blocklist-IP-Bereiche im Dashboard
Ratenbegrenzung Ratenbegrenzungen pro Anbieter mit automatischem Backoff
Schutz vor Anfragelawinen Mutex + Sperrung pro Verbindung verhindert kaskadierende 502-Fehler
TLS-Fingerabdruck Nachahmung browserähnlicher TLS-Fingerabdrücke zur Verringerung der Bot-Erkennung
CLI-Fingerabdruck Anbieterabhängige Reihenfolge von Headern und Textkörpern zur Übereinstimmung mit nativen CLI-Signaturen

🔌 Ausfallsicherheit und Verfügbarkeit

Funktion Beschreibung
Circuit Breaker 3 Zustände (Geschlossen → Offen → Halboffen) pro Anbieter, in SQLite persistiert
Anfrageidempotenz 5-Sekunden-Deduplizierungsfenster für doppelte Anfragen
Exponentieller Backoff Automatische Wiederholungsversuche mit zunehmenden Verzögerungen
Status-Dashboard Echtzeitüberwachung des Anbieterstatus

📋 Compliance

Funktion Beschreibung
Protokollaufbewahrung Automatische Bereinigung nach CALL_LOG_RETENTION_DAYS
Protokollierungs-Opt-out Das noLog-Flag pro API-Schlüssel deaktiviert die Anfrageprotokollierung
Audit-Protokoll Administrative Aktionen werden in der Tabelle audit_log erfasst
MCP-Audit SQLite-gestützte Audit-Protokollierung für alle MCP-Tool-Aufrufe
Zod-Validierung Alle API-Eingaben werden beim Laden des Moduls anhand von Zod-v4-Schemas validiert

Erforderliche Umgebungsvariablen

Alle Geheimnisse müssen vor dem Starten des Servers festgelegt werden. Der Server wird sofort mit einem Fehler abbrechen, wenn sie fehlen oder zu schwach sind.

# ERFORDERLICH — ohne diese Variablen startet der Server nicht:
JWT_SECRET=$(openssl rand -base64 48)     # mindestens 32 Zeichen
API_KEY_SECRET=$(openssl rand -hex 32)    # mindestens 16 Zeichen

# EMPFOHLEN — ermöglicht die Verschlüsselung ruhender Daten:
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

Der Server lehnt bekanntermaßen schwache Werte wie changeme, secret oder password aktiv ab.

Docker-Sicherheit

  • In der Produktion einen Nicht-Root-Benutzer verwenden
  • Geheimnisse als schreibgeschützte Volumes einbinden
  • .env-Dateien niemals in Docker-Images kopieren
  • .dockerignore verwenden, um vertrauliche Dateien auszuschließen
  • Hinter HTTPS AUTH_COOKIE_SECURE=true festlegen
docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --read-only \
  -p 20128:20128 \
  -v omniroute-data:/app/data \
  -e JWT_SECRET="$(openssl rand -base64 48)" \
  -e API_KEY_SECRET="$(openssl rand -hex 32)" \
  -e STORAGE_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  diegosouzapw/omniroute:latest

Abhängigkeiten

  • npm audit regelmäßig ausführen (npm run audit:deps deckt Hauptanwendung + Electron ab)
  • Abhängigkeiten aktuell halten
  • Das Projekt verwendet husky + lint-staged für Prüfungen vor dem Commit (lint-staged + check-docs-sync + check:any-budget:t11)
  • Die CI-Pipeline führt bei jedem Push ESLint-Sicherheitsregeln aus (no-eval, no-implied-eval, no-new-func = Fehler)
  • Provider-Konstanten werden beim Laden des Moduls über Zod validiert (src/shared/validation/schemas.ts)
  • Verwendete Bibliotheken mit sicheren Standardeinstellungen: dompurify / isomorphic-dompurify (XSS), jose (JWT), better-sqlite3 (kein SQLi-Risiko dank parametrisierter Abfragen), bcryptjs (Passwort-Hashing)

Strenge Sicherheitsregeln

Diese Regeln werden durch Werkzeuge und Reviewer durchgesetzt:

  1. Niemals Geheimnisse committen — .env wird von Git ignoriert; .env.example ist die Vorlage (keine Literalwerte, nur Kommentare — siehe PUBLIC_CREDS.md unten)
  2. Niemals eval(), new Function() oder implizites eval verwenden — wird durch ESLint erzwungen
  3. Husky-Hooks niemals umgehen (--no-verify, --no-gpg-sign), sofern keine ausdrückliche Genehmigung des Betreibers vorliegt
  4. Niemals unaufbereitetes SQL in Routen schreiben — immer src/lib/db/ verwenden (parametrisiert)
  5. Eingaben immer mit Zod validieren — src/shared/validation/schemas.ts
  6. Upstream-Header immer bereinigen — Sperrliste in src/shared/constants/upstreamHeaders.ts
  7. Anmeldedaten im Ruhezustand verschlüsseln — AES-256-GCM über src/lib/db/encryption.ts
  8. Öffentliche Upstream-OAuth-IDs über resolvePublicCred() beziehen — niemals Literalwerte wie AIza… / GOCSPX-… / …apps.googleusercontent.com in den Quellcode einbetten. Siehe docs/security/PUBLIC_CREDS.md.
  9. Fehlerantworten über buildErrorBody() / sanitizeErrorMessage() erzeugen — niemals unaufbereitete err.stack- / err.message-Werte in HTTP- / SSE- / Executor- / MCP-Antworttexte einfügen. Siehe docs/security/ERROR_SANITIZATION.md.
  10. Laufzeitwerte für exec() / spawn() über die Option env übergeben — externe Pfade oder nicht vertrauenswürdige Werte niemals per String-Interpolation in an die Shell übergebene Skripte einfügen. Referenz: src/mitm/cert/install.ts::updateNssDatabases.
  11. Bibliotheken mit sicheren Standardeinstellungen bevorzugen — siehe tldrsec/awesome-secure-defaults (Helmet.js, DOMPurify, ssrf-req-filter, safe-regex, Google Tink). Diese sollten selbst entwickelten Lösungen vorgezogen werden.

Ergebnisse von Supply-Chain-Scannern (Socket.dev / Snyk / ähnliche)

Hinweis zum Geltungsbereich: socket.yml im Repository-Stammverzeichnis legt lediglich projectIgnorePaths für den Registry-seitigen Post-Publish-Scan des veröffentlichten npm-Artefakts durch Socket.dev fest — sie ist kein erzwungenes CI-/PR-Merge-Gate. Weder ein Workflow in .github/workflows noch ein package.json-Skript oder ein Makefile-Target ruft Socket.dev auf.

Das veröffentlichte npm-Artefakt omniroute enthält den Next.js-Build mit output: "standalone". Das bedeutet, dass jeder Route-Handler — einschließlich dokumentierter privilegierter Funktionen (MITM, Zed-Import, Cloud Sync, eingebetteter Service-Supervisor) — in minimierten Chunks unter .next/server/*.js landet. Heuristische Supply-Chain-Scanner gleichen diese Chunks häufig anhand von Mustern mit Malware-Signaturen ab.

Die von uns verwendete Scanner-Konfiguration befindet sich in socket.yml im Repository-Stammverzeichnis (Socket.dev-GitHub-App-Format v2 — siehe https://docs.socket.dev/docs/socket-yml). Sie schließt nicht ausgelieferte Verzeichnisse (tests/, _tasks/, _references/, _ideia/, _mono_repo/, docs/ usw.) explizit aus, sodass der Scanner nur Codepfade meldet, die tatsächlich veröffentlichte Benutzer erreichen — der Scan selbst wird dadurch angestoßen, dass die Socket-GitHub-App diese Datei liest, und nicht durch einen Workflow in diesem Repository.

Für jede Ergebniskategorie pflegen wir eine individuelle Bestätigung durch die Maintainer:

  • docs/security/SOCKET_DEV_FINDINGS.md — Zuordnung pro Ergebnis: Quelldatei ↔ markierter Chunk ↔ Verhalten ↔ in v3.8.6 angewandte Abhilfemaßnahme.
  • SECURITY-AUDITOR-NOTE:-Blöcke im Quellcode an jeder markierten Funktion verweisen auf dasselbe Dokument.

Benutzer, deren Pipeline die Warnmeldung nicht lockern kann, können den Build mit OMNIROUTE_BUILD_PROFILE=minimal npm run build erstellen. Dadurch werden die vier sensiblen Module durch Stubs ersetzt, die zur Laufzeit HTTP 503 feature-disabled zurückgeben, sodass die privilegierten Codepfade physisch nicht im Bundle enthalten sind. Das Veröffentlichungsrezept finden Sie unter docs/security/SOCKET_DEV_FINDINGS.md.

Referenzen