10 - Sicherheitsmaßnahmen¶
Dokument: Security-Architektur Stand: 28.02.2026 Scope: Alle Sicherheitsmechanismen der App Status: Audit-ready
1. Übersicht¶
| Bereich | Maßnahmen |
|---|---|
| Transaktionen | EIP-712, Nonce, Deadlines, Merkle Proofs |
| Authentifizierung | Web3Auth, EIP-191, Wallet-Validierung |
| API | Route-Whitelist, CSP, Adressvalidierung |
| Responsible Gaming | Limits, Self-Exclusion, KYC |
| Infrastruktur | Anti-Abuse, Rate Limiting, Error Logging |
2. Transaktionssicherheit¶
2.1 EIP-712 Typed Data Signaturen¶
Alle kritischen Transaktionen (Kauf, Claim) erfordern strukturierte, vom User signierte Permits:
| Permit-Typ | Verwendung | Felder |
|---|---|---|
| BuyPermit | Ticket-Kauf | buyer, poolId, tipsHash, deadline, nonce, maxGasCostUsdt |
| ClaimPermit | Gewinn-Auszahlung | claimer, amounts, deadline, nonce, claimsHash |
Sicherheitsgarantien: - Nutzer sieht exakt was signiert wird (strukturierte Daten) - Replay-Schutz durch Nonce - Zeitliche Begrenzung durch Deadline - Kosten-Obergrenze durch maxGasCostUsdt
2.2 Nonce-basierter Replay-Schutz¶
| Mechanismus | Beschreibung |
|---|---|
| Buy-Intent-Nonce | Eindeutige Nonce pro Intent, in DB gespeichert |
| Claim-Nonce | 16 Bytes random, einmalig verwendbar |
| Relayer-Nonce | Nonce-Manager verhindert doppelte TX-Submission |
2.3 Deadline-Mechanismus¶
| Typ | Dauer | Beschreibung |
|---|---|---|
| BuyPermit | Backend-generiert | Ablaufzeit im Intent festgelegt |
| ClaimPermit | 5 Minuten | calculateDeadline(5) |
| Claim-Timestamp | ± 5 Minuten | Replay-Fenster für Payload-Anfrage |
2.4 Merkle-Tree-Proofs¶
Claims werden gegen Merkle Trees verifiziert:
Settlement → Merkle Root generiert → On-Chain gespeichert
Claim → Backend liefert Proof → Contract verifiziert gegen Root
2.5 Intent-basiertes System¶
Jeder Intent hat eine eindeutige UUID, wird in der DB gespeichert und durchläuft definierte Statusübergänge.
3. Authentifizierungssicherheit¶
3.1 Web3Auth¶
| Maßnahme | Beschreibung |
|---|---|
| Sapphire Network | Distributed Key Generation (MPC) |
| Session-Timeout | 7 Tage max. Session-Dauer |
| MFA optional | Multi-Factor Authentication verfügbar |
| Plattform-spezifisch | Redirect vs. Popup je nach Umgebung |
3.2 Wallet-Konsistenzprüfung (Firefox-Fix)¶
Login → Wallet-Adresse in localStorage speichern
Session Restore → Aktuelle vs. gespeicherte Adresse vergleichen
→ Match: Weiter
→ Mismatch: Sofortiger Logout + Fehlermeldung
Hintergrund: Firefox/Web3Auth-Bug kann bei Session-Wiederherstellung andere Wallet laden. Diese Prüfung verhindert den Zugriff auf fremde Accounts.
3.3 EIP-191 Message Signing¶
Für Claim-Payload-Zugriff:
Message: "Claim payload request\nAddress: {addr}\nChainId: {chainId}\nTimestamp: {ts}"
Verifizierung: ecrecover(hash, signature) === claimed address
Replay-Schutz: |timestamp - now| < 5 Minuten
4. API-Sicherheit¶
4.1 Route-Whitelist (proxy.ts)¶
Request eingehend
→ Ist es ein API-Endpoint?
→ In der Whitelist? → Weiterleiten
→ Nicht in der Whitelist? → 404 Response
→ Ist es eine Seite?
→ In der Whitelist? → Weiterleiten
→ Nicht in der Whitelist? → Redirect zu /
→ Ist es ein Static File?
→ Bekannte Datei? → Weiterleiten
→ Unbekannt? → 404
4.2 Content Security Policy¶
Erlaubt Einbettung nur durch Telegram-Domains und die eigene App.
4.3 Adressvalidierung¶
Wallet-Adressen werden bei jedem API-Call geprüft: - Format: 0x-prefixed, 40 Hex-Zeichen - Checksumming via ethers.js - Case-insensitiver Vergleich in der DB
4.4 Telegram Webhook-Sicherheit¶
4.5 KYC Webhook-Sicherheit (Sumsub)¶
5. Responsible Gaming¶
5.1 Spending Limits¶
| Limit-Typ | Prüfung | Beschreibung |
|---|---|---|
| Tägliches Limit | dailyLimitUsdt |
Vor jedem Kauf geprüft |
| Wöchentliches Limit | weeklyLimitUsdt |
Vor jedem Kauf geprüft |
| Monatliches Limit | monthlyLimitUsdt |
Vor jedem Kauf geprüft |
Implementierung:
- Konfiguriert in User-Profil
- Geprüft in /api/buy/intent
- Aktueller Verbrauch aus DB berechnet (spentToday, spentThisWeek, spentThisMonth)
- 403 Response bei Überschreitung
5.2 Self-Exclusion¶
| Regel | Beschreibung |
|---|---|
| Dauer | 24 Stunden bis 365 Tage |
| Verkürzung | NICHT möglich (nur verlängern) |
| Prüfung | Bei jedem Kauf-Intent |
| Wirkung | Alle Käufe blockiert |
5.3 Altersverifizierung¶
- 18+ erforderlich
- Geburtsdatum wird im Profil geprüft
- Minderjährige erhalten 400 Fehler bei Profiländerung
5.4 KYC-Schwellenwerte¶
| Schwellenwert | Aktion |
|---|---|
| Unter Schwelle | Claim ohne KYC möglich |
| Über Schwelle | KYC erforderlich (kycRequired: true) |
| KYC Status none/pending | Claim blockiert |
| KYC Status verified | Claim freigegeben |
6. Anti-Abuse-Mechanismen¶
6.1 Gas-Faucet-Schutz¶
| Regel | Wert | Beschreibung |
|---|---|---|
| Max Unrecouped | 20 | Max. offene Faucet-Claims |
| Max pro Stunde | 50 | Rate-Limiting |
| Web3Auth-Only | Ja | Keine externen Wallets |
| 1 Claim/Wallet | Ja | Bis zum Recoup |
6.2 Affiliate-Anti-Abuse¶
| Regel | Beschreibung |
|---|---|
| Self-Referral | Verboten (Prüfung beim Binding) |
| Auszahlungstag | Nur Sonntags |
| Mindestaktivität | 5 bezahlte Tips in 6 Tagen |
| Erst-Login-Binding | Affiliate nur beim ersten Login bindbar |
6.3 Nonce-Manager¶
Verhindert Race Conditions bei parallelen Relayer-Transaktionen: - V1: Spinlock mit 120s Timeout - V2: Async Queue mit 50ms Rate-Limiting - Gap-Detection bei > 50 Nonces voraus
6.4 TX-in-Progress-Schutz¶
| Status | Verhalten |
|---|---|
| EXECUTING | Neuer Intent wird mit 409 abgelehnt |
| Seiten-Reload | Resume-Intent für Wiederaufnahme |
7. Daten-Sicherheit¶
7.1 Sensitive Daten¶
| Daten | Speicherort | Schutz |
|---|---|---|
| Private Keys | .env (Server) |
Nicht in NEXT_PUBLIC |
| Wallet-Adresse | localStorage | clearVerifiedWallet() bei Logout |
| Affiliate-Ref | localStorage | Gelöscht nach Binding |
| Session | Web3Auth | 7 Tage, verschlüsselt |
7.2 USDT-Allowance-Management¶
- Approval nur an explizite Contracts (ReserveVault, ClaimRouter)
- Revoke-Möglichkeit über
/account/revoke - Admin-Endpoint für Allowance-Widerruf
7.3 Error-Logging¶
Alle kritischen Fehler werden serverseitig geloggt: - Wallet-Adresse, E-Mail, Session-ID - Fehlercode, Stack-Trace - Aktion und Kontext - Intent-ID und TX-Hash
User-Ablehnungen werden NICHT geloggt (intentional, keine Fehler)
8. Sicherheits-Checkliste¶
| Prüfpunkt | Status | Beschreibung |
|---|---|---|
| EIP-712 Signaturen | Implementiert | Alle Transaktionen |
| Replay-Schutz | Implementiert | Nonce + Deadline |
| Merkle-Proofs | Implementiert | Claim-Verifizierung |
| Route-Whitelist | Implementiert | proxy.ts |
| CSP-Header | Implementiert | Telegram Frame-Schutz |
| Wallet-Validierung | Implementiert | Firefox-Fix |
| Spending Limits | Implementiert | Daily/Weekly/Monthly |
| Self-Exclusion | Implementiert | Nicht verkürzbar |
| KYC-Integration | Implementiert | Sumsub |
| Gas-Faucet-Limits | Implementiert | Anti-Abuse |
| Affiliate-Anti-Abuse | Implementiert | Aktivitäts-Check |
| Error-Logging | Implementiert | Server-seitig |
Weiterführende Dokumente: - 02 - Authentifizierung - 13 - KYC & Compliance - 15 - Konfiguration