Skip to content

SECURITY.md

Latest commit

 

History

History
62 lines (44 loc) · 3.29 KB

SECURITY.md

File metadata and controls

62 lines (44 loc) · 3.29 KB
Raw

Security Policy

Reporting a vulnerability

Please report security issues privately, not as a public issue.

Use GitHub's private vulnerability reporting on this repository: Security → Report a vulnerability (https://github.com/jmpsec/mapctf/security/advisories/new).

Include what you can — affected version or commit, configuration, reproduction steps, and impact. You will get an acknowledgement as soon as the report is seen. Please give us a chance to ship a fix before disclosing publicly.

Supported versions

MapCTF has not yet reached a stable release. Only the latest tagged release and the main branch receive security fixes.

Scope and expectations

MapCTF is young software intended for running CTF competitions and cyber ranges. Some hardening that a mature platform would have is not implemented yet, and these are known gaps rather than vulnerabilities:

  • Rate limiting on login and registration is in-process, so limits are per instance rather than per cluster, and it keys on the client IP from X-Forwarded-For/X-Real-Ip. Deploy behind a reverse proxy that overwrites those headers; without one a client can spoof them and evade the limit.
  • The session cookie is always marked Secure, so the platform must be served over HTTPS.
  • The mapctf-api service is experimental and not required to run a competition. It has no stability promise. If you expose it, set a strong jwt.secret.

Reports about these are still welcome — especially concrete exploitation paths — but they are tracked as roadmap items rather than as embargoed vulnerabilities.

What we would very much like to hear about:

  • Anything that lets a player read a flag they have not solved, or score without submitting a correct flag.
  • Anything that lets a non-admin reach an admin route or mutate competition state.
  • Authentication or session handling flaws, including privilege escalation between teams or instances.
  • Data exposure across instances (MapCTF namespaces all data by map.uuid).

What is protected

For completeness, since these are commonly asked about:

  • CSRF. The session cookie is SameSite=Lax, so a cross-site POST does not carry it. On top of that, every state-changing request must present a per-session token in an X-CSRF-Token header. The token is held server-side in the session and mirrored into a readable cookie for the page's scripts, so an attacker who can set cookies still cannot choose a valid token. It is rotated when you log in.
  • Passwords are bcrypt at the library default cost, and generated admin passwords use crypto/rand.
  • Sessions are renewed on login (no session fixation), HttpOnly, and destroyed on logout.
  • Admin routes are gated by an explicit admin check, not merely by authentication.

Operator guidance

Running a competition safely:

  • Serve MapCTF over HTTPS. The session cookie is Secure, so plain HTTP logins will not work.
  • Set a stable, non-guessable map.uuid. It namespaces every route and all game data.
  • Set a strong jwt.secret if you enable service.auth: db or expose mapctf-api.
  • Do not use a predictable admin password. Omit -p from create-admin-user and a strong random password is generated and printed for you.
  • Keep the database and Redis on a private network. Neither should be reachable from competitors.