Skip to content

Fetching favicon for Non-ASCII and Internationalized domains fails #731

Closed
@lopopolo

Description

Expected Behavior

  • Google fallback should use https.
  • Non-ASCII domains need to be %-encoded when constructing the google fallback url because they are url query string parameters. For example, http://💩.la. QUrlQuery::addQueryItem(?
  • Internationalized domain names are converted to Punycode by browsers before making requests to the domain. I believe QUrl does this but am not sure. Tests needed?

Current Behavior

  • Google fallback is an http endpoint
  • Non-ASCII domains fail to fetch favicons from google fallback

Possible Solution

Steps to Reproduce (for bugs)

  1. Create a new entry with http://💩.la as the URL
  2. Click on the "Icon" icon
  3. Click download favicon
  4. Observe error popup

Context

Debug Info

KeePassXC - Version 2.2.0
Revision: caa49a8

Libraries:

  • Qt 5.9.0
  • libgcrypt 1.7.7

Operating system: macOS Sierra (10.12)
CPU architecture: x86_64
Kernel: darwin 16.6.0

Enabled extensions:

  • KeePassHTTP
  • Auto-Type
  • YubiKey

Activity

lopopolo

lopopolo commented on Jul 2, 2017

@lopopolo
Author

This could be considered a security issue because the current 2.2.0 leaks (all?) sites in a password database to the network

phoerious

phoerious commented on Jul 2, 2017

@phoerious
Member

Downloading a favicon leaks at least the destination server anyway, even when using https (just not the hostname and URL). Also when you add http URLs, they will be called first before any Google fallback (even if that is https). I'll prepare a patch, though.

TheZ3ro

TheZ3ro commented on Jul 2, 2017

@TheZ3ro
Contributor

This will only leaks website you download the favicon for (obviously). I was already planning to fixing google fallback to https for #719

lopopolo

lopopolo commented on Jul 2, 2017

@lopopolo
Author

Downloading a favicon leaks at least the destination server anyway, even when using https (just not the hostname and URL).

Ahh yes, I forgot about SNI. Apologies for being overly dramatic.

droidmonkey

droidmonkey commented on Jul 2, 2017

@droidmonkey
Member

There is nothing particularly sensitive in a domain name, and there is nothing saying the request is coming from a password manager. Favicon lookups is a VERY common transaction.

TheZ3ro

TheZ3ro commented on Jul 3, 2017

@TheZ3ro
Contributor

Internationalized domain names are converted to Punycode by browsers before making requests to the domain. I believe QUrl does this but am not sure. Tests needed?

The QUrl behavior seems a little bit strange here.

QUrl uurl = QUrl(newurl);
qDebug() << newurl << uurl.toDisplayString() << uurl.toEncoded();

Outputs for various punycode url:

"http://www.äsdf.de/" "http://www.äsdf.de/" "http://www.xn--sdf-pla.de/"
"http://💩.la" "http://.la" "http://.la"
"http://www.аррӏе.com" "" ""
"https://www.xn--80ak6aa92e.com/" "https://www.аррӏе.com/" "https://www..com/"

Also, there was this bug https://bugreports.qt.io/browse/QTBUG-60364

changed the title Favicon fetching issues Fetching favicon for Non-ASCII and Internationalized domains fails on Sep 10, 2017
phoerious

phoerious commented on Feb 27, 2018

@phoerious
Member

I tested both raw emoji and punycode domains with our new cURL backend and it seems to work now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Fetching favicon for Non-ASCII and Internationalized domains fails · Issue #731 · keepassxreboot/keepassxc