A09 — Security Logging & Monitoring Insecure

1000-ft view: these examples show what goes wrong when logs are missing, unstructured, leak secrets, use bad timestamps, never trigger alerts, or are easy to tamper with. Outputs write to demo files under /a09_logging/logs.

Attack 1 Attack 2 Attack 3 Attack 4 Attack 5

Attack 1 — Auth & Privileged Action Events

missing/low-value logs

Why it’s bad: either nothing gets logged or the log lines are so vague you can’t tie events together (no user/IP/outcome, no correlation id).

  1. Submit a login — insecure endpoint logs nothing or a useless string.
  2. Trigger an admin action — again, no meaningful audit trail.

Attack 2 — Sensitive Data in Logs

plaintext secrets/PII

Why it’s bad: passwords, tokens, and full SSNs get dumped into logs in cleartext, which are often widely accessible to operators or shipped to third parties.

  1. Submit the form — the insecure endpoint writes secrets directly to app.log.

Attack 3 — Structure & Timestamps

free-form + local time

Why it’s bad: inconsistent formats and local timestamps make SIEM rules brittle and multi-region correlation nearly impossible.

  1. Write a free-form line to app.log with local time and ad-hoc fields.

Attack 4 — Thresholded Alerts

no alerting

Why it’s bad: repeated failures never trigger alerts; brute-force and abuse fly under the radar.

  1. Send many “failed” events — insecure endpoint never emits to alerts.log.

Attack 5 — Log Integrity

plain text • no chain

Why it’s bad: anyone with file access can delete or edit lines in place — there’s no signature, no chain, no tamper evidence.

  1. Append a plain line to app.log (no signature).
  2. There’s no way to prove it hasn’t been altered.