This document describes the security analysis performed on Cronmanager, mapping findings to OWASP Top 10 (2021) and other industry standards. It covers the controls already implemented and the residual risks with recommended next steps.

For the overall security architecture see TECHNICAL.md – Security Model.

1. Scope
2. Threat Model
3. OWASP Top 10 (2021) Mapping
4. Findings and Status
   • A01 – Broken Access Control
   • A02 – Cryptographic Failures
   • A03 – Injection
   • A05 – Security Misconfiguration
   • A06 – Vulnerable and Outdated Components
   • A07 – Identification and Authentication Failures
   • A09 – Security Logging and Monitoring Failures
5. Additional Controls Implemented
6. Residual Risks and Recommendations
7. Security Checklist

The analysis covers:

Risk: An authenticated viewer could access admin-only pages (user management, cron create/edit/delete).

Root cause: Routes are registered with an optional minimum-role parameter. Before the fix, templates checked $user['role'] === 'admin' using a template variable that could be overridden by sub-templates (e.g., detail.php sets $user as a string for an unrelated purpose, leaking into the layout scope).

Fix applied (web/templates/layout.php):

• All admin navigation visibility checks replaced with SessionManager::hasRole('admin'), which reads directly from the authenticated session rather than a possibly polluted template variable.
• The Router (Router.php) enforces the role on every request before dispatching.

Verification: Every protected route calls SessionManager::hasRole($requiredRole) server-side. Template role checks are defence-in-depth only (UI hiding, not access control).

Risk: An admin user could accidentally (or maliciously) demote or delete their own account, leaving the system without an administrator.

Fix: UserController rejects requests where the target user ID equals the currently logged-in user ID with HTTP 403.

Risk: A malicious page could silently trigger cron creation, deletion, or user role changes on behalf of an authenticated user (Cross-Site Request Forgery).

Fix applied:

• SessionManager::getCsrfToken() generates a 64-character cryptographically random hex token (bin2hex(random_bytes(32))) stored in the session on first access.
• SessionManager::validateCsrfToken(string $submitted): bool compares with hash_equals() to prevent timing attacks.
• Router::dispatch() validates $_POST['_csrf'] for all POST, PUT, PATCH, and DELETE requests on protected routes.
• All POST forms in templates include <input type="hidden" name="_csrf" value="<?= $csrf_token ?>">.
• BaseController::render() automatically injects csrf_token into every template data array.

Note on public POST routes: The login and setup forms (POST /login, POST /setup) are not behind the router's CSRF check because they cannot rely on a pre-authenticated session token. Their CSRF risk is lower: a forged login at worst logs the attacker in as themselves, and setup is a one-time event. Nonetheless, the forms include the CSRF field for consistency and defence-in-depth.

Risk: Passwords stored in recoverable form.

Implementation: LocalAuthProvider uses PHP's password_hash() with PASSWORD_BCRYPT (or PASSWORD_ARGON2ID where available, depending on configuration). password_verify() is used for all comparisons. Plaintext passwords are never written to logs or databases.

Risk: Weak or default HMAC secrets allow request forgery between the web container and the host agent.

Fix applied (web/index.php, agent/agent.php):

• At startup, the application checks the configured hmac_secret.
• If it is empty or equals the example placeholder (change-me-to-a-secure-random-string), a CRITICAL log entry is emitted.
• If it is shorter than 32 characters, a WARNING is emitted.
• The recommended generation command (openssl rand -hex 32) is included in both the log message and the configuration example.

Risk: Authorization code interception.

Implementation: OidcAuthProvider generates a cryptographically random PKCE code_verifier (64 bytes, base64url-encoded), computes code_challenge = BASE64URL(SHA256(code_verifier)), and stores both verifier and state in the PHP session. Both are verified before the token exchange.

Risk: HTTP between components exposes credentials or commands.

Status / recommendation:

• Browser → Web UI: HTTPS should be configured at the reverse-proxy / Docker ingress level. The application itself does not handle TLS termination.
• Web container → Host agent: Uses HTTP. The exposure depends on the deployment mode:
  • Host-agent mode: The web container reaches the agent via host.docker.internal (Docker bridge to the host's loopback interface, not externally routable).
  • Docker mode (file-mounted source): Traffic stays on the private cronmanager-internal Docker network and never leaves the host.
  • Docker Hub mode (docker-compose-full.yml): All three services (web, agent, MariaDB) share a private named Docker network; web→agent traffic is container-to-container and never leaves the host.
  • In all cases the HMAC signature ensures integrity and authenticity of requests even without TLS on this internal hop.
• Recommendation: Add TLS to the host agent listener for defence-in-depth if the Docker network is shared with untrusted containers.

Risk: Attacker-controlled data interpolated into SQL queries.

Implementation: Every database interaction uses PDO prepared statements with named placeholders. No raw string concatenation occurs in SQL queries anywhere in the codebase.

Risk: Cron job command fields are written verbatim into system crontabs.

Context: Cronmanager's purpose is to manage arbitrary system commands. Only authenticated admin users can create or edit jobs. The host agent writes commands to crontab files; it does not eval or exec them — the cron daemon interprets them.

Controls in place:

• Only admin-role users can create or modify cron job commands (role enforcement, A01).
• The HMAC-secured channel prevents un-authenticated writes to the agent.
• cron-wrapper.sh runs as the crontab owner (not root by default).

Recommendation: Consider a UI-level allowlist or regex validation on the command field to prevent accidental typos with dangerous shell constructs (e.g., ; rm -rf /).

Risk: Stored cron job descriptions or user input rendered as raw HTML.

Fix: All dynamic output in PHP templates passes through:

htmlspecialchars($value, ENT_QUOTES, 'UTF-8')

Verified across all template files. No echo $variable without escaping exists.

Risk: Missing security headers allow clickjacking, MIME sniffing, and XSS escalation.

Fix applied (web/index.php, sent before any output):

CSP value:

default-src 'self';
script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
font-src 'self';
connect-src 'self';
frame-ancestors 'none'

Known limitation: 'unsafe-inline' for scripts is required because the Tailwind dark-mode detection snippet and tailwind.config block are inline <script> elements in layout.php. For a stricter CSP, these should be extracted to external files and a nonce-based CSP applied. This is a recommended future improvement but does not represent a critical risk in a homelab deployment model.

See Finding 2.2 (startup HMAC secret validation).

Additional control: The deploy.env.example and config.json.example files explicitly contain placeholder values. The deployment script prints a reminder to update secrets after a full deployment.

Risk: Stack traces or internal paths exposed in HTTP responses.

Implementation: The top-level catch block in index.php logs full exception details via Monolog but returns only a generic "500 – Internal Server Error" page to the browser. PHP error display (display_errors) must be set to Off in php.ini for production — this is a deployment configuration requirement, not enforced by the application code.

Status: Automated – composer audit --no-dev runs in CI on every push.

The application uses the following third-party libraries (via shared /opt/phplib/vendor/):

Automated control: composer audit --no-dev is executed on every push and pull request via the dependency-audit job in .github/workflows/security.yml. The job fails (blocking CI) if any production dependency has a known CVE or PHP Security Advisory. Dev-only dependencies (PHPUnit, Mockery, etc.) are excluded.

Recommendations:

1. Pin minor versions in composer.json and update deliberately with testing.
2. Subscribe to security advisories for the listed packages.

Risk: Brute-force or credential-stuffing attacks against the login form.

Fix applied (web/src/Session/SessionManager.php, web/src/Controller/AuthController.php):

• Per-IP tracking with hash('sha256', $ip) as the session key (no plaintext IP in session data).
• Threshold: 5 failed attempts.
• Lockout duration: 15 minutes (configurable via RATE_LOCK_SECONDS).
• On lockout: HTTP redirect to /login with a flash message showing remaining minutes.
• Rate tracking is stored in the PHP session.

Known limitation: Session-based rate limiting is scoped to a single PHP session. An attacker using a fresh browser (new session) or different IPs bypasses the counter. For production hardening, use a shared store (APCu, Redis, or a database table) keyed by IP address.

Risk: Timing or error message differences reveal whether a username exists.

Fix applied:

• Failed login always returns the same flash error key (login_error_credentials) regardless of whether the username was found or the password was wrong.
• Failed login logs hash('sha256', $username) instead of the plaintext username, so log analysis cannot enumerate valid usernames from the log file.

Risk: An attacker pre-sets a known session ID before login.

Implementation: SessionManager::login() calls session_regenerate_id(true) immediately after successful authentication, invalidating the old session and preventing fixation.

Implementation: SessionManager::start() sets the following before session_start():

Risk: External callers accessing the REST API without adequate authentication or with overly broad permissions — equivalent to granting unconstrained admin access to scripts.

Implementation (src/Auth/ApiKeyMiddleware.php, src/Auth/ApiKeyRepository.php):

• Key format: cm_ prefix + 40 cryptographically random URL-safe base64 characters (random_bytes(30)). The cm_ prefix makes leaked keys identifiable.
• Storage: Only sha256(plain_key) is stored in the database. The plain-text key is shown exactly once in the UI and cannot be recovered. Leaking the database does not expose usable keys.
• Scope-based least-privilege: Each key is granted a minimal set of the 8 available scopes. A read-only key has no write or execute access even if the creating user is an admin.
• Scope inheritance: A user can only grant scopes their own role permits (view-users may not grant jobs:write, maintenance:write, settings:write, or settings:read).
• IP whitelist: Optional CIDR-notation allowlist enforced by ApiKey::isIpAllowed() using inet_pton bit-comparison. Requests from unlisted IPs receive HTTP 403.
• Expiry: Optional expires_at; expired keys receive HTTP 401.
• Non-blocking last_used_at: Updated via register_shutdown_function() so the timestamp is recorded without adding latency to the API response.
• No session, no CSRF: The API is fully stateless. Cookie-based CSRF does not apply; the Authorization header is the only credential.
• HMAC separate concern: The HMAC channel is between the web container and the internal agent — it is invisible to and independent of external API callers.

Residual risk: A stolen API key grants access until it is revoked or expires. There is no automatic revocation on suspicious usage patterns. Mitigation: use narrow scopes, short expiry dates, and IP whitelists for keys used by automated scripts.

Events logged via Monolog:

Log configuration: RotatingFileHandler with a configurable path (default /opt/cronmanager/agent/log/cronmanager-agent.log (agent) and /var/www/log/cronmanager-web.log (web)) and 30-day retention. Log level is configurable (default DEBUG in development, should be WARNING or higher in production).

Since v4.0.0 a dedicated GitHub Actions workflow (.github/workflows/security.yml) runs on every push and pull request with two parallel jobs:

composer audit --no-dev

Checks all production Composer dependencies against the PHP Security Advisories database. Fails when any installed package version has a known CVE. Dev dependencies are excluded.

OWASP coverage: A06 – Vulnerable and Outdated Components

semgrep scan --config p/php --config p/owasp-top-ten --error .

Semgrep OSS with two rule sets from the public Semgrep Registry:

OWASP coverage: A01 (access control, path traversal), A02 (weak crypto, hardcoded secrets), A03 (SQL/command/XSS injection), A07 (auth failures), A10 (SSRF)

The job fails on any finding (--error). Excluded paths are listed in .semgrepignore (vendor/, tests/, compiled frontend assets, SQL migrations).

Suppressing a false positive per line:

exec($bgCmd . ' &'); // nosemgrep: php.lang.security.exec-use.exec-use

Optional: set the SEMGREP_APP_TOKEN repository secret (free semgrep.dev account) to enable full Registry access and upload findings to the Semgrep dashboard for trend tracking over time.

The following controls were added that do not map directly to a single OWASP category but represent security best practices:

The following items are known limitations or recommended improvements that were not addressed in this iteration. They are ordered by priority.

Use this checklist when deploying a new instance or reviewing after changes.

• Generated a fresh HMAC secret (openssl rand -hex 32) in agent and web config
• Changed database passwords from example values
• Set DEPLOY_TYPE and SSH host in deploy.env
• Verified php.ini has display_errors = Off and expose_php = Off
• TLS/HTTPS configured at the ingress level (reverse proxy, nginx, Caddy, etc.)

• Confirm first-run setup created the admin account and /setup redirects to /login
• Confirm Monolog is writing to the configured log path
• Confirm log file is not world-readable
• Test login rate limiting: 6 consecutive failed logins should lock the IP
• Test CSRF: submitting a form without _csrf field returns 403
• Test role enforcement: viewer account cannot access /users, /crons/new, etc.
• Confirm GitHub Actions security workflow passes (dependency-audit + semgrep green)

• Review log files for unusual patterns (mass failed logins, CSRF failures, 403s)
• Update Composer dependencies and re-run composer audit (also enforced by CI)
• Rotate HMAC secret (update both agent config and web config; restart agent service)
• Review user accounts and remove stale accounts
• Review API keys under /api-keys: revoke keys that are no longer needed, check last_used_at for stale keys, verify scope assignments are still appropriate
• Rotate long-lived API keys used by automated scripts

Analysis performed: 2026-03-18; last updated: 2026-06-22 (v4.1.0 – external REST API key authentication) Analyst: Christian Schulz technik@meinetechnikwelt.rocks