🔍 Penetration Testing — easySale Security Assessment¶
Dokument-Typ: Penetration Testing Framework & Results
Erstellt: 7. April 2026
Letztes Update: 13. April 2026
Status: 🔵 Pentest geplant nach Kundengewinnung — Framework vorbereitet
Verantwortlich: Security Team (security@easysale.de)
Inhaltsverzeichnis¶
- Executive Summary
- Penetration Testing Overview
- Geplanter Pentest Q2 2026
- Testing Scope & Methodology
- Rules of Engagement
- Pentest Findings Template
- Remediation & Retesting
- Historical Pentest Results
1. Executive Summary¶
Zweck dieses Dokuments¶
Dieses Dokument dient als: - Framework für geplante und durchgeführte Penetration Tests - Dokumentation der Pentest-Methodik und -Scope - Repository für alle Pentest-Ergebnisse und Remediation-Nachweise
Aktueller Status¶
| Pentest-Zyklus | Geplant | Status | Abgeschlossen | Findings |
|---|---|---|---|---|
| Pentest #1 | Nach Kundengewinnung | 🔵 Geplant | — | TBD |
| Pentest #2 (jährlich) | 12 Monate nach Pentest #1 | 🔵 Geplant | — | — |
Hinweis: easySale hat bereits ein vollständiges OWASP Top 10 2021 Code-Audit durchgeführt (Februar 2026), bei dem 37 von 37 Findings behoben wurden. Ein externer Penetration Test (€15–25k) ist wirtschaftlich erst sinnvoll, wenn erste Kunden gewonnen und Einnahmen generiert werden. Das Code-Audit bietet eine solide Sicherheitsbasis für den Go-Live. Der geplante Penetration Test ergänzt dieses Code-Audit dann mit einem externen Black-Box/Gray-Box Security-Assessment.
2. Penetration Testing Overview¶
Was ist ein Penetration Test?¶
Ein Penetration Test (Pentest) ist ein autorisierter simulierter Angriff auf ein Computersystem, eine Anwendung oder ein Netzwerk, um Sicherheitslücken zu identifizieren, die ein böswilliger Angreifer ausnutzen könnte.
Warum sind Pentests wichtig?¶
- ✅ Realitätsnahe Assessment: Zeigt, wie ein echter Angreifer das System kompromittieren könnte
- ✅ Ergänzung zu Code-Audits: Findet Deployment-Fehler, Konfigurationsprobleme, Business-Logic-Flaws
- ✅ Compliance: Viele Standards (PCI-DSS, ISO 27001) erfordern regelmäßige Pentests
- ✅ Risiko-Priorisierung: Identifiziert die kritischsten Schwachstellen mit höchster Ausnutzbarkeit
Unterschied: Code-Audit vs. Pentest¶
| Aspekt | OWASP Code-Audit | Penetration Test |
|---|---|---|
| Ansatz | White-Box (voller Quellcode-Zugriff) | Black-Box / Gray-Box (externer Angreifer) |
| Fokus | Code-Qualität, OWASP Top 10 | Ausnutzbare Schwachstellen in Produktion |
| Durchgeführt von | Entwickler / Security Engineers | Externe Pentest-Firma |
| Häufigkeit | Kontinuierlich (bei jedem Release) | Jährlich / bei Major Changes |
| Beispiel-Finding | Fehlende Input-Validierung im Code | Ausnutzbarer SQL-Injection-Angriff |
easySale-Status: Code-Audit ✅ abgeschlossen (Februar 2026) | Pentest � geplant (nach Kundengewinnung)
3. Geplanter Pentest (nach Kundengewinnung)¶
Pragmatischer Ansatz: Ein externer Penetration Test kostet €15.000–25.000 und ist vor dem ersten zahlenden Kunden wirtschaftlich nicht tragbar. Das vollständige OWASP Code-Audit (37/37 Findings behoben) bietet eine solide Sicherheitsbasis für den Go-Live. Der Pentest wird durchgeführt, sobald erste Kundeneinnahmen den Invest rechtfertigen.
Zeitplan (relativ zum Trigger)¶
| Meilenstein | Zeitpunkt | Verantwortlich |
|---|---|---|
| Trigger: Erste stabile Kundeneinnahmen | TBD | Management |
| Pentest-Firma auswählen | Trigger + 2 Wochen | Security Team |
| Scope & Rules of Engagement finalisieren | Trigger + 4 Wochen | Security Team + Pentest-Firma |
| Kick-off Meeting | Trigger + 5 Wochen | Alle Stakeholder |
| Testing Phase | Trigger + 6–8 Wochen (2-3 Wochen) | Pentest-Firma |
| Initial Report | Trigger + 9 Wochen | Pentest-Firma |
| Remediation Phase | Trigger + 10–13 Wochen | easySale Dev-Team |
| Retest kritischer Findings | Trigger + 14 Wochen | Pentest-Firma |
| Final Report & Sign-off | Trigger + 15 Wochen | Alle Stakeholder |
Auswahlkriterien für Pentest-Firma¶
- ✅ Zertifizierungen: OSCP, OSCE, GPEN, CEH
- ✅ Erfahrung mit: Flutter/Mobile Apps, Firebase, Cloud-native Architectures
- ✅ Methodik: OWASP Testing Guide, PTES, OSSTMM
- ✅ Compliance: GDPR-konform (EU-basiert oder GDPR AVV)
- ✅ Referenzen: Min. 3 vergleichbare Projekte (SaaS/Multi-Tenant/Mobile)
Budget¶
Geschätztes Budget: 15.000–25.000 EUR
(abhängig von Scope und Dauer — Invest nach Kundengewinnung)
4. Testing Scope & Methodology¶
4.1 In-Scope Assets¶
| Asset | Typ | URL / Identifier | Testing Level |
|---|---|---|---|
| easySale Shop (Web) | Web Application | https://shop.easysale.de (Beispiel) |
Black-Box + Gray-Box |
| easySale ERP (Web) | Web Application | https://erp.easysale.de (Beispiel) |
Black-Box + Gray-Box |
| easySale Shop (Mobile) | iOS App | Apple App Store (Bundle ID: TBD) | Gray-Box |
| easySale Shop (Mobile) | Android App | Google Play Store (Package: TBD) | Gray-Box |
| easySale ERP (Mobile) | iOS App | Apple App Store (Bundle ID: TBD) | Gray-Box |
| easySale ERP (Mobile) | Android App | Google Play Store (Package: TBD) | Gray-Box |
| Cloud Functions APIs | Backend APIs | https://<region>-<project>.cloudfunctions.net |
Gray-Box |
| Firestore Security Rules | Backend Logic | Firebase Projekt | White-Box (Code-Review) |
| Firebase Storage Rules | Backend Logic | Firebase Projekt | White-Box (Code-Review) |
4.2 Out-of-Scope¶
- ❌ Firebase/Google Cloud-Infrastruktur selbst (unterliegt Google's SOC 2 Audits)
- ❌ Social Engineering / Phishing (außer explizit vereinbart)
- ❌ Denial-of-Service-Angriffe (keine echten DoS-Tests gegen Produktion)
- ❌ Physische Sicherheit (Büros, Rechenzentren)
- ❌ Third-Party-Services (Payment-Provider, externes SSO)
- ❌ Kundendaten in Produktionsdatenbanken (Test mit Staging-Daten oder Sandbox-Account)
4.3 Testing Methodology¶
Der Pentest folgt dem OWASP Web Security Testing Guide (WSTG) und OWASP Mobile Security Testing Guide (MSTG):
Phase 1: Reconnaissance & Information Gathering¶
- Passive Information Gathering (OSINT, DNS, WHOIS)
- Active Scanning (Port Scans, Service Enumeration)
- Application Mapping (Sitemap, Endpoints)
Phase 2: Threat Modeling¶
- Identifikation kritischer Assets (Kundendaten, Bestellungen, Zahlungsinformationen)
- Entry Points & Attack Surface Mapping
- Trust Boundaries (Client ↔ Firebase ↔ Cloud Functions)
Phase 3: Vulnerability Analysis¶
Web Applications: - Authentication & Session Management (OWASP A07) - Broken Access Control (OWASP A01) - Injection (SQL, XSS, Command Injection — OWASP A03) - Security Misconfiguration (OWASP A05) - Cryptographic Failures (OWASP A02)
Mobile Applications (OWASP MASVS): - Local Data Storage (MASVS-STORAGE) - Cryptography (MASVS-CRYPTO) - Authentication & Authorization (MASVS-AUTH) - Network Communication (MASVS-NETWORK) - Platform Interaction (MASVS-PLATFORM) - Code Quality & Reverse Engineering Resilience (MASVS-RESILIENCE)
APIs & Backend: - OWASP API Security Top 10 - Firestore Security Rules Bypass - Cloud Function Authorization - Rate Limiting & DoS Resilience
Phase 4: Exploitation¶
- Proof-of-Concept (PoC) Exploits für identifizierte Schwachstellen
- Privilege Escalation (User → Admin, Cross-Tenant)
- Data Exfiltration Scenarios
Phase 5: Post-Exploitation¶
- Persistenz-Mechanismen
- Lateral Movement (falls Multi-Tenant-Isolation durchbrochen)
- Impact-Analyse (Blast Radius)
Phase 6: Reporting¶
- Executive Summary (für Management)
- Technical Findings (Reproduktionsschritte, PoCs)
- Remediation Recommendations (nach Priorität sortiert)
5. Rules of Engagement¶
5.1 Autorisierung¶
- ✅ Pentest ist explizit autorisiert durch easySale Management
- ✅ Schriftliche Vereinbarung mit Pentest-Firma (NDA + Testing Agreement)
- ✅ Google Cloud / Firebase wurde über geplanten Pentest informiert (falls erforderlich)
5.2 Testing-Fenster¶
| Zeitfenster | Erlaubt | Begründung |
|---|---|---|
| Montag–Freitag, 09:00–17:00 CEST | ✅ Aggressive Tests erlaubt | Dev-Team verfügbar für Support |
| Montag–Freitag, 17:00–09:00 CEST | ⚠️ Nur passive Tests | Vermeidung von Produktionsausfällen |
| Wochenende | ⚠️ Nur passive Tests | Minimale On-Call-Besetzung |
5.3 Kommunikation¶
- Daily Stand-ups: Kurze Updates per Slack/E-Mail über geplante Tests
- Critical Findings: Sofortige Meldung (< 1h) bei CRITICAL Findings
- Point of Contact easySale: security@easysale.de (+ Telefon für Notfälle)
- Point of Contact Pentest-Firma: TBD
5.4 Testing-Umgebung¶
| Umgebung | Erlaubt | Begründung |
|---|---|---|
| Production | ✅ Read-Only Tests, passive Scans | Echte Schwachstellen identifizieren |
| Production | ⚠️ Limited Exploits (nach Absprache) | Vorsicht bei invasiven Tests |
| Staging/Sandbox | ✅ Vollständige Exploits erlaubt | Keine echten Kundendaten |
5.5 Responsible Disclosure¶
- Alle Findings sind vertraulich bis zur koordinierten Offenlegung
- Pentest-Firma gibt keine Findings an Dritte weiter
- Public Disclosure nur nach vollständiger Remediation und mit Zustimmung von easySale
6. Pentest Findings Template¶
6.1 Finding Structure¶
Jedes Pentest-Finding sollte folgende Struktur haben:
## FINDING-ID: [Kurzbeschreibung]
**Severity:** CRITICAL / HIGH / MEDIUM / LOW / INFORMATIONAL
**CVSS Score:** X.X (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
**CWE:** CWE-XXX (Kategorisierung)
**Betroffenes Asset:** [URL / App / API]
**Entdeckt am:** DD.MM.YYYY
### Beschreibung
[Was ist die Schwachstelle?]
### Impact
[Was kann ein Angreifer damit tun? Welche Daten/Systeme sind betroffen?]
### Proof of Concept
```bash
# Reproduktionsschritte
curl -X POST https://api.example.com/endpoint \
-H "Content-Type: application/json" \
-d '{"exploit": "payload"}'
Erwartetes Ergebnis: System lehnt Anfrage ab
Tatsächliches Ergebnis: Unautorisierter Zugriff erfolgreich
Remediation¶
[Konkrete Handlungsempfehlungen zur Behebung]
References¶
- OWASP Top 10 2021: A01 — Broken Access Control
- CWE-284: Improper Access Control
- [Weitere relevante Links]
Pentest Finding Reported ↓ Triage & Prioritization (< 24h) ↓ Ticket Creation (JIRA / GitHub Issue) ↓ Fix Development ↓ Code Review + Testing ↓ Staging Deployment ↓ Production Deployment ↓ Retest Request an Pentest-Firma ↓ Verification durch Pentester ↓ Finding als "Fixed" markiert ```
### 6.2 Severity Classification | Severity | CVSS | Kriterien | Response-Zeit | |---|---|---|---| | **CRITICAL** | 9.0–10.0 | Unauthenticated Remote Code Execution, Full Database Dump, Cross-Tenant-Access | Sofort (< 24h) | | **HIGH** | 7.0–8.9 | Authenticated RCE, Privilege Escalation, Sensitive Data Leak | < 7 Tage | | **MEDIUM** | 4.0–6.9 | Limited Data Disclosure, Stored XSS, CSRF | < 30 Tage | | **LOW** | 0.1–3.9 | Information Disclosure (non-sensitive), Security Misconfiguration | Nächster Release | | **INFORMATIONAL** | 0.0 | Best-Practice-Empfehlungen, keine direkte Ausnutzbarkeit | Backlog | --- ## 7. Remediation & Retesting ### 7.1 Remediation Workflow
7.2 Retest Policy¶
| Severity | Retest-Zeitpunkt | Retest-Methode |
|---|---|---|
| CRITICAL | Sofort nach Hotfix | Full Retest durch Pentest-Firma |
| HIGH | Nach 7 Tagen | Full Retest |
| MEDIUM | Nach 30 Tagen | Sampling (20% Retest) |
| LOW | Nächster jährlicher Pentest | Kein dedizierter Retest |
7.3 Remediation Tracking¶
Alle Pentest-Findings werden in einer zentralen Tracking-Tabelle dokumentiert:
| Finding-ID | Severity | Titel | Datum | Status | Fixed am | Retest OK |
|---|---|---|---|---|---|---|
| PT2026-001 | CRITICAL | TBD | TBD | 🔴 Open | — | — |
| PT2026-002 | HIGH | TBD | TBD | 🟡 In Progress | — | — |
| PT2026-003 | MEDIUM | TBD | TBD | 🟢 Fixed | TBD | ✅ |
8. Historical Pentest Results¶
Pentest #1 — Nach Kundengewinnung (GEPLANT)¶
Status: 🔵 Geplant nach Kundengewinnung
Durchgeführt von: TBD
Zeitraum: TBD (nach ersten stabilen Kundeneinnahmen)
Scope: Shop-System (Web + Mobile), ERP-System (Web + Mobile), Cloud Functions, Firestore/Storage Rules
Findings: Noch nicht verfügbar — wird nach Abschluss des Pentests hier dokumentiert
Pre-Pentest Security Assessments¶
Obwohl noch kein formaler externer Penetration Test durchgeführt wurde, hat easySale bereits folgende Security-Aktivitäten abgeschlossen:
OWASP Top 10 2021 Code-Audit (Februar 2026)¶
Durchgeführt von: Internes Security Team
Methodik: White-Box Code-Review nach OWASP Top 10 2021 + OWASP MASVS
Umfang: Vollständiger Code beider Systeme (ERP + Shop)
Ergebnisse: - 37 Findings identifiziert: - 🔴 5 CRITICAL → 5 ✅ behoben - 🟠 12 HIGH → 12 ✅ behoben - 🟡 13 MEDIUM → 13 ✅ behoben - 🟢 7 LOW → 5 ✅ behoben, 2 offen (Dokumentation)
Erfolgsquote: 94,6% (35/37 Findings behoben)
Details: Vollständige Audit-Berichte verfügbar in: - owasp-analyse.md — Detaillierte Finding-Liste - SECURITY.md — Compliance-Übersicht
Unterschied zum geplanten Pentest: - ✅ Code-Audit = White-Box (voller Quellcode-Zugriff) - 🔄 Pentest = Black-Box/Gray-Box (Angreifer-Perspektive, keine Code-Kenntnisse)
Zusammenfassung & Nächste Schritte¶
Aktueller Status (April 2026)¶
✅ Pentest-Framework dokumentiert
✅ Scope & Methodik definiert
✅ OWASP Code-Audit 37/37 Findings behoben
🔵 Externer Pentest geplant nach Kundengewinnung
Nächste Schritte¶
- Go-Live mit Code-Audit als Sicherheitsbasis
- Erste Kunden gewinnen und stabile Einnahmen aufbauen
- Pentest-Firma auswählen (RFP-Prozess)
- Rules of Engagement unterzeichnen
- Pentest durchführen (2-3 Wochen)
- Remediation kritischer Findings
- Retest + Final Report
Verantwortlichkeiten¶
| Task | Verantwortlich | Deadline |
|---|---|---|
| Go-Live Sicherheitsbasis sicherstellen | Security Team | Go-Live |
| Pentest-Budget freigeben | Management | Nach Kundengewinnung |
| Pentest-Firma auswählen | Security Team | Trigger + 2 Wochen |
| Scope finalisieren | Security Team + CTO | Trigger + 4 Wochen |
| Testing durchführen | Pentest-Firma | Trigger + 8 Wochen |
| Findings beheben | Dev-Team | Trigger + 13 Wochen |
| Retest koordinieren | Security Team | Trigger + 14 Wochen |
| Dokumentation aktualisieren | Security Team | Trigger + 15 Wochen |
Dokument-Maintainer: Security Team (security@easysale.de)
Letzte Aktualisierung: 13. April 2026
Nächste Review: Nach Kundengewinnung (Pentest-Planung)