Conversation
PoorValidation2's shopping-cart cost math used plain int arithmetic (pineappleAmount*30, orangeAmount*3000, etc.) and validateAmount() only clamped the lower bound (negative amounts -> 0). A sufficiently large positive amount (e.g. orangeAmount=1000000 -> orangeCost=3,000,000,000) overflows a 32-bit int and wraps negative, driving finalCost <= 0 while orangeAmount > 0 and unlocking the free-oranges success response without a legitimate order. Fix: validateAmount() now also clamps the upper bound to a new MAX_ITEM_AMOUNT=1000 constant, and all cost arithmetic (pineappleCost/orangeCost/appleCost/bananaCost/finalCost) is widened from int to long as defense-in-depth so the multiplication itself cannot wrap even if the clamp were ever loosened. Added PoorValidation2IT covering: the original overflow exploit no longer produces the free-oranges response, a larger multi-field overflow attempt also fails, and a legitimate order of 1 of each item still completes with the correct $3090 total. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🏆 Security Shepherd — CTF Patch Score1 / 40 challenges patched
Commit: 🎉 Your result is on the leaderboard — see where you rank! 🏆 |
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Summary
PoorValidation2's shopping-cart cost math used plain
intarithmetic (pineappleAmount*30,orangeAmount*3000, etc.) whilevalidateAmount()only clamped the lower bound (negative amounts became 0). A sufficiently large positive amount (e.g.orangeAmount=1000000->orangeCost=3,000,000,000) overflows a 32-bitintand wraps negative, drivingfinalCost <= 0whileorangeAmount > 0— unlocking the free-oranges success response without a legitimate order.Fix
validateAmount()now also clamps the upper bound to a newMAX_ITEM_AMOUNT = 1000constant.pineappleCost/orangeCost/appleCost/bananaCost/finalCost) is widened frominttolongas defense-in-depth so the multiplication itself cannot wrap even if the clamp were ever loosened.Testing
mvn -o compilesucceeds cleanly (JDK 17).mvn -o spotless:applyconfirms formatting is clean.src/it/java/servlets/module/challenge/PoorValidation2IT.javawith 3 cases:orangeAmount=1000000overflow exploit must no longer return the free-oranges response.2000000000per field) must also fail.finalCostwheneverorangeAmount > 0is 3000 (one orange, nothing else), so the free-oranges condition (finalCost <= 0 && orangeAmount > 0) can never be satisfied again — and a legitimate small order (well under the 1000-unit clamp) computes an identical total to before.Addresses Challenge-13-Poor-Validation-2.
🤖 Generated with Claude Code