sahvx655-wq opened a new pull request, #425:
URL: https://github.com/apache/commons-validator/pull/425
Chasing how the `strict` flag is meant to enforce an exact match in the
pattern-based date helpers, I found it rests entirely on `datePattern.length()
!= value.length()`. `SimpleDateFormat.parse(String)` stops at the first
character it cannot read instead of failing, so a value whose trailing rubbish
keeps the length equal to the pattern walks straight through:
`formatDate("11/11/199f", "MM/dd/yyyy", true)` consumes only `11/11/199`,
quietly reads the year as 199 and hands back a `Date`, and
`GenericValidator.isDate` calls the same string valid. The truncated year in a
debug trace is what gives it away. The same heuristic sits in
`GenericTypeValidator.formatDate` and in the deprecated `DateValidator.isValid`
that `GenericValidator.isDate` delegates to, so both accept the garbage.
Both methods now run the parse through a `ParsePosition` and, when `strict`,
reject the value unless the parse reached the end of it, which is the
full-consumption check `routines/AbstractFormatValidator.parse` already uses.
The length comparison stays in place, so an abbreviated field like `2/12/1999`
is still rejected and non-strict parsing keeps its current leniency. Left
alone, any caller trusting the strict contract to screen malformed dates takes
attacker-supplied trailing data and stores a different date from the one
submitted.
- [x] Read the [contribution guidelines](CONTRIBUTING.md) for this project.
- [ ] Read the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) if you use
Artificial Intelligence (AI).
- [ ] I used AI to create any part of, or all of, this pull request. Which
AI tool was used to create this pull request, and to what extent did it
contribute?
- [x] Run a successful build using the default
[Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command
line by itself.
- [x] Write unit tests that match behavioral changes, where the tests fail
if the changes to the runtime are not applied. This may not always be possible,
but it is a best practice.
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Each commit in the pull request should have a meaningful subject line
and body. Note that a maintainer may squash commits during the merge process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
