sahvx655-wq opened a new pull request, #420:
URL: https://github.com/apache/commons-validator/pull/420
I was checking how DomainValidator handles non-ASCII hosts and found
unicodeToASCII passes the input straight to java.net.IDN.toASCII, whose
nameprep step silently deletes default-ignorable and format code points before
the label regex runs. A host carrying a soft hyphen, a zero-width space or
joiner, or a byte order mark therefore collapses to a clean label and
validates: isValid("example.com") and isValid("example.com") both return
true, and UrlValidator.isValidAuthority shares the converter so it behaves the
same way.
The risk is that two byte-distinct strings validate as the same host, which
is a spoofing vector and quietly poisons any allow-list built from validated
input. None of these code points are legal in an RFC 1123 host name, and IDN's
IDNA2003 normalisation never keeps one in a real label, so the fix scans the
input in unicodeToASCII and returns it unconverted when it holds a Unicode
FORMAT code point, leaving the existing label regex to reject it. Keeping the
guard in the shared converter fixes DomainValidator and UrlValidator in one
place rather than each caller, and legitimate IDN input is unaffected because
its letters are not format characters.
--
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]
