sahvx655-wq opened a new pull request, #429:
URL: https://github.com/apache/commons-validator/pull/429
unicodeToASCII already returns the host unconverted when it carries a
Unicode FORMAT code point, because IDN.toASCII deletes those during nameprep
and the label would otherwise validate as a clean string. Walking the nameprep
mapping showed the FORMAT category is only part of RFC 3454 Table B.1
("commonly mapped to nothing"): the combining grapheme joiner U+034F, the
Mongolian TODO soft hyphen and free variation selectors U+1806 and
U+180B..U+180D, and the variation selectors U+FE00..U+FE0F are stripped as well
but report as Mn/Pd, so the getType check waves them through.
isValid("exa͏mple.com"), plus the variation-selector and Mongolian forms,
convert to example.com and return true, so a byte-distinct host validates as
example.com and EmailValidator.isValidDomain and UrlValidator.isValidAuthority
inherit the hole; left alone it is an invisible-character homograph and an
allow-list poisoning vector.
The guard now rejects those non-FORMAT code points beside the existing
FORMAT check, so the label regex sees the original invisible character and
fails it. Keeping it inside unicodeToASCII closes the domain, email and URL
callers together rather than each re-testing for stripped code points, and
legitimate IDN letters (bücher.ch, президент.рф) and the hangul fillers that
punycode to a real label are untouched. testIDNMappedToNothing covers the four
representative code points; it fails on master and passes with the guard.
--
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]
