New HTTP Parameter Pollution Rules #2747
Merged
Conversation
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
This was referenced Aug 10, 2022
RedXanadu
approved these changes
Aug 15, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is a little set new pair of rules that prevents parameter pollution bypasses in bug bounty findings
Z05OZUCHand5UXE4RK0.The issues reported bypass existing parameter pollution rule 921180 via the following constructs:
1 -
foo[1]a=bar&foo[1]b=<evil>- parameter parsers often cut after the closing of the array. 921180 PL3 takes the full name, though.2 -
foo[1]x[1]=bar&foo[1]x[2]=<evil>- extension of 1, came up with this myself, this has the advantage that the parameter name does end with]just like a valid array notation.3 -
foo[1]=bar&foo[2]=<evil>- simple parameter parsers don't do arrays4 -
foo=bar&foo[1]=<evil>- simple parameter parsers don't do arrays5 -
foo[1]=bar&foo[1]acb]=<evil>- simple parameter parsers don't do arraysNew rule 921210 PL3 prevents case 1 and case 2, while still allowing
foo[1]andfoo[1][2](= array notation). They will not allow 3-dimensional arrays though (foo[1][2][3]).New rule 921220 PL4 disallows the
[character in parameter names. This effectively disallows array parameter (names). This prevents case 3, 4 and 5. Applications that make use of array parameters will have to disable this rule. Ideally via a rule exclusion for each array parameter name.I would prefer to detect case 4 at PL3 while still allowing array parameter (names), however, this is seriously difficult and I can not see how this could be done without a construct over several helper rules. On top, case 4 only works against a stupid parameter parser, something that should not run behind a PL3 WAF.
I would also like to detect case 5 at PL3, but I could not get a regex that detects this while still allowing 2-dimensional arrays. The only way I could think of would make use of a look-around.
This fixes #2618.