CySCA 2014: four web challenges from an Australian student CTF
2014年澳大利亚信息安全挑战 CySCA CTF 官方 Web 题解
CySCA is an annual cyber-security competition for Australian university students. The 2014 web track included four challenges, each built around a web-security weakness that is still common in production applications today.
Trusting a client-supplied flag
The first challenge gated a page behind a cookie value that marked whether the current user held elevated access. Because the application trusted that cookie's value outright rather than verifying it server-side against an authenticated session, changing the value in the browser was enough to unlock the restricted page.
Markdown-rendered cross-site scripting
A comment field stripped quotes and HTML-escaped angle brackets, blocking straightforward script injection, but still rendered a markdown-style link syntax. The link's display text was not subject to the same escaping before being inserted into the page, so a crafted link label executed as script when the comment was viewed, a reminder that any lightweight markup renderer is a second attack surface alongside the main HTML sanitiser.
SQL injection behind a CSRF token
A comment-deletion endpoint validated a rotating CSRF token before processing its real parameters, which normally makes automated fuzzing difficult because each request needs a fresh, valid token. Capturing and reusing a token automatically as part of the request flow let standard SQL-injection tooling work through the parameter behind the token check, uncovering a classic unsanitised-input flaw once the CSRF layer was handled.
Forging a signature with hash length extension
An internal API authenticated requests with a signature computed as a hash of a secret concatenated with the request parameters. Hash functions built this way are vulnerable to length extension: because the internal state of many hash algorithms after processing a message is itself enough to continue hashing further data, an attacker who knows a valid signature and the length of the secret (or who is willing to try a small number of likely lengths) can compute a new, valid signature for the original parameters plus arbitrary attacker-chosen parameters appended, without ever learning the secret itself. That let the challenge be solved by appending a request to read a different, sensitive file to an already-signed request.
Why it matters
All four issues map directly onto review checklist items: never trust a client-held access flag without server-side verification, treat every markup renderer as untrusted output, never assume a CSRF token makes an endpoint safe from other injection classes, and never build a request signature as a plain hash of secret-plus-message. Use a construction such as HMAC instead, which is specifically designed to resist length-extension forgery.
Key takeaways
- An access-control flag stored in a client-editable cookie is not access control
- Lightweight markup renderers (markdown, BBCode) need their own escaping, separate from the main HTML sanitiser
- A CSRF token protects against cross-site requests but says nothing about injection flaws in the same endpoint's parameters
- Hash length extension lets an attacker append data to a signed message and forge a valid signature without the secret
- Use HMAC, not a plain hash of secret-plus-message, for any signature or request-authentication scheme
This note has been rewritten and checked for this edition; it is not a copy of the original post.