Conversation
…Validate XssChallengeSix reflects a user-supplied searchTerm into <a href="..."> after passing it through XssFilter.anotherBadUrlValidate(). That method only escaped the FIRST occurrence of '<', '>', and '"' (replaceFirst), so a second, later occurrence of any of those characters survived untouched and let an attacker close the href attribute early and inject a brand new HTML attribute (e.g. onmouseover=alert(1)) or a whole new tag, achieving reflected XSS despite the filter. Switch all four breakout characters (plus single quote, for defense in depth) to replaceAll so every occurrence is neutralised, not just the first. Legitimate http(s) links are unaffected since they don't contain these characters. Challenge-40-XSS-6
🏆 Security Shepherd — CTF Patch Score1 / 40 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.
Challenge-40-XSS-6
XssChallengeSix.doPostreflects the user'ssearchTerminto<a href="...">Your HTTP Link!</a>after running it throughXssFilter.anotherBadUrlValidate.That sanitizer only escaped the first occurrence of
<,>, and"(viareplaceFirst). A payload containing a second occurrence of any of those characters (e.g.http://a/x"onmouseover="alert(1)orhttp://a/x<i>text</i><img src=x onerror=alert(1)>) sailed through with that later character completely unescaped, closing thehref=""attribute early and letting an attacker inject a brand-new live attribute/tag on the anchor element — a reflected XSS bypass of the filter.Fix
Switch all of
<,>,"toreplaceAll(every occurrence, not just the first) and also encode'for defense in depth. Legitimate http(s) links, which don't contain these characters, are unaffected.Local verification (WSL)
Full
mvn compile/full container stack was heavily contended by many concurrent sibling builds in the shared sandbox (timed out at 400s), so I compiled justutils/XssFilter.java+utils/FindXSS.javadirectly withjavacagainst the project's cached Maven dependencies, and drove them with a standalone harness that reproducesXssChallengeSix.doPost's exact reflection logic (sanitize -> wrap in <a href> -> FindXSS.search):"/</>intact in the rendered<a>tag (confirmed exploitable attribute/tag breakout).http://www.example.com/path?x=1) renders identically before and after the fix.Only
src/main/java/utils/XssFilter.javawas changed.