[qutebrowser] IDN spoofing

[Florian Bruhin]

Hey,

On Wed, Apr 19, 2017 at 04:08:41PM +0100, John Lane wrote:
> Is it possible to do this in qutebrowser - I couldn't find a setting for
> it on "qute:settings" ?

Currently it's not. Such a setting would be a first line of defense, but
I also want to think some more about fix this properly while still
showing the encoded form for "normal" IDN domains (say, a German domain
with umlauts in my case).

I opened an issue here with some first thoughts:
https://github.com/qutebrowser/qutebrowser/issues/2547

> What's also interesting is that clicking the "apple.com" link on that
> register article does not work in qutebrowser with the qt5-webkit-ng
>  backend. It does work with the qt5-webengine backend.

Looks like Qt's QUrl doesn't like something about that. While I can open
it with QtWebEngine, I can't e.g. copy the URL.

I smell some Qt bugs to report... :D

On Wed, Apr 19, 2017 at 04:26:30PM +0100, Martin Tournoij wrote:
> On Wed, Apr 19, 2017, at 16:08, John Lane wrote:
> > Interesting article[1] on the register today about internationalised
> > domain name (IDN) spoofing using Punycode[2].k
> > 
> > I think it's quite alarming that many browsers show you what looks like
> > apple.com which in reality is something entirely different. That's
> > something new I've learnt today!
> > 
> > This can be configured against in Firefox about:config by setting
> > "network.IDN_show_punycode=true"
> 
> I thought all of this was fixed years ago by normalizing various homographs to
> their Latin variant. Guess not :-/
> 
> There are some other fixes we could do as well. If we see that punicode is
> being used, we can try to do a lookup to the normalized domain name, and if it
> exists, use that (possibly with a warning). That way the "Cyrillic Apple"
> becomes regular ol' apple.com.
> 
> I don't know how fool-proof unicode normalisation is, though. Unicode is
> pretty large, so there may be oversights?

I don't think this is a good solution. Apart from it being quite hacky
to implement, if I tell the browser to go to the not-quite-apple site, I
want it to go *there*, not to apple.com.

I'm also not sure if normalization actually does this kind of thing.
Cyrillic letters probably have some kind of sensible mapping to latin
ones, but what if you happen to find, say, some Chinese or Japanese
glyph which just happens to look like a "o" but has nothing to do with
it?

> Another, safer, way would be to improve on the Firefox setting by including a
> whitelist of codepoints for common "safe" scripts, such as Arabic, Hangul,
> Chinese, Kanji, and perhaps a few others. If all characters fall in that
> range: show the codepoints, else show the punycode.
> That particular domain from the article uses Cyrillic, so we can't add that to
> the whitelist.

Chromium apparently went for a blacklist[1], but I wonder what other
creative lookalike glyphs you could find if you searched hard enough...

[1] https://chromium.googlesource.com/chromium/src/+/08cb718ba7c3961c1006176c9faba0a5841ec792%5E%21/

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/qutebrowser/attachments/20170420/3a75efb2/attachment.asc>