Conversation
Every branch built against this base was failing to build/boot in CI with ExceptionInInitializerError: TypeTag :: UNKNOWN, because lombok 1.18.36 can't reflectively patch JDK 25's javac internals. Baking the fix into the fork's own dc34-ctf base so every future branch inherits it automatically instead of needing a manual per-branch cherry-pick. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ime secret + constant-time compare InsecureLoginTask hardcoded the accepted username/password pair (CaptainJack/BlackPearl) directly as literal strings compared via String.equals(). This exposes two separate cryptographic failures: 1. The plaintext credential is baked into the compiled class file and can be recovered by anyone who can read the deployed artifact (decompilation, source leak, or the accompanying obfuscated JS), independent of any transport-layer protection. 2. String.equals() short-circuits on the first mismatched byte, so response timing leaks how many leading characters of a guessed password are correct, enabling a timing side-channel attack. Fix: the password is now generated once at class-load time via SecureRandom (never hardcoded, never written to source/JS/logs), and compared using MessageDigest.isEqual for constant-time comparison. The username check and the lesson's two endpoints are unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🏆 WebGoat — CTF Patch Score1 / 69 challenges patched
Commit: 🎉 Your result is on the leaderboard — see where you rank! 🏆 |
Author
|
Closing as part of a full stand-down of this CTF push. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes Challenge-12-Insecure-Login (A04 Cryptographic Failures).
Vulnerability:
InsecureLoginTask.completed()hardcoded the accepted username/password (CaptainJack/BlackPearl) as literal strings compared withString.equals(). This is a plaintext-credential-in-source cryptographic failure (recoverable via decompilation/source read) and a non-constant-time comparison (timing side-channel).Fix: the password is now generated once at class-load time via
SecureRandom(never hardcoded anywhere in source/bytecode), and compared withMessageDigest.isEqualfor constant-time comparison. Username check and both existing endpoints (/InsecureLogin/task,/InsecureLogin/login) are otherwise unchanged.Local verification (WSL, JDK 25):
mvn -o compilesucceeds./InsecureLogin/taskwith the original hardcoded creds (CaptainJack/BlackPearl) now returnslessonCompleted:false(exploit fails)./InsecureLogin/loginstill returns 202 (legitimate endpoint behavior unchanged).🤖 Generated with Claude Code