Gervase Markham wrote:
On 26/02/09 11:49, Jean-Marc Desperrier wrote:
What's truly broken is that the current i18n attack protection relies on
the checking done by the registrar/IDN, and that the registrar/IDN can
only check the second-level domain name component.
Actually, our protection had a bug (that is, there were some characters
not on our blacklist which should have been). But it's not true that
there was no protection.
Which blacklist ? There's a blacklist inside the browser ?
The oppposite seems obviously said here :
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
« it does not [] require multiple DNS lookups, large character tables in
the browser [] »
Blacklist at the registrar level can not protect from attacks on the
third-level domain name (or fourth, or more).
But this being said, I'm coming to think it would be better to take a
wider perspective and consider that making security rely on the user
being able to *validate* the content of the URL bar is not realistic.
You know, you can exclude "╱".
But then you start wondering how many user will *really* notice if
there's a "∕" or a "⁄", or "ʃ", or "Ɉ", or "͵ʹ", or "٪", or "ޙ" ,"ހ",
"৴", "૮", "८", "།", "༼", "ᚋ", "ᤣ", "⁒", "⅟", "∠" instead of "/".
And then you begin to think that maybe just having "." would work very
often, that most user have the most cursory look at the url bar, so that
making security depend on the url bar is just bad.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
