Penetration-Testing-Grundlagen für Entwickler-Teams

1. Penetration Test vs. Vulnerability Scan: der entscheidende Unterschied

Ein Vulnerability Scan ist ein automatisierter, signaturbasierter Abgleich einer Anwendung oder Infrastruktur gegen bekannte Schwachstellen, veraltete Softwareversionen und typische Fehlkonfigurationen. Tools wie Nessus, OpenVAS oder OWASP ZAP im Automatik-Modus liefern innerhalb weniger Stunden eine lange Liste potenzieller Probleme, priorisiert nach CVE-Score. Das ist schnell, günstig und beliebig oft wiederholbar, produziert aber auch eine erhebliche Zahl an False Positives und erkennt keine Schwachstellen, die aus dem Zusammenspiel mehrerer eigentlich harmloser Funktionen entstehen.

Ein Penetration Test simuliert dagegen einen realen Angreifer: ein Mensch, unterstützt durch Tools, verkettet einzelne Schwachstellen zu einem tatsächlichen Angriffspfad, prüft Business-Logic-Fehler wie manipulierbare Preise oder umgehbare Rabattregeln und liefert für jeden kritischen Fund einen Proof of Concept statt nur einer Vermutung. Beide Methoden ergänzen sich, ersetzen sich aber nicht: automatisierte Scans laufen idealerweise wöchentlich oder bei jedem Deployment, ein vollständiger Pentest findet typischerweise jährlich oder vor größeren Architekturänderungen statt.

2. Black-Box, Grey-Box und White-Box: die drei Testansätze

Beim Black-Box-Test erhält das Testteam keinerlei internes Wissen, nur die URL oder IP-Adresse des Ziels, genau wie ein externer Angreifer ohne Insiderwissen. Das liefert die realistischste Außenperspektive, ist aber durch das begrenzte Zeitbudget des Tests in der erreichbaren Tiefe limitiert, weil viel Zeit für reine Informationsbeschaffung draufgeht, die ein echter Angreifer über Wochen oder Monate strecken könnte.

Der White-Box-Test gibt dem Testteam vollen Zugriff auf Quellcode, Architekturdokumentation und Testzugänge aller Rollen und kommt damit einem gezielten Code-Security-Review sehr nahe, findet dadurch auch tief liegende Logikfehler, die von außen kaum sichtbar wären. Der Grey-Box-Test liegt dazwischen: Das Team bekommt typischerweise einen niedrig privilegierten Kundenaccount, wie ihn auch ein registrierter Nutzer oder ein Angreifer mit geleakten Zugangsdaten hätte. Für E-Commerce-Shops ist Grey-Box meist die sinnvollste Wahl, weil damit realistisch der Checkout, das Kundenkonto und API-Endpunkte mit echter Session geprüft werden, ohne die komplette Codebasis vorab offenzulegen.

3. Scoping: was in den Test gehört und was nicht

Ein präzises Scoping-Dokument listet exakt, welche Domains, Subdomains, IP-Bereiche und API-Endpunkte getestet werden dürfen, in welcher Umgebung (Staging oder Produktion) und in welchem Zeitfenster. Ebenso wichtig ist die explizite Auflistung ausgeschlossener Systeme, etwa Zahlungsdienstleister im PCI-DSS-Geltungsbereich eines Drittanbieters oder eingebundene Marketing-Tools, für die keine Freigabe des jeweiligen Anbieters vorliegt. Ohne diese Trennschärfe drohen Tests versehentlich fremde Infrastruktur zu treffen.

Genauso gehören erlaubte und verbotene Techniken ins Scoping: Denial-of-Service-Tests, Social Engineering gegen Mitarbeitende oder physische Zutrittsversuche sind Standardmäßig ausgeschlossen, sofern nicht separat vereinbart. Tests gegen die Produktivumgebung bergen reales Risiko für Datenintegrität und Verfügbarkeit, deshalb ist eine Staging-Umgebung mit realistischen, aber anonymisierten Daten die bevorzugte Wahl. Muss dennoch gegen Produktion getestet werden, sollten destruktive Aktionen wie eine echte Zahlungsauslösung explizit aus dem Scope genommen werden.

# rules-of-engagement.yaml - Scoping-Dokument fuer einen Penetration Test
# Dieses Dokument muss von einer autorisierten Vertretung der
# Zielorganisation unterschrieben werden, BEVOR ein Test beginnt.
engagement:
  client: "Mironsoft Demo GmbH"
  target_systems:
    - "https://shop.example.com (Produktion, nur lesende Aktionen erlaubt)"
    - "https://staging.shop.example.com (Staging, vollstaendiger Test erlaubt)"
  excluded_systems:
    - "Payment-Provider-APIs (PCI-DSS-Scope, Drittanbieter)"
    - "Marketing-Tools von Drittanbietern (keine Freigabe des Anbieters)"
  test_type: "grey-box"
  test_window:
    start: "2026-08-03T08:00:00+02:00"
    end: "2026-08-07T18:00:00+02:00"
  allowed_techniques:
    - "authentifiziertes und unauthentifiziertes Testen der Webanwendung"
    - "API-Sicherheitstests (REST, GraphQL)"
    - "Tests auf Business-Logic-Schwachstellen"
  prohibited_techniques:
    - "Denial of Service / Lasttests"
    - "Social Engineering gegen Mitarbeitende"
    - "physische Zutrittsversuche"
  emergency_contact:
    name: "Lead Developer, Mironsoft"
    phone: "+49 30 000000"
    escalation_sla_minutes: 30
  authorization:
    signed_by: "CTO, Client GmbH"
    signature_date: "2026-07-20"
    written_permission_reference: "SOW-2026-0142"

4. Autorisierung: schriftliche Freigabe ist Pflicht, keine Option

Jede Form von Penetration-Testing-Technik gegen Systeme ohne vorherige schriftliche Genehmigung ist unbefugter Zugriff und in praktisch jeder Rechtsordnung strafbar, unabhängig von guten Absichten. In Deutschland greifen hier §202a und §202c StGB (Ausspähen und Vorbereiten des Ausspähens von Daten), in den USA der Computer Fraud and Abuse Act, in anderen Ländern vergleichbare Gesetze. Eine mündliche Zusage, eine informelle Slack-Nachricht oder die bloße Vermutung, dass „das schon in Ordnung geht", reichen nicht aus. Erforderlich ist ein unterschriebenes Rules-of-Engagement- oder Statement-of-Work-Dokument mit exaktem Scope, Testzeitraum und einer unterzeichnenden Person, die tatsächlich die Befugnis hat, für die betroffenen Systeme eine Freigabe zu erteilen, nicht irgendein beliebiger Mitarbeiter.

Bei Infrastruktur, die bei einem Cloud-Anbieter, CDN oder SaaS-Dienst gehostet wird, reicht die Freigabe des Kunden allein häufig nicht aus. Anbieter wie AWS oder Azure verlangen für bestimmte Testarten eine separate Vorabmeldung über eigene Formulare, weil sonst geteilte Infrastruktur betroffen sein könnte. Das unterschriebene Autorisierungsdokument muss außerdem einen Notfallkontakt und klare Abbruchbedingungen enthalten, damit ein Test sofort gestoppt wird, sobald etwas Unerwartetes auftritt, etwa Hinweise auf einen bereits real existierenden, aktiven Einbruch in das System.

5. Interner Security Review vs. externer Pentest

Ein interner Security Review durch das eigene Entwickler-Team, bestehend aus Code-Review, Dependency-Scanning und Threat Modeling, ist günstig, kontinuierlich durchführbar und profitiert vom tiefen Wissen über die eigene Codebasis. Der Nachteil liegt in blinden Flecken: dieselben Annahmen, die einen Fehler verursacht haben, führen häufig dazu, dass genau dieser Fehler beim eigenen Review übersehen wird, weil niemand aktiv gegen die eigene Architektur denkt.

Ein externer Penetration Test bringt eine unabhängige, adversarial denkende Perspektive und Erfahrung aus vielen unterschiedlichen Codebasen und Angriffsmustern mit, die intern selten in dieser Breite vorhanden ist. Compliance-Rahmenwerke wie PCI DSS oder ISO 27001 sowie viele Cyberversicherungen verlangen ohnehin einen unabhängigen externen Nachweis. Der Nachteil ist der höhere Preis und der Charakter einer Momentaufnahme. Die sinnvollste Kombination aus beiden Welten: kontinuierlicher interner Review plus automatisiertes Scanning im Alltag, ergänzt durch einen periodischen externen Pentest vor größeren Releases oder mindestens einmal jährlich.

Die Tabelle zeigt keine Konkurrenz, sondern zwei sich ergänzende Ebenen der Qualitätssicherung. Scans decken die Breite ab und laufen automatisiert bei jedem Deployment mit, ein Pentest deckt die Tiefe ab und findet genau die Schwachstellen, an denen Automatisierung strukturell scheitert.

6. Wie sich Entwickler-Teams auf einen Pentest vorbereiten

Vor dem eigentlichen Test sollte eine stabile, produktionsnahe Testumgebung mit denselben Abhängigkeiten und Versionen bereitstehen, inklusive Testzugängen für alle im Scope genannten Rollen, vom anonymen Gast bis zur eingeschränkten Admin-Rolle. Logging und Monitoring müssen aktiv sein, damit sich Testaktivität später sauber im eigenen System nachvollziehen lässt. Nicht zwingend notwendige Deployments während des Testfensters einzufrieren verhindert, dass sich der Scope während des laufenden Tests unter den Testenden verschiebt.

Ein interner Ansprechpartner mit der Befugnis, den Test bei einem kritischen Live-Problem sofort zu pausieren, sollte während des gesamten Zeitraums erreichbar sein. Mindestens Ops- beziehungsweise SRE-Verantwortliche und relevante Security-Stakeholder müssen wissen, dass ein autorisierter Test läuft, damit legitimer Testverkehr nicht versehentlich als echter Angriff interpretiert wird und einen unnötigen Incident-Response-Prozess auslöst.

7. Während des Tests: Kommunikation und Monitoring

Ein vereinbarter Kommunikationskanal mit täglichem Statusupdate und einem klaren Eskalationsweg für kritische Findings gehört zu jedem professionellen Test. Kritische Funde, etwa eine aktiv ausnutzbare Remote Code Execution oder eine offen zugängliche Kundendatenbank, sollten sofort gemeldet werden und nicht erst im Abschlussbericht, damit das Entwickler-Team parallel mit der Behebung beginnen kann, statt tagelang ungeschützt zu bleiben.

Monitoring, WAF und IDS bleiben im Normalbetrieb aktiv, sofern nicht ausdrücklich anders vereinbart, denn ihre Deaktivierung würde genau die reale Widerstandsfähigkeit unsichtbar machen, die der Test eigentlich prüfen soll. Eine Ausnahme sind reine Business-Logic-Tests, bei denen geblockte Requests nur unnötiges Rauschen erzeugen würden. Jede Testaktion auf Seiten des Pentesters wird gemäß Rules of Engagement dokumentiert und lässt sich mit den internen Logs abgleichen, sodass Auffälligkeiten schnell dem autorisierten Test zugeordnet werden können, statt einen falschen Alarm auszulösen.

#!/usr/bin/env bash
# recon.sh - Automatisierte Recon strikt innerhalb eines autorisierten Pentest-Scopes
# Dieses Skript verweigert die Ausfuehrung ohne explizite, schriftliche Freigabe.
set -euo pipefail

readonly SCOPE_FILE="./scope.yaml"
readonly CONSENT_REF="${CONSENT_REF:?CONSENT_REF setzen: Referenz der unterschriebenen Freigabe/SOW, z.B. SOW-2026-0142}"
readonly TARGET="${1:?Verwendung: recon.sh <target-domain>}"

# Harter Stopp: niemals ohne Scope-Datei und Consent-Referenz fortfahren
if [[ ! -f "$SCOPE_FILE" ]]; then
  echo "[ABBRUCH] Keine scope.yaml gefunden. Testen ohne schriftliche Autorisierung ist illegal." >&2
  exit 1
fi

if ! grep -q "$TARGET" "$SCOPE_FILE"; then
  echo "[ABBRUCH] Ziel $TARGET ist nicht im autorisierten Scope gelistet. Stoppe." >&2
  exit 1
fi

echo "[INFO] Autorisierungs-Referenz: $CONSENT_REF"
echo "[INFO] Ziel im Scope bestaetigt: $TARGET"

mkdir -p "results/$TARGET"

# Nur passive/geringfuegige Recon, keine Exploitation, keine Lasttests
nmap -sV --top-ports 100 -oN "results/$TARGET/nmap.txt" "$TARGET"
curl -sI "https://$TARGET" -o "results/$TARGET/headers.txt"
subfinder -d "$TARGET" -silent -o "results/$TARGET/subdomains.txt"

echo "[FERTIG] Recon innerhalb des autorisierten Scopes fuer $TARGET abgeschlossen"

8. Nach dem Test: Findings bewerten und priorisieren

Ein guter Pentest-Bericht strukturiert jeden Fund mit Schweregrad, meist auf Basis von CVSS, Reproduktionsschritten, Nachweisen, betroffener Komponente und konkreter Remediation-Empfehlung. Entwickler-Teams sollten Findings nach tatsächlicher Ausnutzbarkeit und Business-Impact priorisieren, nicht allein nach CVSS-Wert: ein „hoch" eingestufter Fund in einem internen Admin-Tool ohne externe Erreichbarkeit kann in der Praxis weniger dringend sein als ein „mittel" eingestufter Fund, der direkt aus dem Checkout heraus erreichbar ist.

Jedem Finding sollte ein klarer Owner und eine Frist zugewiesen werden, gestaffelt nach Schweregrad, etwa kritisch gleich am selben Tag, hoch innerhalb des laufenden Sprints, mittel im nächsten Release-Zyklus. Findings gehören in denselben Issue-Tracker wie reguläre Bugs, statt in einem separaten PDF zu verschwinden, das niemand mehr öffnet. Für jedes kritische und hohe Finding sollte ein verifizierter Retest verpflichtend sein, bevor es als geschlossen markiert wird.

{
  "finding_id": "PT-2026-0142-007",
  "engagement_reference": "SOW-2026-0142",
  "title": "IDOR im Bestell-Endpunkt erlaubt Einsicht fremder Bestellungen",
  "severity": "high",
  "cvss_v3_1": {
    "vector": "AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
    "score": 6.5
  },
  "affected_component": "Mironsoft_SecurityDemo/Controller/Order/ViewVulnerable.php",
  "test_type": "grey-box",
  "reproduction_steps": [
    "Als Kunde A authentifizieren",
    "GET /order/view?order_id=<Bestell-ID von Kunde B> anfragen",
    "Vollstaendige Bestelldaten von Kunde B in der Antwort beobachten"
  ],
  "evidence_reference": "evidence/PT-2026-0142-007-response.json",
  "business_impact": "Offenlegung von Namen, Adressen und Bestellinhalten fremder Kunden",
  "remediation": "Besitzverhaeltnis der Bestellung gegen die authentifizierte Kundensession pruefen, bevor Daten zurueckgegeben werden",
  "status": "open",
  "discovered_date": "2026-08-04",
  "retest_required": true
}

9. Remediation, Retest und kontinuierliche Sicherheit

Nur die konkret gemeldete Instanz einer Schwachstelle zu fixen, reicht selten aus. Teams sollten gezielt nach demselben Muster an anderen Stellen der Codebasis suchen, etwa per Grep über alle Controller, die kundenbezogene Ressourcen verarbeiten, wenn ein einzelner Controller einen fehlenden Ownership-Check hatte. Ein Regressionstest, der bei erneutem Auftreten der Schwachstelle fehlschlägt, gehört fest zur Behebung dazu, nicht nur die Behebung selbst.

Ein Retest durch dieselbe Pentest-Firma gegen den gefixten Code bestätigt, dass der Fix die Lücke tatsächlich schließt und nicht nur das Symptom verändert, und der resultierende saubere Bericht ist häufig genau das, was Compliance-Rahmenwerke und Cyberversicherungen als Nachweis verlangen. Pentest-Ergebnisse gehören in das langfristige Security-Backlog des Teams, nicht in eine einmalige Checkbox für die Compliance-Abteilung. Wiederkehrende Engagements über mehrere Jahre zeigen, ob Anzahl und Schweregrad der Findings von Release zu Release tatsächlich sinken.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Acl/etc/acl.xsd">
    <acl>
        <resources>
            <resource id="Magento_Backend::admin">
                <resource id="Mironsoft_SecuritySuite::security" title="Security Suite" sortOrder="200">
                    <!-- Eigene, eng begrenzte Ressource, damit Pentest-bezogene
                         Einstellungen nicht ueber Standard-Admin-Rollen erreichbar sind -->
                    <resource id="Mironsoft_SecuritySuite::pentest_mode"
                              title="Penetration Test Mode"
                              sortOrder="10"/>
                    <resource id="Mironsoft_SecuritySuite::findings"
                              title="Findings Register"
                              sortOrder="20"/>
                </resource>
            </resource>
        </resources>
    </acl>
</config>

10. Zusammenfassung

Penetration-Testing-Grundlagen für Entwickler-Teams lassen sich auf wenige Kernprinzipien reduzieren: Ein Pentest ist kein Ersatz für automatisierte Vulnerability Scans, sondern eine ergänzende, manuelle Prüfung, die Business-Logic-Fehler und verkettete Schwachstellen findet, die Scanner strukturell übersehen. Black-Box, Grey-Box und White-Box unterscheiden sich im Wissensstand des Testteams, wobei Grey-Box für die meisten E-Commerce-Shops den besten Kompromiss aus Realismus und Tiefe bietet. Schriftliche Autorisierung mit klarem Scope, Zeitfenster und einer tatsächlich befugten unterzeichnenden Person ist zwingend, jede Testtätigkeit ohne diese Freigabe ist unbefugter Zugriff und strafbar.

Interner Security Review und externer Pentest schließen sich nicht aus, sie ergänzen sich: kontinuierliche interne Prüfung im Alltag, periodischer externer Pentest als unabhängiger Blick von außen. Der eigentliche Wert eines Pentests entsteht erst nach dem Test, wenn Findings sauber priorisiert, mit Ownern und Fristen versehen, tatsächlich behoben und durch einen verifizierten Retest bestätigt werden, statt als PDF in der Ablage zu verstauben.

11. FAQ: Penetration-Testing-Grundlagen für Entwickler-Teams