Pull to refresh

Comments 11

1) Т.е. предлагаете ключи зашифровать, правильно? А ключ шифрования где хранить будете?
2) Можно поподробнее про широкие возможности логгирования?

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

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

Согласен с Вами во многом. Но мы говорим об sdk, которой пользуются тысячи людей.
Существует много вредоносных программ, способные собрать таким образом токены, а сотням недобросовестных разработчиков под силу получить доступ к персональной информации своего пользователя.

Точно так же вы могли создать WebView где открывалась бы фишинговая страница.

Впринципе да. Но это трудоемко. И все-таки это не сама цель статьи. Я хотел указать на недостатки библиотеки больше

Так а недостатки в чем? Что вредоносные программы могут взять этот sdk и им пользоваться для сбора данных пользователей?

Могут вполне. Недостатки: 1. Открытое хранение токенов. 2. Использование webview в sdk для авторизации. Стоит от этого отказаться. Ну и остальное явно/неявно является следствием этих двух.

Т.е. если хранить токен как aes(plainTextToken, «supersecretkey») а webview заменить на активити то считаете это существенно что-то изменит? Я думаю нет, т.к. токен все равно можно достать с одним несложным дополнительным шагом (а если нельзя то и хранить его незачем), а любые события ввода можно и из активити достать точно так же как и их вебвьюхи.
О, наконец-то кто-то, кто тоже страдает от VK Android SDK!

Удивляет то, что в этом SDK довольно скудная документация. Скажем, взять ту же авторизацию. Единственное, что написано в официальной документации — это то, что нужно использовать метод VKSdk.login(), в который передаётся параметр scope. Ни примеров, каким может быть scope, ни хотя бы объяснения, что он значит, в документации нет. Приходится лезть в исходники и уже там видеть, что это массив разрешений. Но списка возможных значений нет нигде вообще.

Или, например, открытие официального приложения VK из своего Android-приложения. Скажем, чтобы открыть чей-то профиль, нужно создать следующий интент:
Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("vkontakte://profile/" + friendID));

А теперь нетривиальная задачка: как открыть чат с человеком c ID friendID?

Верно. Кажется, по этой причине, удобнее api sdk заменять на rest запросы (тем более часто не все же нужно, только общую информацию, публикации стены и т.д.)


Но списка возможных значений нет нигде вообще.

Они здесь)
С клиентом не работал, похоже это боль)

Sign up to leave a comment.

Articles