Комментарии 26
Понятно что для хостинга на сервере это не подойдёт и API сильно быстрее, но собрать данные в принципе можно.
Во-первых, брешь-то в чём? Есть логин и пароль — значит есть доступ ко всему.
Во-вторых, всегда можно прикинуться официальным iOS/Android клиентом и получить полный доступ к 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 абсолютно точно не поможет, ведь при наличии полного контроля над компьютером есть ещё много способов получить доступ к переписке (см. «пропатченный браузер»)
А альтернатива проста — просто удалить возможность "тестовых запросов" для всех методов раздела messages
Альтернатива проста, читайте про JWT и рефреш-токен. Если он будет постоянно изменяться, проблемы нет, так как постоянная прослушка трафика реально выходит за пределы нормальной разработки в область информационной защиты.
Впринципе, можно дергать messages через метод execute. Так что надо не "отключить формочку", а именно отобрать права у тестового приложения.
Как я обошёл запрет на Messages API через документацию Вконтакте