🔍 Penetration Testing — easySale Security Assessment¶
Dokument-Typ: Penetration Testing Framework & Results
Erstellt: 7. April 2026
Letztes Update: 7. April 2026
Status: 🟡 Pentest Q2 2026 geplant — Dokument vorbereitet für Ergebnisse
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 (Q2 2026) | Mai/Juni 2026 | 🟡 In Planung | — | TBD |
| Pentest #2 (jährlich) | Q2 2027 | 🔵 Geplant | — | — |
Hinweis: easySale hat bereits ein vollständiges OWASP Top 10 2021 Code-Audit durchgeführt (Februar 2026), bei dem 35 von 37 Findings behoben wurden. Der geplante Penetration Test ergänzt dieses Code-Audit 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 (Q2 2026)
3. Geplanter Pentest Q2 2026¶
Zeitplan¶
| Meilenstein | Datum (geplant) | Verantwortlich |
|---|---|---|
| Pentest-Firma auswählen | April 2026 | Security Team |
| Scope & Rules of Engagement finalisieren | Anfang Mai 2026 | Security Team + Pentest-Firma |
| Kick-off Meeting | Mitte Mai 2026 | Alle Stakeholder |
| Testing Phase | Mai/Juni 2026 (2-3 Wochen) | Pentest-Firma |
| Initial Report | Ende Juni 2026 | Pentest-Firma |
| Remediation Phase | Juli 2026 | easySale Dev-Team |
| Retest kritischer Findings | August 2026 | Pentest-Firma |
| Final Report & Sign-off | August 2026 | 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¶
Geplantes Budget: 15.000–25.000 EUR
(abhängig von Scope und Dauer)
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 — Q2 2026 (GEPLANT)¶
Status: 🟡 In Planung
DurchgefĂĽhrt von: TBD
Zeitraum: Mai/Juni 2026 (geplant)
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
🟡 Pentest-Firma Auswahl läuft
🔵 Kick-off geplant für Mai 2026
Nächste Schritte¶
- April 2026: Pentest-Firma finalisieren (RFP-Prozess)
- Anfang Mai: Rules of Engagement unterzeichnen
- Mitte Mai: Kick-off Meeting
- Mai/Juni: DurchfĂĽhrung Pentest Phase
- Juli: Remediation kritischer Findings
- August: Retest + Final Report
Verantwortlichkeiten¶
| Task | Verantwortlich | Deadline |
|---|---|---|
| Pentest-Firma auswählen | Security Team | 30.04.2026 |
| Scope finalisieren | Security Team + CTO | 10.05.2026 |
| Testing durchfĂĽhren | Pentest-Firma | 30.06.2026 |
| Findings beheben | Dev-Team | 31.07.2026 |
| Retest koordinieren | Security Team | 15.08.2026 |
| Dokumentation aktualisieren | Security Team | 31.08.2026 |
Dokument-Maintainer: Security Team (security@easysale.de)
Letzte Aktualisierung: 7. April 2026
Nächste Review: Nach Abschluss Pentest Q2 2026