On 7/30/2012 2:47 PM, Reindl Harald wrote: > > > Am 30.07.2012 22:54, schrieb William A. Rowe Jr.: >> What is less clear is what precautions we should take when functioning as >> a forward proxy with proxy uri string contents, or presenting user-provided, >> non-canonicalized host names. I can imagine such translation being abused to >> conceal some forms of XSS exploitation. >> >> I'd start by assembling a patch to introduce punycode transliteration into >> the >> apr-util library and another patch into httpd for vhost, mass-vhosting using >> utf-8 path names, and presenting trusted utf-8 values for our error log and >> field tokens. Does anyone have concerns before I begin messing with this >> logic? > > the idn-code has nothing to search in server-configs > > they are not in DNS, they are not in mail-servers > all on the server level is working with punny-codes > and this is good how it is
Exactly my point. If you configure a utf-8 hostname, we know in fact it is a punycode encoding of that value, which is why I believe it makes sense to represent both when you test the vhost configs with -D DUMP_VHOSTS. If you configure a punycode hostname, it will be accepted with no hassle. There is no such thing as an actual utf-8 or extended ASCII (8 bit) hostname. For adding the feature to mod_vhost_alias, I absolutely would not do that without adding a flag (or a %-escape modifier) to determine whether we are looking at the punycode host (default) or utf-8 representation (configurable). If there are a significant number of folks who enjoy reading punycode, I have no problem making the access and error log representations in original punycode representation, and for non-canonical hostname behavior, I believe that would be for the best.
