Как стать автором
Обновить

Комментарии 26

А если проставить headless chrome, написать selenium скрипт и настроить доступ через MitM прокси, по идее от пользователя не отличить. Данные все из прокси доставать.

Понятно что для хостинга на сервере это не подойдёт и API сильно быстрее, но собрать данные в принципе можно.

Во-первых, брешь-то в чём? Есть логин и пароль — значит есть доступ ко всему.


Во-вторых, всегда можно прикинуться официальным iOS/Android клиентом и получить полный доступ к API, наверное.

Вроде бы уже писали о том, что официальный клиент не использует публичные апи и шифрует передаваемые данные. (могу ошибаться)

Неправда. Я некоторое время назад занимался моддингом оф. приложения (делал нечиталку), там на 99% используется официальный API. До сих пор пользуюсь той версией, сообщения пока работают.

Но зачем это всё?
Я для своего месседжера (персональный) просто взял access_token kate mobile'а и продолжил пользоваться им как ни в чём не бывало. В переписке с поддержкой на эту тему было сказано


Да, пока такой подход может работать. Однако на всякий случай предупредим: однажды мы начнем блокировать пользователей, чьи токены вызываются не из ассоциированного приложения

Но, честно говоря, мне кажется это совсем бред, особенно если запросы не отличаются от запроса приложения

На самом деле вообще непонятно, как со всеми этими токенами жить опенсорс-приложениям.

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

Я чего-то не понял, какое решение предлагает автор? Как бы вы это реализовали? Критиковать-то прекрасно, но где альтернатива?


Не признают это проблемой, никто не будет лопатить тонны кода ради сомнительных угроз.
IMHO

Тоесть возможность за 5 минут выкачать последние личные сообщения и как минимум по 100 вложений картинок Вы не считаете угрозой личным данным? Или Вы хотите, чтобы я написал отдельную библиотеку-обёртку, что доказать 100%-ную возможность этого метода?

Ещё раз, где вы угрозу увидели? Почему возможность выкачивать СВОИ сообщения вы считаете угрозой? В том же Telegram, например, возможность выкачивания всей переписки это вообще штатная возможность, встроенная прямо в официальный клиент.

Я вижу опасность в том, что я могу условно сниффингом в локальной сети выловить из запроса пароль и логин пользователя, а после этого получить доступ к его сообщениям. Именно этого и пытались избежать ВК, закрывая доступ к API по паролю и логину

я могу условно сниффингом в локальной сети

Не можете, потому что https. Так что я угрозы по-прежнему не вижу


Да, лет семь назад я сам сниффал сеть и получал доступ к чужим сообщениям (и меня тоже сниффали, кстати). Но это было лет семь назад, сейчас уже принудительный https для всех


закрывая доступ к API по паролю и логину

Если смысл и правда в этом, то со стороны ВК это бессмысленное страдание фигнёй, так как Selenium и прикидывание официальными клиентами всё равно никто не отменял


Поэтому просто не надо вводить свой пароль куда попало, и всё будет пучком и без угроз

Https не защитит от прокси сервера, а также настроенного на пк фальшивого корневого сертификата. Об этом можно вообще написать отдельную статью и сделать самописную библиотеку для messages api.

Если пользователь ведёт себя настолько безответственно, что допустил на своём компьютере подключение левых прокси и сторонних сертификатов, то ВК здесь вот вообще абсолютно ни при чём.

Ну а например школьники, которые могут зайти в ВК на уроке, на школьном компьтере? А как же социальная инженерия, где пользователя могут просто обмануть? Да, это не проблемы ВК, но Вы действитеоьо хотите облегчить жизнь этих мошенников? А где гарантия, что однажды Вы сами на это случайно не попадётесь? (без обид)

На условном «школьном компьютере» может вообще стоять пропатченный «учителем» браузер, который будет собирать все личные сообщения прямо из открытой вкладки ВК. Ещё раз: в том, что пользователь лично вводит свой пароль куда попало, ВК не виноват вообще никак.


Вы действитеоьо хотите облегчить жизнь этих мошенников?

Если пользователь сам добровольно передаёт пароль стороннему лицу, да ещё и код из SMS при двухфакторке тоже перепечатывает ему, а потом ещё и девичью фамилию матери сообщает и фотографию обратной стороны кредитной карты шлёт, то любые технические меры здесь бессильны и единственный способ усложения жизни мошенников — ликбез по информационной безопасности (который ВК кстати иногда проводит).


А где гарантия, что однажды Вы сами на это случайно не попадётесь?

Я не ввожу свой пароль на «школьных компьютерах» и в недоверенных приложениях.

Ну, такими темпами можно вообще придти к выводу, что нет смысла делать у приложений хоть какую-то защиту — даже двухфакторка бессмысленна, ведь пользователь сам во всем виноват, если случайно сольёт свой пароль.

Нужна защита от таких атак, в которых пользователь не виноват — например, от того же сниффа сети или от перехвата SMS спецслужбами (после подобных событий в Telegram и завезли двухфакторку с паролем, кстати).


Впрочем, во взломах компьютера пользователь тоже может быть не виноват (всё-таки это какой-нибудь майкрософт косячит и RCE-уязвимости в своих SMB и RDP клепает), но к сожалению я не вижу технических способов защититься на компьютере, который полностью подконтролен кому-то другому, без серьёзного ущерба для юзабилити. Банальное отключение доступа к messages API абсолютно точно не поможет, ведь при наличии полного контроля над компьютером есть ещё много способов получить доступ к переписке (см. «пропатченный браузер»)

Я даже добавлю: тут не то что угрозы нет, невозможность выкачать свои сообщения — это недостаток. Например — если я хочу сделать бекап своих сообщений не в ВК. Без API я буду или копировать вручную (тратя много времени) — или придумывать костыли по типу selenium и патченных браузеров.

А альтернатива проста — просто удалить возможность "тестовых запросов" для всех методов раздела messages

Альтернатива проста, читайте про JWT и рефреш-токен. Если он будет постоянно изменяться, проблемы нет, так как постоянная прослушка трафика реально выходит за пределы нормальной разработки в область информационной защиты.

Впринципе, можно дергать messages через метод execute. Так что надо не "отключить формочку", а именно отобрать права у тестового приложения.

www.npmjs.com/package/vk-io может авторизоваться по логину/паролю, притворяясь офф. приложениями. Доступ к апи сообщений есть.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.