[Из песочницы] Грабли VK SDK для Android

Привет Хабр! Недавно понадобилось интегрировать соц. сеть в проекте для Android. Выбор пал на ВК и, соотвественно, их офиц.библиотеку VKCOM/vk-android-sdk. Использовал ее раньше и ещё тогда не был от неё в восторге из-за малого количества примеров. Сейчас смотрю в исходный код, а он всё также далеко не идеален.

Обычно всегда просматриваю ключи в преференсах при запуске приложения и увидел такое вот (после авторизации):

Ключ: VK_SDK_ACCESS_TOKEN_PLEASE_DONT_TOUCH
Значение: scope=offline&https_required=1&access_token=e5cd068be722caafd3c449557e19c19eeed3f54c295a65cd097ed087f61c44394bd985975364fc34641cc&expires_in=0&created=1476876628588&user_id=220436550

Насторожило. Не думаю, что это хорошо хранить такие данные в открытом виде. Вообще, ещё после первого знакомства думал о возможности считывания вводимых данных при авторизации. Почему бы нет?

Нужно всего лишь импортировать как модуль. Убираем возможность авторизации через основного клиента (оставляем второй вариант):
if (VKUtil.isAppInstalled(ctx, VK_APP_PACKAGE_ID)
    && VKUtil.isIntentAvailable(ctx, VK_APP_AUTH_ACTION)
    && fingerprints.length > 0
    && fingerprints[0].equals(VK_APP_FINGERPRINT)) {
        if (savedInstanceState == null) {
            intent = new Intent(VK_APP_AUTH_ACTION, null);
            intent.setPackage(VK_APP_PACKAGE_ID);
	    intent.putExtras(bundle);
	    startActivityForResult(intent, VKServiceType.Authorization.getOuterCode());
        }
    } else {
        new VKOpenAuthDialog().show(this, bundle, VKServiceType.Authorization.getOuterCode(), null);
}

» Исходник здесь

Немного модернизируем их кастомный webview:

@Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
    return new BaseInputConnection(this, false);
}

@Override
public boolean dispatchKeyEvent(KeyEvent event) {
    super.dispatchKeyEvent(event);
    // Без условия event дублируется
    if (event.getAction() == KeyEvent.ACTION_UP) {
        Log.d("TAG", event.getKeyCode() + " | " + event.toString());
    }
    return true;
}

» Исходник здесь

Спасибо ответу на StackOverFlow. Получается пароль и логин полностью считывается при ручном вводе в их диалоговом окошке (без копипаста). Можно определить даже регистр символа:

Вывод logcat
7 | KeyEvent { action=ACTION_UP, keyCode=KEYCODE_0, …, source=0×0 }
59 | KeyEvent { action=ACTION_UP, keyCode=KEYCODE_SHIFT_LEFT, …, source=0×0 }
40 | KeyEvent { action=ACTION_UP, keyCode=KEYCODE_L, …, source=0×0 }

Всё это открывает широкие возможности. Возможно ещё можно подобрать схожие примеры.
Я небольшой спец в cookies, но, например, удается вытащить поля remixstid, remixmdevice, remixlang, remixlhk. Похоже они касаются данных о токене, судя по описанию функции выхода для аккаунта в основном классе.
/**
  * Wipes out information about the access token and clears cookies for internal browse
  */
@SuppressLint("NewApi")
public static void logout() {
    ...
    CookieManager.getInstance().removeAllCookies(null);
    ...
}

» Исходник здесь

Думаю для ВК лучше полностью перенести авторизацию на основного клиента. А что касаемо API, наполнить подробными примерами (Wiki на GitHub неплох в дополнение javadoc имеющемуся). Но сейчас использовать такой подход сомнительно.

Спасибо за внимание!

Комментарии (3)

  • 19 октября 2016 в 18:40

    0

    1) Т.е. предлагаете ключи зашифровать, правильно? А ключ шифрования где хранить будете?
    2) Можно поподробнее про широкие возможности логгирования?
    • 19 октября 2016 в 19:02 (комментарий был изменён)

      0

      1) Можно было бы. Например, в одном приложении я шифровал пароль с логином через AES. Но опять же исходники открыты (впрочем и без этого они открыты можно сказать, но на гитхабе все очень читаемо). Поэтому думаю это обязанность или разработчиков отдельно, или уже команды вк (будь-то хранить на серверах как и сейчас и/или расширить возможности своего клиента, где возможно использовать шифрование). Но точно не такой способ как сейчас.
      2) Это я в смысле несанкционированного доступа к аккаунту вк.
      Думаю, неплох вариант, когда приложение обращалось бы к клиенту за токеном. И получается напрямую разработчикам было бы доступно непосредственно только обращение к API.

  • 20 октября 2016 в 06:25

    0

    1) Это вполне нормальный способ. Единственный метод добыть ключи из приватных файлов атакуещему когда все остальное не дырявое — это добыть файлы из под рута. Но когда у тебя рут то можно вообще все сделать.
    2) Та же самая штука — зачем самому себя хакать? Если SDK это часть своего приложения то с любыми процессами в своем приложении можно сделать что угодно любыми методами. А другим приложениям эти данные недоступны.

© Habrahabr.ru