Security Scanner Workbench

Security Scanner Workbench (SSW) ist eine lokale, Podman-basierte Security-Assessment- und DAST-Workbench für autorisierte Web- und Infrastrukturtests. Sie verbindet Recon, Discovery, URL-/Target-Management, Authentisierung, Schwachstellen-Scanner, Findings und Reporting in einer Desktop-Oberfläche.

Aktuelle Version: 0.9.7

TLS-Zertifikatsprüfung

Für HTML/Login-Analyse und Form-Login stehen drei Modi bereit: normale Zertifikatsprüfung, eigene interne CA oder bewusstes Zulassen von Self-signed/ungültigen Zertifikaten für autorisierte Testziele. Details: docs/TLS_POLICY.md.

Nur Systeme scannen, für die eine ausdrückliche Berechtigung besteht. Aktive und invasive Scanner können Anwendungen und Infrastruktur belasten.

Highlights 0.9.7

• Katana Multi-Target korrigiert: URL-Dateien werden mit -list statt als einzelnes -u-Ziel übergeben.

• Katana Login-Analyse mit hartem Timeout: Live-Logging bleibt erhalten, hängende Katana/Chromium-Prozesse werden zuverlässig beendet.

• Kompletter Form-Login Cookie-Jar: Session-, CSRF-, Load-Balancer- und weitere Cookies werden gemeinsam an Scanner weitergegeben.

• Login-Analyse startet ohne bestehende Form-Session: Bearer-/Custom-Header bleiben erhalten, Login-Cookies werden für die Formularanalyse bewusst entfernt.

• Container-Mount-Contracts: automatisierte Tests prüfen, dass dateischreibende Scanner ein vorhandenes beschreibbares Host-Mount erhalten; GAU/Katana behalten Rootless-keep-id.

• persistenter Target Pool pro Zielsystem

• Katana/gau/ffuf-Ergebnisse können in späteren Läufen wiederverwendet werden

• Button Nur neue Targets scannen mit scanner-spezifischer Historie

• URL-Filter: Maximalmenge, Max/Host, Include-/Exclude-Regex, statische Assets, Query-Parameter

• Target-Pool-Editor: URLs hinzufügen, aktivieren, deaktivieren und löschen

• scanner-spezifische Target-Aufbereitung:

  • Nikto → deduplizierte Base-URLs
  • Dalfox/SQLMap → nur parameterisierte URLs
  • Nuclei/httpx → gefilterte URL-Liste

• echte Profile Quick / Standard / Deep / Authenticated / Custom

• Profile definieren Scanner-Auswahl und Last-/Tuning-Parameter

• aktualisierte Pipeline-Ansicht und Scanner-Hilfe

• GitHub Actions, Issue Templates und Pull-Request-Template

Pipeline

Phase 0: Recon
Subfinder -> dnsx -> tlsx -> Naabu
                       |
                 httpx Recon
                       |
Phase 1: Discovery     v
             Katana + gau + ffuf
                       |
                 URL Merge
                       |
              Persistent Target Pool
                       |
             Filter / Limit / Scope
                       |
                httpx Verify
                       |
Phase 2/3: Assessment  v
       Nuclei / Nikto / ZAP / testssl
              Dalfox / SQLMap*
                       |
             Findings / Reporting

* SQLMap ist bewusst nicht Bestandteil eines automatischen Standard-/Deep-Profils.

Die Pipeline ist nicht an einen einzelnen Scanlauf gebunden. Ein typischer Ablauf kann daher sein:

Tag 1: Katana -> 2'400 URLs -> Target Pool
Tag 2: Target Pool -> Filter -> 12 Nikto Base-Targets
Tag 3: Nur neue Targets -> Nuclei/Dalfox

Details: docs/TARGET_POOL.md

Scanprofile

Profil	Einsatz	Last	Verhalten
Quick	Smoke-/Entwickler-Check	niedrig	kleine Discovery, niedrige Rate, wichtige Findings
Standard	regulärer Security-Test	mittel	ausgewogene Recon-, Web- und TLS-Prüfung
Deep	geplante Tiefenanalyse	hoch	breitere Ports/Discovery, ffuf und ZAP Full
Authenticated	Anwendungen mit Login/Session	mittel	web-orientierter Scanner-Satz mit zentraler Auth
Custom	eigener Testplan	frei	Scanner-Auswahl wird nicht automatisch verändert

Ein Profilwechsel aktiviert den dazu vorgesehenen Scanner-Satz. Custom ist die Ausnahme und respektiert die aktuelle manuelle Auswahl.

Details: docs/PROFILES.md

Integrierte Scanner

Phase 0 – Attack Surface Recon

• Subfinder
• dnsx
• tlsx
• Naabu

Phase 1 – Discovery

• Katana
• gau
• ffuf

Phase 2 – Vulnerability Scanning

• ProjectDiscovery httpx
• Nuclei
• Nikto
• OWASP ZAP
• testssl.sh
• Dalfox

Phase 3 – Special Targets & Secrets

• WPScan
• TruffleHog
• GoTestWAF
• SQLMap

Die vollständige operative Hilfe pro Scanner steht unter docs/SCANNER_HELP.md und in der GUI unter Hilfe.

Target Pool

Discovery-Ergebnisse werden pro Target unter data/target-pools/ persistiert. Dieser Runtime-Inhalt ist über .gitignore vom Repository ausgeschlossen.

Unter Target Pool kann der Benutzer:

• alle bekannten URLs sehen
• Quelle und bereits verwendete Scanner sehen
• URLs manuell hinzufügen
• Targets aktivieren/deaktivieren
• Targets löschen
• direkt Nur neue Targets scannen starten

Unter Targets stehen die Filter:

• Max. URLs
• Max. pro Host
• statische Dateien ausschliessen
• Include Regex
• Exclude Regex
• nur Query-Parameter

0 bei einem Mengenlimit bedeutet unbegrenzt.

Nur neue Targets

Die Historie ist scanner-spezifisch. Eine URL kann beispielsweise für Nuclei bereits verarbeitet sein, für Dalfox aber weiterhin neu sein. Ein Target wird erst nach einem Scanner-Prozess mit Exit-Code 0 als verarbeitet markiert.

Scope & Safety

Discovery-Ergebnisse werden vor der Weitergabe erneut gegen die Scope-Allowlist geprüft. Eine leere Allowlist bedeutet standardmässig: Target-Host und dessen Subdomains.

Externe Redirect-/Discovery-Ziele können blockiert werden. Zertifikats-SANs, passive Archivquellen und Crawling-Ergebnisse werden nicht als automatische Berechtigung interpretiert.

Zielbelastung

Die Workbench setzt Last nicht nur über einen globalen Schalter, sondern über Profile und scanner-spezifische Parameter wie:

• Naabu Rate
• httpx Rate Limit
• Katana Concurrency / Parallelism / Rate Limit
• Nuclei Rate Limit / Concurrency
• ZAP Request Delay
• gau Threads
• Dalfox Worker / Delay
• SQLMap Level / Risk / Threads

Die Profile sind konservativ abgestuft. Deep sollte auf produktiven Systemen nur in einem geeigneten Testfenster verwendet werden.

Authentisierung

Die Authentication-Seite unterstützt:

• Form Login
• automatische Hidden-/CSRF-Felderkennung
• Session-Cookie-Erhaltung
• Bearer Token
• Custom Header
• Login Inspector
• Katana Form Extraction

Secrets werden in Dry Run, commands.log und Run-Metadaten maskiert.

Architektur

ssw/
├── core/
│   ├── orchestrator.py       # Phase 0-3 und Pipeline-Handoffs
│   ├── target_pool.py        # persistente URL-Ziele, Filter, Scan-Historie
│   ├── discovery.py          # Host/Port/URL-Artefakte
│   ├── process_runner.py     # subprocess lifecycle
│   ├── command_mask.py       # Secret-Maskierung
│   ├── scope.py              # Scope/Safety
│   ├── findings.py           # Normalisierung
│   └── report.py             # HTML Assessment Report
├── scanners/                 # scanner-spezifische Command Builder
├── gui/                      # Tkinter UI / Adapter
├── profiles/                 # Quick/Standard/Deep/Auth/Custom
└── tests/                    # Core-, Parser- und Pipeline-Tests

Die Orchestrierung ist Tk-unabhängig. Die GUI ist ein Adapter auf die Core-Schicht.

Podman Netzwerkmodell

Scanner laufen bewusst mit --network=host, damit interne DNS-Zonen, .local-Targets und Lab-Netze zuverlässig erreichbar sind. Das reduziert die Container-Netzwerkisolation und macht Scope-Control besonders wichtig.

Installation

Voraussetzungen:

• Linux
• Python 3.10+
• Tkinter
• Podman

Schnellstart:

chmod +x start.sh
./start.sh

Manuell:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python app.py

Diagnose:

./diagnose.sh

Tests

pytest -q
python -m compileall -q ssw
bash -n start.sh
bash -n diagnose.sh

GitHub Actions führt pytest mit Python 3.10 und 3.12 aus.

Repository / Runtime-Daten

Nicht versioniert werden unter anderem:

.venv/
runs/*
reports/*
data/target-pools/*.json
*.log
.env

Damit landen Scanresultate, Targets und lokale Laufzeitdaten nicht versehentlich im Git-Repository.

Ergebnisse

Jeder Scan erhält ein eigenes Run-Verzeichnis unter runs/. Je nach Scanner entstehen dort Rohdaten, normalisierte Findings, run-summary.json, commands.log, Console-Log und ein HTML Assessment Report.

Dokumentation

• docs/SCANNER_HELP.md – Scanner-Referenz, Last, Einsatz und Pipeline-Rolle
• docs/TARGET_POOL.md – persistente Targets und „nur neue Targets“
• docs/PROFILES.md – Quick/Standard/Deep/Custom
• docs/ROADMAP.md – Weiterentwicklung
• CONTRIBUTING.md – Beiträge
• SECURITY.md – Security Policy
• CHANGELOG.md – Versionshistorie

Responsible Use

Die Workbench ist für autorisierte Security-Tests gedacht. Insbesondere Portscans, Fuzzing, aktive ZAP-Scans, Dalfox und SQLMap können relevante Last oder zustandsverändernde Requests verursachen. Scope, Testfenster und Profil müssen zum Zielsystem passen.

License

Apache-2.0. Siehe LICENSE.

Entwicklerdokumentation

• Architektur
• Target Pool
• Profile
• TLS Policy
• Roadmap