Кражу cookies при помощи xss

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

Неточная идентификация[ править править код ] Если на компьютере используется более одного браузера, то, как правило, каждый имеет отдельное хранилище для cookie. Поэтому cookie идентифицируют не человека, а сочетание учётной записи , компьютера, и браузера. Таким образом, любой человек, который использует несколько учётных записей, компьютеров или браузеров, имеет несколько наборов cookie. Во время нормальной эксплуатации сервер и браузер пользователя постоянно обмениваются cookie. Cookie могут быть украдены другим компьютером, читающим трафик сети. Сетевой трафик может быть перехвачен не только его отправителем и получателем особенно в публичных сетях Wi-Fi. Этот трафик включает в себя и cookie, передаваемые через незашифрованные HTTP-сессии. Там, где сетевой трафик не шифруется, злоумышленники могут прочесть сообщения пользователей сети, в том числе их cookie, используя программы, называемые снифферами.

The Web Application Security Consortium

XSS атака Москва г. Москва, ул. Нобеля 7, п. Как работает межсайтовый скриптинг Основная цель межсайтового скриптинга — кража cookies пользователей при помощи встроенного на сервере скрипта с дальнейшей выборкой необходимых данных и использованием их для последующих атак и взломов.

Злоумышленник осуществляет атаку пользователей не напрямую, а с использованием уязвимостей веб-сайта, который посещают жертвы, и внедряет специальный JavaScript. В браузере у пользователей этот код отображается как единая часть сайта. При этом посещаемый ресурс по факту является соучастником XSS-атаки. Если сравнивать с SQL-инъекциями, то XSS безопасен для сервера, но несет угрозу для пользователей зараженного ресурса или страницы.

Однако, если к злоумышленнику попадут cookies администратора, можно получить доступ к панели управления сайтом и его содержимому. Методика атаки через XSS Запуск вредоносного кода JavaScript возможен только в браузере жертвы, поэтому сайт, на который зайдет пользователь, должен иметь уязвимость к XSS.

Для совершения атаки злоумышленник изначально проверяет ресурсы на наличие уязвимостей через XSS, используя автоматизированные скрипты или ручной режим поиска. Обычно это стандартные формы, которые могут отправлять и принимать запросы комментарии, поиск, обратная связь.

Проводится полный сбор страниц с формами ввода, и каждая сканируется на наличие уязвимостей. В противном случае система отобразит вам страницу с результатами поиска. Основные популярные CMS уже давно лишились подобных проблем, но из-за возможности расширения функционала за счет модулей и плагинов, создаваемых сторонними разработчиками, шансы на использование уязвимостей XSS возрастают в разы, особенно в Joomla, DLE, Bitrix, Wordpress.

Еще один возможный вариант поиска — использование страниц, которые обрабатывают GET-запросы. Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае. Общая классификация XSS Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.

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

Каждый раз при обращении к сайту выполняется заранее загруженный код, работающий в автоматическом режиме. В основном таким уязвимостям подвержены форумы, порталы, блоги, где присутствует возможность комментирования в HTML без ограничений. Вредоносные скрипты с легкостью могут быть встроены как в текст, так и в картинки, рисунки. Отраженные XSS непостоянные.

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

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

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

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

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

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

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

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

Безопасная обработка данных должна выполняться в коде не только на стороне вашего web-сервера, но и на стороне пользователя клиента. Если используете популярные CMS, например Wordpress, Bitrix, Joomla, регулярно обновляйте версии движка и всех установленных модулей и плагинов. По умолчанию большинство самых распространенных систем для управления сайтов защищены от использования XSS, а вот сторонние плагины из непроверенных источников могут содержать уязвимости.

Голосов: 8, Рейтинг: 4.

ПОСМОТРИТЕ ВИДЕО ПО ТЕМЕ: Steal Cookies - XSS POC

По сути, каждая cookie - это пара: название параметра и его значение. При необходимости добавляем еще подобные строчки. Так как целью моей не является кража чужих ящиков или получения Но теоретически можно подменить свои cookies на чужие и Но вот если зайти в почту, то сообщение «XSS» есть и у Меня в Скажите, а если вам придет письмо от неизвестно отправителя и с темой «Крик о помощи».

XSS это возможность злоумышленника определенным образом ссылку на возможные варианты смотрите в конце статьи интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении. Пассивная и активная Существует два типа XSS уязвимостей — пассивная и активная. Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны. Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника. К счастью, на большинстве ресурсов время жизни сессии ограничено. Кража данных из форм Ищем форму через, например, getElementById и отслеживаем событие onsubmit.

Тестирование веб-сервисов Deface сайта можно сделать, если вы получили доступ к ftp, залили shell и тд, но также это можно сделать с помощью обычной XSS.

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

Например, браузер может быть стандартным веб-браузером клиента или браузер объекта, встроенного в программном продукте, например, браузер в Winamp, RSS Reader, или почтовый клиент. Когда злоумышленник получает браузер пользователя может выполнить код, который будет работать в контексте безопасности или зоне хостинг веб-сайта. При таком уровне привилегий, код можно прочитать, изменить и передать конфиденциальные данные доступные в браузере. Межсайтовый скриптинг может похищать данные пользователя Cookie кражи , их браузер перенаправляется в другое место. Cross-Site Scripting атаки с использованием кросс-сайтовых сценариев по существу ставят под угрозу доверительные отношения между пользователем и веб-сайтом. Приложения, использующие браузер имеют экземпляры объектов для загрузки содержимого из файловой системы, могут выполнять код в зоне локального компьютера и приводят к нарушению безопасности системы. Нестойкие атаки и основанные на DOM атаки требуют, чтобы пользователь или посетил специально обработанную ссылку, пропитанную вредоносным кодом, или посетил вредоносную веб-страницу, содержащую веб-форму, которая перенаправляет на уязвимый сайт и предпринимает атаку. В таком случае форма может быть представлена автоматически без знания жертвы например, при помощи JavaScript. При щелчке по вредоносной ссылке или представлении вредоносной формы, на полезную нагрузку XSS отреагирует, интерпретирует браузер пользователя и выполнится нужный код.

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

XSS атака Москва г. Москва, ул.

Поставим себя на место злоумышленника. Нужно чтобы пользователь кликнул по ссылке.

.

.

.

.

.

.

ВИДЕО ПО ТЕМЕ: Basic XSS Guide #1 - Alert() - Redirection - Cookie Stealing
Похожие публикации