Попытка атаки через xss битрикс что это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

🕵 Примеры атак 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 трудно искоренить, поскольку приложения становятся все больше и все сложнее. Применяя упомянутые в статье методы, можно сделать жизнь злоумышленников трудной.

Источник

Что такое XSS-уязвимость и как тестировщику не пропустить ее

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

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

Определение

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — довольно распространенная уязвимость, которую можно обнаружить на множестве веб-приложений. Ее суть довольно проста, злоумышленнику удается внедрить на страницу JavaScript-код, который не был предусмотрен разработчиками. Этот код будет выполняться каждый раз, когда жертвы (обычные пользователи) будут заходить на страницу приложения, куда этот код был добавлен. А дальше существует несколько сценариев развития.

Первый: злоумышленнику удастся заполучить авторизационные данные пользователя и войти в его аккаунт.

Второй: злоумышленник может незаметно для жертвы перенаправить его на другую страницу-клон. Эта страница может выглядеть совершенно идентично той, на которой пользователь рассчитывал оказаться. Но вот принадлежать она будет злоумышленнику. Если пользователь не заметит подмены и на этой странице введет какие-то sensitive data, то есть личные данные, они окажутся у злоумышленника.

Третий… да в общем-то много чего еще можно придумать. Почти все, что может JavaScript, становится доступным для злоумышленника. Чуть ниже мы рассмотрим подробнее один из таких примеров. А пока давайте попробуем чуть подробнее обсудить, как именно устроена уязвимость. И почему злоумышленнику удается внедрить свой код в чужое приложение без доступа к его исходникам.

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

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

Как устроена уязвимость?

Прежде всего, как именно удается внедрить на страницу JavaScript-код, которого там раньше не было? И как получается распространить этот код среди других пользователей?

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

Злоумышленник вводит текст (и за одно вредоносный код), который сохраняется на странице. Когда другие пользователи зайдут на эту же страницу, вместе с текстом они загрузят и JavaScript-код злоумышленника. Именно в момент загрузки этот код отработает. Конечно, уязвимость сработает, только если текст при сохранении не будет обезопасен. О том, как это сделать, и почему разработчики иногда забывают об этом, поговорим чуть позже.

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

А пока давайте двигаться дальше.

Почему такие ошибки часто встречаются на веб-проектах?

Суть в том, что браузер не может самостоятельно отличить обычный текст от текста, который является CSS, HTML или JavaScript-кодом. Он будет пытаться обрабатывать все, что находится между тегами

В случае, если страница является уязвимой, после ввода этого кода на странице появится вот такое окошко:

Оно и будет означать, что наш JavaScript-код исполнился и мы нашли XSS-уязвимость.

Итак, вводим код и видим следующее предупреждение:

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

Помните, чуть выше мы с вами заметили, что текст, который мы вводим в поле поиска, отображается в URL в так называемом GET-параметре? Имя этого параметра “q”, а значение — то, что мы вводим в поле поиска. Это сделано для того, чтобы можно было скопировать URL вместе с этой самой строкой поиска и в следующий раз открыть страницу сразу с нужными авторами.

Например, вот такой URL откроет страницу сразу только с книгами Рея Брэдбери: playground.learnqa.ru/demo/xss?q=Рей+Брэдбери

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

Проверим, не забыл ли наш разработчик все учесть тут. Попробуем в GET-параметр “q” подставить тот самый JavaScript-код: https://playground.learnqa.ru/demo/xss?q=

Перейдя по этому URL мы видим, что на странице появилось окошко со значением 123. Но почему?

Все довольно просто. Помните, когда сайт не может найти нужные книги по заданному поисковому запросу, он текст этого поискового запроса выводит в тексте ошибке? Мол, не нашли ничего по запросу “бла-бла”. Вот вместо этого “бла-бла” у нас теперь JavaScript-код с алертом. Разработчик написал валидацию поля ввода и решил, что так он защитил сайт от того, чтобы JavaScript мог оказаться в поисковом запросе. И не стал экранировать текст ошибки. Нам же удалось обойти валидацию через URL, поменяв там значение поискового запроса.

Ради интереса теперь можем вывести значение нашей сессионной cookie, для этого вместо в URL надо подставить другой код:

С этим я уже предоставлю поиграться вам самостоятельно. 🙂

Найдя ошибку, стоит обратиться к разработчикам — они ее исправят.

Способов закрыть ошибку довольно много. Экранировать текст — не единственный из них. Еще можно запретить самому JavaScript видеть некоторые cookie. Для этого у cookie есть специальный параметр “http only”. Если он выставлен в TRUE, JavaScript никак не сможет узнать, что такая cookie вообще выставлена и не сможет ее прочитать и передать злоумышленнику даже в том случае, если ему удастся найти XSS на вашем проекте.

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

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

Вас ждет только полезная и нужная теория без воды и большое количество практических примеров и заданий. Вы будете исследовать множество веб-страниц, напичканных самыми разными уязвимостями. Итоговой работой станет большое исследование либо вашего рабочего проекта, либо одного из веб-приложений таких гигантов как Google, Facebook, Twitter и так далее.

Источник

Cистематическая уязвимость сайтов, созданных на CMS 1С-Битрикс

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

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

Другое дело безопасность конечного продукта, созданного на такой CMS, и самое главное, систематика проявления уязвимостей высокого уровня угроз у этих сайтов. Исходя из нашей практики по обеспечению безопасности сайтов (компания InSafety), а также статистики, которую мы собираем по уязвимостям платформ (CMS), не менее чем у пятидесяти процентов сайтов, созданных на платформе 1С-Битрикс c личными кабинетами пользователей, существует возможность эксплуатации хранимых XSS-атак.

Платформа: CMS 1C-Битрикс 15.0 и выше
Угроза безопасности: хранимая XSS-атака
Систематика: не менее 50% сайтов с личными кабинетами пользователей

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

HTML-код не будет санирован и будет запомнен в имени пользователя «как есть». Скриншот админки сайта:

Этот пример наглядно демонстрирует наличие угрозы безопасности

В предложенной демонстрации существовании угрозы, было показано внедрение HTML кода, а не JS, что предполагает типовая XSS-атака. Это обусловлено тем, что у большинстве сайтов, разработанных на CMS 1C-Битрикс, попытку внедрения JS-кода заблокирует фильтр проактивной защиты.

Внедрение большинства синтаксических тегов HTML кода, проактивной защитой CMS 1C-Битрикс не фильтруется. Такая демонстрация обнаружения уязвимости кода абсолютно безопасна и наглядна. В случае, когда фильтр проактивной защиты 1С-Битрикс по какой-то причине отключен, вышеописанная уязвимость кода позволяет эксплуатировать хранимые XSS-атаки в «классической» реализации.

Уровень угрозы безопасности для сайта от внедрения любого (будь то JS или HTML) несанкционированного кода, как и его вывода без должной фильтрации, крайне высок.

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

Защита от XSS-атаки

Защитить свой сайт от возможности эксплуатации XSS атаки достаточно просто. Для этого следует фильтровать входные и выходные данные путем экранирования символов и преобразования спецсимволов в HTML-сущности. В php это можно сделать с помощью функций htmlspecialchars(), htmlentities(), strip_tags().

Кроме этого следует явно указывать кодировку страниц сайта:

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

Пример для NGINX: (запись в конфигурационный файл)

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

Заключение

Вышеозначенная угроза безопасности на веб-приложения, является наиболее популярной и известной атакой. Про XSS атаки и защиту от них, написано тысячи статей и публикаций.

В практике нашей компании уязвимость к XSS атакам личных кабинетов пользователей была обнаружена осенью 2015 года. Весною 2016 года наша статистика уязвимых сайтов на CMS 1С-Битрикс явно указывала на наличие возможности эксплуатации атаки у более 50% процентов исследуемых сайтов. В апреле 2016 года, понимая, что уязвимость кода в этом разделе носит системный характер, мы передали всю информацию по угрозе безопасности в компанию Битрикс. Сотрудники компании Битрикс приняли информацию, сообщив в обратной связи, что приняли меры, исправив документацию к системе. Несмотря на принятые меры, вышеописанная угроза безопасности для сайтов на 1С-Битрикс остаётся крайне актуальной на сегодняшний день.

Надеюсь, что эта информация будет полезной для разработчиков и владельцев сайтов, созданных на платформе 1C-Битрикс.

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

Источник