Попали в сети

Социальные сети стали неотъемлемой частью нашей жизни и продолжают внедряться в неё все глубже. Каждому из нас близка какая-то определенная сеть — многие любят удобную для взаимодействия платформу ВКонтакте, кто-то любит краткость Twitter, кто-то строчит простыни текста в LiveJournal, всем нравится присутствовать в Google Plus (но ничего не писать в нем), кому-то мил замысловатый интерфейс Facebook, а некоторые жить не могут без оценок Одноклассников. Каждому своё.

Жизнь современного человека постоянно оцифровывается «по вашему хотению»: судя по квадратной фотографии с наложенным фильтром, вы позавтракали аппетитным омлетом, в середине дня чекин доложил, что вы посетили обувной магазин, ближе к полуночи 140-символьное сообщение явно указало, с кем вы проведете ночь. Ваши родные и близкие, все что вы любите кушать, одежда, которую хотите носить, места, в которых бываете, все ваши хочу, люблю и ненавижу — все это теперь есть в интернете.

Будущее уже здесь — настали те времена, когда можно узнать о человеке всё, и даже не быть знакомым с ним лично, когда каждого из нас можно охарактеризовать по профилю в социальной сети. Даже никакие Deep Packet Inspection не нужны.

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

Любая социальная сеть — совокупность социальных графов:

  • для обычного пользователя социальная сеть — сервис где можно общаться с другими людьми, обмениваться информацией, искать новые знакомства или старых друзей. Очень жаль, но чаще всего, социальные сети являются основным способом прокрастинации;
  • для маркетолога социальная сеть — ценный источник данных для анализа поведения пользователей. Узнав дни рождения ваших родственников (которых вы любезно указали в своем профиле), можно релевантно «продавать» вам цветы с доставкой на дом, предлагать заказать пиццу, если вы засиделись вечером онлайн, или рекламировать новую модель молодёжного автомобиля, если вы «гуглили» автокредитование;
  • для злоумышленника социальные сети могут стать настоящим «рабочим» инструментом — отмычкой к вам или вашим близким. Помните СМС-сообщения «мама, пришли 1000 рублей на этот номер, потом все объясню»? Благодаря огромному объему персональных данных, опубликованных в сети, социальная инженерия имеет все шансы стать чумой XXI века. Еще совсем недавно самый распространенный секретный вопрос для восстановления пароля к почтовым ящикам был «девичья фамилия матери». Наши мамы указывают свою девичью фамилию в своём профиле, чтобы одноклассники смогли её быстрее найти.

Чем больше двигаешься, тем больше запутываешься

Конечно не нужно, сломя голову, удалять все свои профили и менять имя и фамилию на вымышленные, но и забывать что социальные сети не игрушка - тоже не нужно. Всегда стоит задумываться о том, что и где вы пишете, какие фотографии выкладываете. Помимо этого, стоит узнать подробнее о настройках приватности в вашей любимой социальной сети, ограничить доступ посторонних людей к информации о себе и своих близких. Эта превентивная мера поможет снизить риск компрометации ваших приватных данных, но не гарантирует 100% безопасность.

Сети бывают дырявыми

У большинства социальных сетей есть API (Application Programming Interface) — набор готовых классов, функций и методов, предоставляемых социальной сетью для использования во внешних сервисах или приложениях. Например, через API работают мобильные приложения, каждое ваше действие в приложении, будь то добавление кого-то в друзья, лайк или ретвит — операция отправки запроса в API, получение от него ответа и визуализация события на вашем мобильном устройстве.

Чтобы данные не были доступны через API всем подряд, применяется протокол авторизации OAuth (актуальная версия OAuth 2.0), т.е. ответ от API можно получить, только если вы зарегистрированы или создали специальное «приложение» для этих целей. API таких популярных сервисов как ВКонтакте, Facebook, Twitter, Одноклассники, Foursquare, LinkedIn или Google+ очень похожи — даже самую простую информацию о пользователе можно получить, только используя OAuth. Однако, если внимательно посмотреть в документацию API ВКонтакте, можно обнаружить в описании некоторых методов надпись «это открытый метод, не требующий access_token», т.е. данные возвращаемые через этот метод можно получить без авторизации. Чтобы использовать такие методы, не нужно даже регистрироваться в ВКонтакте.

Например, методы «users.get», «users.getSubscriptions», «users.getFollowers» выдают данные о пользователе (имя, фамилия, страна, город, пол, ссылка на аватар, количество друзей и их id и т.д.), даже если в настройках приватности, для пункта «кому в интернете видна моя страница» указать в качестве параметра «только пользователям ВКонтакте». При помощи методов для работы с фотоальбомами можно без труда получить прямые ссылки на фотографии из того же «закрытого» профиля, а методы для работы со «стеной» выдают содержимое ваших постов, включая количество лайков и репостов. Еще один интересный пример: через API можно получить список друзей «удаленного» аккаунта или на какие паблики аккаунт был подписан.

Впрочем не буду рассказывать обо всех проанализированных мной открытых методах и лишать вас удовольствия поковыряться в документации самостоятельно.

Если сгруппировать на одной странице данные, доступные через API, получится упрощенная версия профиля пользователя. Такая «доступность» информации влечет за собой неминуемый парсинг базы данных пользователей ВКонтакте, т.е. сбор социальных графов. Возможные последствия можно определить если знать наверняка кем и как именно эти данные будут использоваться.

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

Лучшие комментарии

  • Контекст комментария

    Антон Крохман

    «Дырку» оперативно закрыли, но при этом создали головняк некоторым разработчикам приложений для ВК. Раньше я делал users.get с сервера, по трем причинам: 1) Это быстрее, чем вызвать с клиента. 2) Это надежнее в плане того, что пользователь не сможет подделать URL фото, передав его с клиента. Поддельный URL может содержать, например, порнографию, а не аватар пользователя. 3) Поддельный URL может содерать не фото, а какой-нибудь swf, который может быть использован в «хакерских» целях. Такое тоже было. После фикса «дырки» users.get с сервера возвращает только имя пользователя и его пол. Как это можно исправить (не ломая при этом фикс «дырки»)? Два способа: 1) Разрешить вызывать users.get с сервера, при условии передачи клиентского access_token. Так сделано на ОК, ММ и Фейсбуке. 2) Подписывать секретным ключом приложения ответ API на users.get. Тогда разработчик сможет безопасно использовать эти данные, переданные с клиента на сервер.

Добавить 22 комментария

  • Ответить

    Да, кстати. Мы протестировали работу API — API работает отлично, наш сервак задохнулся от производительности серверов ВКонтакте. Всю базу выкачать, конечно, займёт время, но ограничений не словили никаких.

  • Ответить

    В тексте читается, конечно, восторг от открытия факта существования API соцсетей и легкое непонимание того, что такое OAuth на самом деле. Но если это оставить за скобками, то все-таки, насчет API ВКонтакте: через методы типа users.get не получить больше, чем видит произвольный пользователь ВК, зашедший на страницу искомого пользователя. Т.е. можно перебирать vk.com/id1, vk.com/id2… vk.com/idNNNNNN — все, что вы там видите, и можно «выкачать». Хоть по HTTP, хоть через API.

  • Ответить

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

  • Ответить

    Юра, гхм. «не будучи юзером ВК» — это что означает, это что за ограничитель? Не кажется ли тебе что это только чуть-чуть сильнее чем «не будучи человеком с интернетом в России»? А то что пользователь ограничил какому-то более-менее узкому кругу (френдам) — то и не видно через эти методы.

  • Ответить

    > у возможности выкачать такой огромный массив информации есть подводные камни. Мы про них не знаем. Еще раз гхм. Так они есть или нет? Откуда утверждение что они есть если «мы про них не знаем»?

  • Ответить

    Юра, я апи вконтакта (как и самим вконтактом, к счастью) не пользовался. Но, почитав описание проблемы и комментарии друзей Ашманова у тебя в ФБ, пошел смотреть доку по апи. Может я чего-то не понял, но, судя по описанию, я не могу сделать просто GET запрос из браузера. Мне нужен secret, чтобы подписать запрос. А secret генерируется при заведении приложения во вконтактике. Для того, чтобы завести приложение, уверен, нужно иметь акк. Таким образом, ограничение на уровень доступа «только пользователям ВКонтакте» выполняется, так как запросы могут делать только приложения, а у приложений есть автор с акком во вконтактике. OAuth тут вообще, кажется, ни при чем, т.к. это делегирование прав пользователя приложению, насколько я понимаю.

  • Ответить

    Проблема с необдуманным выкладыванием своей жизни в паблик есть, конечно. Наверняка каждый слышал истории типа «я все выкладывал и выкладывал, а потом мне сказали, что все это видно, и я все удалил». Просто у каждого человека свои представления о том, что произойдет с информацией, которую он отдает. Например, он думает, что ее увидят только друзья. Или только члены семьи. Или никто, пока не спросит разрешения. Это вопрос веры. И помним, что в настройки 99% людей не лезет, поэтому особое значение имеют настройки по умолчанию. Значимость этой проблемы принижает только то, что личная жизнь основной массы людей никому не нужна (хотя, если станет нужна…) Для рекламного таргетинга и без этого возможностей вроде бы много. И даже про тех, кто лично рассматривает каждую cookie и решает, принимать или нет, все равно все будет знать DPI. Так что не спрятаться-не скрыться. «Не будучи юзером ВК» — это не ограничение, конечно. И я повторюсь, даже без API никто не запрещает парсить страницы юзеров, так что какая разница.

  • Ответить

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

  • Ответить

    > Пост про настройки приватности не соответствующие действительности. Серьезно? https://api.vk.com/method/friends.get?user_id=6384915&v=5.0&fields=city,domain Ну вот например аккаунт со скрытым списком френдов. Владелец посчитал что хорошо их не показывать. И в ответе в api их нет. Пост про несоответствие действительности не соответствует действительности.

  • Ответить

    Владимир Ермаков, прочитайте внимательно, пожалуйста. Речь о пункте «кому в интернете видна моя страница». Если скрыть все по отдельности — да, тогда ничего не будет, многие так делают?

  • Ответить

    Спасибо за совет. Только я не понял к чему он. Ответ на вопрос «кому видна моя страница» довольно простой — она видна неограниченному кругу людей, если не предприняты специальные действия по ограничению этой видимости по воле владельца. Это относится к любой «моей странице», в каком бы виде она не существовала — страница в соцсетях, страница сайта, далее везде.

  • Ответить

    Владимир Ермаков, Спасибо за пример! Действительно, вызов работает даже для юзера, страницу которого нельзя увидеть из браузера. При этом на http://vk.com/page-1_2369497 указано, что sig — обязательный параметр. Вообще, сейчас начинаю смутно припоминать, что это же давняя проблема Вконтакта, когда ограничения на видимость разных сущностей сущестуют отдельно друг от друга. И был какой-то неслабый шитсторм, когда у людей повылезали приватные фотоальбомы, а администрация Вконтакта объясняла, что пользователи сами виноваты в том, что ограничивали видимость то ли аггрегирующей альбомы страницы, а не каждого альбома отдельно, то ли чего-то такого. Но суть была такая же — данные уплывают, Вконтакте отвечает, что ССЗБ.

  • Ответить

    > давняя проблема Вконтакта В v5 ничего такого не обнаруживается. Результат, возвращаемый методами, не требующими access token, точно соответствует настройкам приватности, заданным пользователем-владельцем для объектов, к которым относится данный метод. Возможно, какие-то неведомые косяки там есть, кто не без греха, но в целом все это выглядит более чем разумно и стройно. Я всегда ругался на авторов всех без исключения api, но сейчас вот утверждаю — нет, не все до единого api проектировали и писали [вырезано цензурой 4 раза]. Хорошие api — существуют. Покажите мне авторов api vk — каждому налью по стакану, а то и по несколько. Можно считать это публичной офертой.

  • Ответить

    Владимир, ну это может быть не проблема именно API, а проблема дизайна разграничения доступа-видимости и UI самого Вконтакта. Проблема же понятна: люди скрывают всё страницу, а не данные по отдельности. При этом сами данные торчат в интернет. И высосать граф может кто угодно. О чем, как теперь становится понятно, и написано в статье.

  • Ответить

    Проведём мысленный эксперимент: Пользователю, который взводит селектор «кому видна моя страница в интернете» на «только пользователям ВКонтакте» показывается ссылка на сайт openapivkontakteexample.com, где предлагают ввести его данные и узнать анкетные данные. Без логина, без регистрации, без SMS. Как вы думаете, какой будет реакция пользователя? Roem.ru не юзерский ресурс, я понимаю, что мы все привыкли вертеть пользователя и его данные так, как хотим. Однако такие вещи, по моему скромному мнению, как раз и приводят к тому, что Рунет пытаются контролировать снаружи, а не какой-то саморегулирующейся организацией. О качестве этих внешних управляющих, которые спокойно выкатывают на боевое законодательство альфа-версию законов — вы знаете.

  • Ответить

    Юрий, тут надо и с другой стороны посмотреть — чего хочет юзер. Скажем, в прошлом-позапрошлом году была эпидемия псевдосервисов «узнай, кто заходил на твою страничку ВКонтакте». Несмотря на все старания ВК разъяснить, что не может такой штуки быть, люди отправляли и отправляли платные смс — а главное, получали правдоподобный результат. Важный момент — многие остались довольны и даже не поняли, что их развели. Насколько можно прикинуть, некоторые люди заработали вполне себе миллионы рублей. То есть юзер, к сожалению — он как ребенок, если есть какое-то направление, куда можно бежать, он туда бежит. Я не думаю, что это волнует кого-то из тех, кто пытается контролировать Рунет. Они скорее из другого исходят: «Чего-то там эти распоясались, информацией обмениваются, в группы собираются.»

  • Ответить
    Альтер Эго

    Для кого эта статья? Для тех чудиков, что постят фотки омлетиков в инстаграм и прочие соцсети эта статья — как об стенку горох. Те, кто всё понимает, понимает это и без вас, уважаемый автор статьи. И про них ничего не найдёшь в сети.

  • Ответить

    «Дырку» оперативно закрыли, но при этом создали головняк некоторым разработчикам приложений для ВК. Раньше я делал users.get с сервера, по трем причинам: 1) Это быстрее, чем вызвать с клиента. 2) Это надежнее в плане того, что пользователь не сможет подделать URL фото, передав его с клиента. Поддельный URL может содержать, например, порнографию, а не аватар пользователя. 3) Поддельный URL может содерать не фото, а какой-нибудь swf, который может быть использован в «хакерских» целях. Такое тоже было. После фикса «дырки» users.get с сервера возвращает только имя пользователя и его пол. Как это можно исправить (не ломая при этом фикс «дырки»)? Два способа: 1) Разрешить вызывать users.get с сервера, при условии передачи клиентского access_token. Так сделано на ОК, ММ и Фейсбуке. 2) Подписывать секретным ключом приложения ответ API на users.get. Тогда разработчик сможет безопасно использовать эти данные, переданные с клиента на сервер.