Add audit reports and fix plan for DevTrack #1259

2026-06-25 10:26:46 -04:00
parent 231e70b942
commit 02e83eb140
3 changed files with 161 additions and 0 deletions
@@ -0,0 +1,62 @@
+---
+agent: code-auditor
+status: COMPLETE
+timestamp: 2026-06-25T10:20:00Z
+duration_seconds: 120
+files_scanned: 4
+findings_count: 6
+errors: []
+skipped_checks: []
+---
+
+# Code Audit
+
+## Files Scanned
+- `modules/phishing/lander_gen.py` (103 lines)
+- `modules/phishing/deploy_phishing.py` (574 lines, focused: L157-185, L417-424, L445-446)
+- `modules/phishing/templates/cloud-lander.html.j2` (31 lines)
+- `modules/phishing/templates/js-payload.js.j2` (11 lines)
+
+## Findings
+
+### HIGH
+- [lander_gen.py:25-90] `post_deploy_generate_lander()` uses `print()` calls (11 instances, L62-89) in production code. Should use logging or Rich for consistency with c2itall pattern.
+- [cloud-lander.html.j2:14] Magic number `20` hardcoded in `makeRandomSub(20)` for random subdomain prefix length. Should be a configurable constant; if log-harvesting becomes a threat, this will need per-request rotation and the number may change.
+
+### MEDIUM
+- [lander_gen.py:66-76] Duplicate provider-specific logic pattern. GCS, S3, and Azure blocks each construct `public_url` and `upload_cmd` independently. Same operation (URL + command generation) duplicated 3 times with 5+ line similarity each. Extract to a dict-driven pattern or helper to reduce duplication.
+- [deploy_phishing.py:164-184] Nesting depth of 5 levels in lander prompt block (if → if → if → if → if). Input validation and conditional chain is difficult to follow; consider early returns or extracting to a dedicated validation function.
+- [cloud-lander.html.j2:13] Hardcoded character set `'abcdefghijklmnopqrstuvwxyz0123456789'` used in random subdomain generation. If character set requirements change (e.g., exclude vowels to avoid accidental offensive domains), this will need updating in multiple places.
+
+### LOW
+- [lander_gen.py:87] Comment references "ponytail: fixed JS filename visible in webserver logs" but does not state the upgrade path. Per ponytail rules, shortcut ceilings should name when to upgrade (e.g., "upgrade to per-RId rotation if log-harvesting becomes a threat"). Current comment is incomplete.
+- [deploy_phishing.py:445-446] Inline import of `post_deploy_generate_lander` inside success block. While intentional (lazy load post-deploy), this is not consistent with module-level imports at the top of the function. Consider moving to the top for clarity or add a comment explaining the late binding reason.
+
+## Stats
+- print() calls: 11 (lander_gen.py L62-89, deploy_phishing.py L158-184)
+- TODO/FIXME/HACK: 0
+- Files >500 lines: 1 (deploy_phishing.py)
+- Functions >50 lines: 0
+- Max nesting depth: 5 (deploy_phishing.py L164-184)
+- Cyclomatic complexity: 2 (within acceptable range)
+- Dead code: None detected
+- Duplicate logic blocks: 1 (provider URL/command generation)
+
+## Notes
+
+### Code Quality Observations
+
+**Strengths:**
+- Input validation at trust boundaries is solid (HTTPS enforcement, campaign ID regex)
+- No unused imports
+- Clean separation of concerns (lander_gen.py as pure generation, deploy_phishing.py as orchestration)
+- Syntax is valid across all files
+
+**Complexity:**
+- The lander prompt block in deploy_phishing.py (L164-184) has legitimate nesting due to cascading user input validation, but would benefit from extraction to reduce cognitive load.
+- File sizes are within healthy range (largest is 574 lines, acceptable for a deployment orchestrator).
+
+**Style:**
+- Consistent use of COLORS dict for output (good adherence to c2itall pattern)
+- Template Jinja2 syntax is correct and minimal
+