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>
IDOREditOtherProfile.completed() trusted the client-supplied path variable and request body to decide whose profile record got written, only checking role/color values after the fact. This let any authenticated user submit another user's userId (via the path or the JSON body) and modify that other user's profile (color/role) without any server-side authorization check tying the request to the session's actual authenticated identity. Now the endpoint requires that both the path variable and, if present, the body's userId match the session's authenticated user id before any write happens; any mismatch is rejected outright regardless of what role/color values were supplied. Editing your own profile (the legitimate action) still succeeds, and the role field can no longer be set by the client at all, closing off a privilege-escalation side channel through the same endpoint.
🏆 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.
Vulnerability
IDOREditOtherProfile.completed()(PUT /IDOR/profile/{userId}) trusted the client-supplied path variable and/or the JSON body'suserIdfield to decide which user's profile record to write, without any check tying the request to the session's actual authenticated user. Any authenticated user could submit a different user's id and modify that user'scolor/rolefields.Fix
The endpoint now requires that both the path variable and (if present) the body's
userIdmatch the session's authenticated user id (idor-authenticated-user-id) before any write occurs. Any mismatch is rejected regardless of the role/color values supplied. The role field is no longer settable by the client at all, closing a privilege-escalation side channel through the same endpoint. Editing your own profile still works.Local verification (WSL)
Built and booted the app locally (JDK 25, matches CI). Registered a user, logged into the IDOR lesson as
tom/cat(authenticated id2342384).PUT /IDOR/profile/2342388(Buffalo Bill's id) with{"userId":"2342388","color":"red","role":1}->lessonCompleted:false. Also tried the path/body-mismatch variant (own id in path, other user's id in body) -> alsofalse.PUT /IDOR/profile/2342384(own id) with{"userId":"2342384","color":"blue"}->lessonCompleted:true, profile updated. Same with nouserIdin the body, and with an attemptedroleoverride (role stays unchanged, confirming no escalation is possible).🤖 Generated with Claude Code