Xss предупреждение noscript что делать

Если страница имеет уязвимости XSS, на экране появится уведомление такого же плана, как и в первом случае.

Для поиска «дыр» на сайте существует огромное количество готовых скриптов и запросов, и если ни один из них не подходит, значит ресурс надежно защищен от подобных атак.

Общая классификация XSS

Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.

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

Отраженные XSS (непостоянные). В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:

DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:

Виды XSS по способу взаимодействия

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

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

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

Как проверить сайт на наличие уязвимостей XSS и защитить его

Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.

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

Несколько советов по предотвращению использования XSS на вашем сайте:

Источник

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

XSS – это тип уязвимости программного обеспечения, свойственный Web-приложениям, который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями

Автор: Ahmed Elhady Mohamed
Перевод: www.SecurityLab.ru

Введение

В Wikipedia содержится следующее определение для XSS: «Межсайтовый скритинг (XSS) – это тип уязвимости программного обеспечения, свойственный Web-приложениям (путем обхода ограничений безопасности браузера)», который позволяет атакующему внедрить клиентский сценарий в web-страницы, просматриваемые другими пользователями. Уязвимость межсайтового скриптинга может использоваться атакующим для обхода таких механизмов безопасности как политика единства происхождения. Согласно данным Symantec за 2007 год, XSS уязвимости составили 80.5% от общего числа брешей, обнаруженных на сайтах. Рейтинг опасности таких уязвимостей может варьироваться в зависимости от важности данных, хранящихся на уязвимом сайте и существующих механизмов защиты».
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets – таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.

XSS опасен

XSS действительно является уязвимостью высокой степени опасности, поскольку она может использоваться для изменения DOM-модели сайта, что в свою очередь позволит похитить учетных данных администратора сайта и получить полный контроль над уязвимым приложением.

Какие цели преследует атакующий?

Типы XSS

Существует три типа XSS уязвимостей:

Далее мы подробно обсудим каждый их этих типов.

Постоянный (хранимый) XSS

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

Демонстрация хранимого XSS

Ниже приведен пример PHP сценария, уязвимого к хранимому XSS:

В коде не осуществляется корректная обработка параметров “message” и “name” перед сохранением данных в таблицу guestbook. Таким образом, при выводе этих данных в браузер пользователя существует возможность выполнение вредоносного JavaScript кода.

В демонстрационных целях при попробуем проэксплуатировать эту уязвимость на примере DVWA.

После отправки этой формы можем посмотреть на выполнение нашего JavaScript кода:

Непостоянный (отраженный) XSS

Согласно Wikipedia, непостоянный XSS является наиболее распространенным типом XSS. Непостоянный XSS имеет место, когда данные, предоставляемые Web-клиентов в строке запроса или HTML форме, используются для генерации ответа клиенту без обработки этих данных.

Демонстрация отраженного XSS

Ниже приведен пример кода, уязвимого к отраженному XSS:

Как видно из примера, очистка данных не осуществляется для параметра “name” перед его выводом в браузера пользователя. Таким образом, если в него внедрить JavaScript сценарий, это сценарий будет выполнен.

Мы воспользуемся приложением DVWA для демонстрации этой уязвимости:

Давайте внедрим код “” в элемент формы:

XSS в DOM-модели

Таким образом, XSS возникает непосредственно внутри JavaScript сценария. Примером к этой уязвимости может служить сценарий, который получает данные из URL через location.* DOM или посредством XMLHttpRequest запроса, и затем использует их без фильтрации для создания динамических HTML объектов.

Демонстрация XSS в DOM-модели

Для примера мы воспользуемся сценарием, который позволяет пользователю выбрать язык интерфейса. Язык по умолчанию передается посредством URL в параметре “default”. Обработка языка интерфейса осуществляется следующим образом:

Доступ к этой странице осуществляется по следующему адресу: http://www.some.site/page.html?default=French

Для эксплуатации XSS уязвимости в DOM-модели мы выполним следующий запрос:

Исходный JavaScript сценарий не ожидает, что входные данные могут содержать HTML код, поэтому просто выводит их на странице. Затем браузер обрабатывает этот код и выполняет сценарий alert(document.cookie).

Теперь давайте рассмотрим некоторые методы эксплуатации уязвимостей межсайтового скриптинга.

Методы эксплуатация XSS

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

Метод 1: замена «

Стоит отметить, что использование alert(“XSS”) для тестирования XSS нежелательно, поскольку большинство сайтов блокируют сценарии по ключевому слову «XSS».

Метод 2: использование magic quotes

Применяя этот метод, разработчик использует фильтрацию функции «addslashes()» языка PHP, которая добавляет символ «\» перед любым специальным символом. Таким образом, код, написанный на JavaScript, не будет выполнен.

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

Как злоумышленник может украсть файлы куки?

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

Для демонстрации мы создадим сценарий collect_cookie.php на языке PHP, который будет размещен на сервере любой компании, предоставляющей хостинг. После этого будет внедрен код на языке JavaScript, который будет похищать файлы куки и передавать их на наш сайт. Когда php-файл получит данные, он сохранит их в файл stolen_cookies.txt.

Чтобы похитить файлы куки необходимо наличие трех составляющих:

Первая составляющая: скрипт collect_cookie.php

Ниже приведен PHP-скрипт, который будет использован для сбора файлов куки и их запись в файл stolen_cookie.txt

Пожалуйста, нажмите href=»http://www.google.com/»>здесь, чтобы перейти на предыдущую страницу’;
?>

Разберемся, что делает данный скрипт:

В данной строке происходит сохранения значения переменной «cookies» из GET-запроса в переменную «collectedCookie»
$date=date(«l ds of F Y h:i:s A»);

Здесь происходит сохранение времени соединения, по нему можно определить время кражи cookies.

Сохранение user_agent жертвы для осуществления будущих атак, если они потребуются.

В этой строке происходит создание файла stolen_cookie.txt, в котором будут храниться похищенные данные.

fwrite($file,»DATE:$date || USER AGENT:$user_agent || COOKIE:$collectedCookie \n»);

Сохранение данных в следующем формате: (“ДАТА: || USER AGENT || COOKIE”)

echo ‘Извините, сайт находится в состоянии разработки. Пожалуйста, нажмите href=»http://www.google.com/»>здесь, чтобы перейти на предыдущую страницу’;

Осуществляется вывод на экран текста (“Извините, сайт находится в состоянии разработки”) и ссылки, ведущая на страницу google.com.
Первый шаг к сбору информации о cookies закончен.

Вторая составляющая: JavaScript-код

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

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

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

В итоге украденные файлы куки окажутся в файле stolen_cookie.txt. По ссылке ниже доступно видео, демонстрирующие как можно украсть файлы куки: http://www.youtube.com/watch?v=ZeLyJnhz4ak

Что такое BeEF?

BeEF (сокращение от Browser Exploitation Framework) – платформа для эксплуатации браузеров. BeEF используется для разнообразных атак на компьютеры пользователей с целью их захвата. Наличие этого инструмента значительно облегчает работу, поскольку многие рутинные операции уже автоматизированы.

Поскольку операция захвата компьютера-зомби автоматизирована, с помощью приложения beef (Browser Exploitation Framework) можно захватывать множество компьютеров-зомби (так называют компьютеры, которые находятся внутри ботнета).

На официальном сайте проекта BeEF содержится следующее описание программы: «Browser Exploitation Framework (BeEF) – это мощная профессиональная утилита. В BeEF реализованы последние методы атак, которые используют специалисты в области тестов на проникновение с богатым практическим опытом атак на клиентские приложения. В отличие от остальных платформ безопасности, BeEF ориентирован на эксплуатацию уязвимостей в браузерах для получения контроля над компьютером. Данный проект разрабатывается исключительно для легальных исследований и тестов на проникновение.»

Вы можете загрузить BeEF с сайта проекта http://beefproject.com.

Как использовать BeEF?

После запуска beef-ng на экране отобразиться консоль приложения:

Теперь Вы можете открыть панель управления BeEF, перейдя по ссылке и используя «beef»/«beef» в качестве логина и пароля.

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

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

Обратите внимание на вкладку Commands

Как можно увидеть, существует довольно много эксплоитов, которые можно использовать. Например, можно выбрать модуль misc->alert dialog. Вы можете выбрать такой модуль, какой захотите.

Ниже виден результат. Как мы и ожидали, скрипт выполнился, и появилось окошко с предупреждением.

Как вы видите, процесс полностью автоматизирован. Вам только нужно настроить и запустить модуль. Интеграция beef и metasploit заслуживает отдельного внимания. На вкладке Command Вы можете увидеть модуль metasploit. Зайдите туда и посмотрите, насколько богатый функционал предоставляет модуль metasploit. Вы увидите страницу, на которой можно будет выбрать любой эксплоит из набора metasploit и любую настраиваемую полезную нагрузку.

Дополнительная информация о beef расположена по адресу: https://github.com/beefproject/beef/wiki

Заключение

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

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

Источник

🕵 Примеры атак XSS и способов их ослабления

Межсайтовый скриптинг ( XSS ) – это атака, которая позволяет JavaScript через один сайт работать с другим. XSS интересен не из-за технической сложности, а скорее потому, что он эксплуатирует некоторые из основных механизмов безопасности браузеров и из-за огромной распространенности.

Background

Появление этих возможностей привело к тому, что браузеры не только визуализируют HTML, но и вмещают в памяти в качестве API для разработчиков представление, называемое объектной моделью документа (DOM). DOM предлагает древовидную структуру тегов HTML, а также доступ к файлам cookie для получения состояния. Со временем модель превратилась из предназначенной преимущественно для чтения структуры в структуру read-write, обновление которой приводит к повторному рендерингу документа.

Политика Same-Origin отлично помогает смягчать атаки на статические сайты, как показано на рисунке выше. Однако с атаками на динамические ресурсы, принимающие пользовательский ввод, ситуация немного сложнее из-за смешивания кода и данных, которая позволяет злоумышленнику выполнять контролируемый ввод в исходном документе.

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

Примеры

Рефлективные атаки XSS

Ниже можно увидеть простое веб-приложение на Go, которое отражает свой ввод (даже если это вредоносный скрипт) обратно пользователю. Вы можете использовать это приложение, сохранив его в файле xss1.go и запустив go run xss1.go.

Фрагмент 3: Пример веб-приложения с рефлективной (отраженной) XSS-атакой.

Чтобы увидеть XSS-атаку, перейдите по уязвимому URL-адресу ниже.

Взгляните на источник: сервер вернул документ, который выглядит примерно так, как показано во фрагменте 4. Обратите внимание, как смешение кода и данных позволило произойти этой атаке.

Фрагмент 4: Пример вывода уязвимого для XSS веб-приложения.

Хранимые XSS-атаки

Ниже приведен простой чат, который иллюстрирует этот вид атак. Вы можете сохранить приложение в файле xss2.go и запустить с помощью команды go run xss2.go.

Фрагмент 5: Хранимая XSS-атака.

Атака делится на две фазы:

XSS-атаки на основе DOM

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

Фрагмент 6: Пример веб-приложения с XSS-атакой на основе DOM.

Фрагмент 7: Еще один пример атаки XSS на основе DOM.

Связанные направления атак

Content-type

Всему виной неправильная настройка типа содержимого ответов HTTP. Это может произойти как на уровне бекенда (ответ имеет неверный набор заголовков Content-Type), так и при попытке браузера проснифферить тип MIME. Internet Explorer был особенно восприимчив к этому, и классическим примером является служба загрузки изображений: злоумышленник может загрузить JavaScript вместо картинки. Браузер видит, что тип контента был установлен на image/jpg, но пейлоад содержит скрипт – он выполняется, что приводит к атаке XSS.

Urlschemes

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

Чтобы опробовать этот тип атаки, можно сохранить приложение в файле xss4.go, запустить командой go run xss4.go и перейти по ссылке http://localhost:8080?link=javascript:alert(1).

Фрагмент 8: XSS-атака, введенная через схему URL-адресов.

Избавление

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

Валидация входных данных

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

Хороший тон написания приложений на Go состоит в том, чтобы не иметь никакой логики приложения в обработчиках запросов HTTP, а вместо этого использовать их для анализа и проверки входных данных. Затем данные отправляются в обрабатывающую логику структуру. Обработчики запросов становятся простыми и обеспечивают удобное централизованное расположение для контроля правильности очистки данных.

На фрагменте 9 показано, как можно переписать saveHandler для приема символов ASCII [A-Za-z\.].

Фрагмент 9: Пример использования обработчиков HTTP-запросов для проверки данных.

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

Экранирование

Одно и то же приложение может быть гораздо безопаснее (даже если в него была произведена инъекция кода), если экранировать все небезопасные выходные данные. Именно это делает пакет html/template в Go. Использование языка шаблонов и контекстно-зависимого синтаксического анализатора для экранирования данных до их визуализации уменьшит вероятность выполнения вредоносного кода.

Ниже приведен пример использования пакета html/template. Сохраните приложение в файле xss5.go, а затем выполните командой go run xss5.go.

Фрагмент 10: Использование экранирования для устранения хранимых XSS-атак.

Откройте консоль браузера и посмотрите на элемент li в DOM. Интерес представляют два свойства: innerHTML и innerText.

Фрагмент 11: Проверка DOM при использовании экранирования.

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

Content Security Policy

Написание CSP для небольших автономных приложений является простой задачей – начните с политики, которая по умолчанию запрещает все источники, а затем разрешите небольшой их набор. Однако написать эффективный CSP для больших сайтов уже не так просто. Как только сайт начинает загружать контент из внешних источников, CSP раздувается и становится громоздким. Некоторые разработчики сдаются и включают директиву unsafe-inline, полностью разрушая теорию CSP.

Чтобы упростить написание CSP, в CSP3 вводится директива strict-dynamic. Вместо того чтобы поддерживать большой белый список надежных источников, приложение генерирует случайное число (nonce) каждый раз, когда запрашивается страница. Этот nonce отправляется вместе с заголовками страницы и встроен в тег script, что заставляет браузеры доверять этим скриптам с соответствующим nonce, а также любым скриптам, которые они могут загрузить. Вместо того, чтобы вносить скрипты в белый список и пытаться выяснить, какие еще сценарии они загружают, а затем пополнять белый список рекурсивно, вам нужно достаточно внести в белый список импортируемый скрипт верхнего уровня.

Фрагмент 12: Пример CSP, смягчающего XSS-атаку.

Чтобы попытаться использовать приложение, перейдите по ссылке: http://localhost:8080 и попробуйте отправить как и раньше. Эта атака сработала бы и без CSP, но поскольку CSP не допускает inline-скриптов, вы должны увидеть примерно такой вывод в консоли браузера:

Почему сценарий не запустился? Рассмотрим CSP подробнее.

Фрагмент 13: Базовый CSP. Nonce повторно генерируется для каждого запроса.

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

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

Content-Type

Вы должны не только устанавливать свой Content-Type, но и следить, чтобы браузеры не пытались автоматически определить тип контента. Для этого используйте заголовок : X-Content-Type-Options: nosniff.

Virtual doms

Заключение

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

Источник