Files
Tim Krampitz 01046b01e4 Neue Skills, Referenzen & OpenWiki-Doku integriert
Umfangreiche Erweiterung der Skill-Bibliothek: Neue Skills für Humanisierung (Englisch/PT-BR), Design-Validierung, AI-SEO und Coolify-Deployment inkl. Regelwerke, Presets, Pattern-Referenzen, Testfälle und Automatisierungsskripte. Zusätzliche Skills für Revenue-Centric Design, Pier Cloud, OKF, Lebenslauf- und LinkedIn-Optimierung sowie zahlreiche Referenzdateien, Checklisten und YAML/JSON/Markdown-Templates. Einführung einer vollständigen OpenWiki-Dokumentation mit Architektur-, Domain- und Workflow-Beschreibungen, zentralem Index und automatisierten Updates. Modularer Aufbau, restriktive Lizenzen und umfassende Qualitäts- und Evaluationsmechanismen für alle neuen Inhalte.
2026-07-26 14:00:58 +02:00

225 lines
8.5 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Penetration Testing
Active security assessment against a live target. Unlike code-only analysis, this involves running tools against actual systems — reconnaissance, scanning, exploitation attempts, and evidence collection.
**When to use:** The user has a target (domain, IP, web app URL) and wants an offensive assessment, not just source code review. This is the "attacker's perspective" workflow.
## Prerequisites
- For **localhost/dev targets**: no authorization needed — it's the user's own machine.
- For **remote/production targets**: explicit written authorization from the target owner.
- Clear rules of engagement for remote targets (scope, testing window).
- Do NOT probe remote systems without confirmation.
## Default Flow (Path + Dev)
When the user provides a codebase path without a remote URL:
1. Run SAST via `steering/full-scan.md` on the source code
2. Detect how to start the dev server:
- Look for `package.json``npm run dev` / `npm start`
- Look for `docker-compose.yml``docker compose up -d`
- Look for `Makefile``make run`
- Look for `manage.py``python manage.py runserver`
- Ask the user if unclear
3. Start the dev server, wait for it to be ready
4. Run DAST against `localhost:<port>` (phases 2-4 below)
5. Correlate: match DAST findings to source code locations from SAST
6. Stop the dev server
## Extended Flow (Path + Production URL)
When the user also provides a production URL:
1. Complete the default flow above (SAST + DAST localhost)
2. Show gate: "This will send active probes to [URL]. Authorized? [y/n]"
3. On confirmation: run DAST against production URL
4. Compare: findings present in dev but absent in prod (mitigated by infra?) and vice versa
5. Final report correlates all three layers
## Phase 1: Reconnaissance
Gather information without touching the target directly, then move to active probing.
### Passive (no direct contact with target)
```bash
python3 scripts/pentest.py recon-passive --target <domain>
```
The script runs:
- WHOIS lookup (registrar, nameservers, creation date)
- DNS enumeration (A, AAAA, MX, NS, TXT, CNAME records)
- Subdomain discovery via certificate transparency logs
- Technology fingerprinting from public sources
### Active (direct contact — requires authorization)
```bash
python3 scripts/pentest.py recon-active --target <ip_or_domain> --ports <range>
```
The script wraps:
- Host discovery (ping sweep or TCP probe)
- Port scanning (top 1000 or full 65535 based on `--ports`)
- Service version detection on open ports
- OS fingerprinting
Record all discovered hosts, ports, and services. This becomes the attack surface map.
## Phase 2: Enumeration
Dig deeper into discovered services.
### Web targets
```bash
python3 scripts/pentest.py enumerate-web --url <base_url>
```
Covers:
- Directory and file brute-forcing (common paths, backup files, admin panels)
- Subdomain enumeration (DNS brute, certificate transparency)
- Technology stack detection (frameworks, CMS, WAF identification)
- robots.txt, sitemap.xml, .well-known paths
- HTTP method testing on discovered endpoints
- Authentication mechanism identification
### Infrastructure targets
- Banner grabbing on non-HTTP services
- SMB share enumeration
- SNMP community string testing
- Default credential checks on known services
## Phase 3: Vulnerability Identification
Map discovered services to known vulnerabilities and potential attack vectors.
### Automated scanning
```bash
python3 scripts/pentest.py vuln-scan --target <url_or_ip> --type <web|infra>
```
For web targets, check OWASP Top 10:
1. **Injection** — SQLi, command injection, LDAP injection, template injection
2. **Broken Auth** — default creds, weak passwords, session fixation
3. **Sensitive Data Exposure** — cleartext transmission, backup files, source disclosure
4. **XXE** — XML entity injection in upload/API endpoints
5. **Broken Access Control** — IDOR, privilege escalation, path traversal
6. **Misconfig** — default pages, directory listing, verbose errors, CORS
7. **XSS** — reflected, stored, DOM-based
8. **Insecure Deserialization** — object injection in serialized data
9. **Known CVEs** — version-matched CVE checks against detected software
10. **SSRF** — server-side request forgery in URL parameters
### Manual testing
After automated scans, test for logic flaws that scanners miss:
- Business logic bypasses (price manipulation, workflow skipping)
- Race conditions in state-changing operations
- Chained vulnerabilities (low-severity issues combining into high-impact)
## Phase 4: Exploitation (Proof of Concept)
For each identified vulnerability, attempt controlled exploitation to confirm impact.
**Rules:**
- Minimal impact — demonstrate the bug, don't destroy data
- Document every step — screenshot, request/response, timestamp
- Stop if unexpected damage occurs
- Stay within authorized scope
Record results:
```bash
python3 scripts/scan_db.py add-finding \
--scan-id <id> \
--title "SQL Injection in /api/search" \
--severity critical \
--category injection \
--file "api/routes/search.js" \
--line 42 \
--description "Unsanitized user input in search parameter passed directly to SQL query" \
--evidence "Request: GET /api/search?q=1' OR 1=1-- Response: 200 OK with all database records"
```
## Phase 5: Post-Exploitation (if in scope)
When rules of engagement allow:
- Lateral movement mapping (what else can you reach from compromised position)
- Privilege escalation attempts
- Data access assessment (what sensitive data is reachable)
- Persistence mechanism identification (not deployment — just identifying)
## Phase 6: Reporting
```bash
python3 scripts/finalize.py --scan-dir .security
```
The pentest report adds to the standard report format:
| Section | Content |
|---------|---------|
| Executive Summary | Business impact in non-technical language |
| Scope | Authorized targets, testing window, methodology |
| Attack Narrative | Chronological story of the assessment |
| Findings | Sorted by severity with full reproduction steps |
| Evidence | Screenshots, request/response dumps, tool output |
| Remediation | Prioritized fix recommendations with effort estimates |
| Positive Observations | What's working well (defenders need wins too) |
## Severity Rating
Follow `references/severity-policy.md`, but with CVSS alignment for pentest context:
| Severity | CVSS Range | Pentest Context |
|----------|-----------|-----------------|
| Critical | 9.010.0 | RCE, full auth bypass, mass data exfil, supply chain |
| High | 7.08.9 | SQLi with data access, stored XSS + session theft, priv esc |
| Medium | 4.06.9 | Reflected XSS, info disclosure, missing security controls |
| Low | 0.13.9 | Missing headers, version disclosure, theoretical issues |
| Info | — | Best practices, hardening suggestions, architecture notes |
## Tools Reference
The `scripts/pentest.py` script wraps system tools when available and falls back to Python alternatives.
### Tool Matrix
| Function | System Tool | Python Alternative (pip) | Stdlib Fallback |
|----------|------------|--------------------------|-----------------|
| Port scanning | `nmap` | `python-nmap` or `python3-nmap` | `socket` connect scan |
| DNS enumeration | `dig`, `host` | `dnspython` | `socket.getaddrinfo` |
| WHOIS lookup | `whois` | `python-whois` | crt.sh HTTPS query |
| Subdomain enum | `subfinder`, `amass` | `bbot` | crt.sh CT log query |
| Dir brute-force | `gobuster`, `feroxbuster` | `dirsearch` | `urllib` common-path check |
| Tech detection | `whatweb`, `wappalyzer` | `builtwith`, `webtech` | HTTP header analysis |
| Web vuln scan | `nikto` | `wapiti3` | Manual checks |
| Template scan | `nuclei` | `wapiti3` (module-based) | Header/config checks |
| SQL injection | `sqlmap` | `sqlmap` (is Python) | Parameter probing |
| XSS detection | — | `wapiti3`, `xsser` | Reflected input check |
| OSINT recon | `theHarvester` | `theHarvester` (is Python) | Search API queries |
| HTTP proxy | `burpsuite`, `mitmproxy` | `mitmproxy` (is Python) | — |
### Installation
```bash
# Minimal (covers most use cases)
pip install dnspython python-whois requests
# Full pentest stack
pip install dnspython python-whois python3-nmap wapiti3 dirsearch bbot webtech mitmproxy
```
### Priority Order
The script tries tools in this order:
1. **System binary** (fastest, most features) — e.g., `nmap` on PATH
2. **Python pip package** (portable, no root needed) — e.g., `python3-nmap`
3. **Stdlib fallback** (always works, limited) — e.g., `socket` scan
If nothing external is available, the stdlib fallback still produces useful results — just slower and less comprehensive.