de3bed10ba
🚨 Severity: MEDIUM 💡 Vulnerability: Information Exposure (CWE-209) - The web dashboard returned raw exception messages to users, potentially leaking internal details (stack traces, file paths, sensitive info). - This violated the principle of "Fail Securely". 🎯 Impact: - Attackers could glean information about the internal file structure or database errors to facilitate further attacks. 🔧 Fix: - Configured `logging` to capture errors securely to stderr (standard practice for containerized apps). - Updated `dashboard()` and `get_cached_markdown` to log the full exception traceback server-side. - Changed user-facing response to a generic "Internal Server Error" (500). ✅ Verification: - Added unit test `test_dashboard_error_handling` in `scripts/test_web_dashboard.py`. - Verified that the test passes: `python scripts/test_web_dashboard.py`. - Confirmed that the response body contains "Internal Server Error" and does NOT contain the mock secret.
1.5 KiB
Sentinel's Journal
2026-02-07 - Telegram Bot Authorization Bypass
Vulnerability: The Telegram Deployment Bot (scripts/telegram_deploy_bot.py) contained a "Fail Open" vulnerability where omitting the TELEGRAM_ALLOWED_USER_IDS environment variable resulted in granting access to all Telegram users instead of none.
Learning: Security controls must default to deny (Fail Closed). Implicitly allowing access when configuration is missing creates silent vulnerabilities that are hard to detect until exploited.
Prevention: Ensure all authorization checks explicitly return False or throw an exception if the access control list is empty or undefined. Never default to True in security-critical paths.
2026-02-13 - [Documentation] Cloudflare Nameservers and Domain Unification
- Updated Cloudflare nameservers to daisy.ns.cloudflare.com and rocco.ns.cloudflare.com.
- Unified domain name to lengkundee01.org across CNAME and PWA documentation.
2026-02-22 - Information Exposure in Web Dashboard
Vulnerability: The Web Dashboard (scripts/web_dashboard.py) directly returned raw exception messages to users (return f"Error: {str(e)}", 500), potentially leaking sensitive internal details (stack traces, file paths, database errors).
Learning: Development-style error reporting was left in production-facing code.
Prevention: Always use a generic error message for user-facing responses (e.g., "Internal Server Error") and log the specific exception details securely to stderr or a log file using logging.