С учетом распространенных среди разработчиков мифов и заблуждений о межсайтовом выполнении сценариев, нет ничего удивительного в том, что он и по сегодняшний день входит в число наиболее распространенных проблем безопасности веб-приложений.
Должен признаться, что чтение комментариев на Хабре к практически любым постам, описывающим очередную XSS на каком-либо популярном сервисе или сайте, способно повергнуть в уныние любого, кто так или иначе связан с безопасностью веб-приложений. С учетом распространенных среди разработчиков мифов и заблуждений о межсайтовом выполнении сценариев, нет ничего удивительного в том, что он и по сегодняшний день входит в число наиболее распространенных проблем безопасности веб-приложений: согласно данным отчета Positive Technologies за 2010-2011 годы , XSS были подвержены 40% проанализированных веб-приложений, а из отчета Firehost за второй квартал 2012 года следует, что XSS составила 27% от числа зарегистрированных хостером атак.
И поскольку, заминусовать этот пост можно и за один только его заголовок, то поспешу пояснить: межсайтовое выполнение сценариев действительно не является уязвимостью, но только потому, что оно является атакой. В чем разница, почему это важно, как со всем этим бороться и какие еще мифы и заблуждения распространены об XSS — читаем под катом.
Все заблуждения сформулированы в заголовках, порядок произвольный, любые совпадения примеров конкретных атак и уязвимостей с реально существующими — случайны и непреднамеренны.
Как уже было сказано выше, это не так. Межсайтовое выполнение сценариев является атакой, причем и по версии OWASP , и по версии WASC (хотя читать мануалыклассификации у нас конечно не принято). Иными словами, XSS является лишь одним из возможных способов эксплуатации уязвимости определенного класса. Например, следующий код содержит только одну уязвимость, но подвержен атакам сразу нескольких классов:
Во-первых, данный код подвержен атаке злоупотребления функционалом перенаправления , ни имеющей никакого отношения к XSS. Во-вторых, запросом вида легко и непринужденно реализуется, собственно, межсайтовое выполнение сценариев. В третьих, если веб-приложение будет развернуто в окружении, которое использует канонический PHP версии ниже 4.4.2 или 5.1.2, либо ряд сторонних реализаций PHP, то данный код будет также уязвим и к атакам расщепления и сокрытия HTTP-ответов (а защищенность веб-приложения не должна зависеть от защищенности окружения настолько, насколько это возможно).
Разница между уязвимостью и атакой в том, что устранение уязвимости позволяет избавится и от всех эксплуатирующих ее атак, а вот устранение конкретной атаки — от самой уязвимости не избавляет. Простой пример: если мы, рассматривая данную XSS как уязвимость, устраним ее с помощью URL-кодирования каждого фрагмента переданного скрипту URL’а, то на возможность проведения атаки злоупотребления функционалом перенаправления это совершенно не повлияет — злоумышленник по-прежнему будет иметь возможность перенаправить пользователя на произвольный, корректно сформированный URL. Вместо того, чтобы бороться со следствиями, мы должны побороть причину, а именно — устранить ту самую, единственную уязвимость, которая позволяет проводить все эти атаки. В данном случае, уязвимость заключается в том, что GET-параметр url не обрабатывается должным образом ни при передаче в скрипт веб-сервером, ни перед его использованием в выходных данных. Прошу любить и жаловать: данная уязвимость относится к классам неправильной обработки входных и выходных данных и является самой распространенной уязвимостью, благодаря которой возможно проведение большинства известных на сегодняшний день атак. Следовательно, чтобы устранить эту уязвимость, необходимо обеспечить правильную и достаточную обработку данных обоих типов, при этом очевидно, что в данном случае, URL-кодирование достаточным не является. Мы еще вернемся к этому вопросу чуть позже.
«Когда тебе станет совсем скучно — затей с коллегами спор о терминологии» (С). Но тут уже вопрос принципиальный, простите. Я не знаю, благодаря кому именно, русскоговорящим разработчикам была навязана эта гейская классификация (есть мнение, что ее распространению способствовала статья об XSS в русской Википедии), но подобное разделение, хотя и имеет место, тем не менее совершенно бесполезно, т.к. не отражает всех свойств конкретной XSS, реально значимых с точки зрения анализа защищенности веб-приложения и устранения в нем соответствующих уязвимостей. Традиционно и ошибочно принято считать, что XSS может быть пассивной (требующей передать пользователю специально сформированную ссылку и убедить его по ней пройти) и активной (хранящейся на сервере и срабатывающей без лишних телодвижений со стороны пользователя). Однако же, рассмотрим следующий пример: допустим, что в движке Хабра есть уязвимость, позволяющая выйти лишь за рамки атрибута src тега <a> в тексте хабратопика, но не позволяющая выйти за рамки тега. Понятно, что данную уязвимость, можно использовать для проведения атаки XSS, определив обработчик наведения курсора на ссылку, щелчка по ней и т.п. Вопрос: пассивной или активной является такая атака? С одной стороны, ссылка хранится на сервере, ее не нужно доставлять атакуемым пользователям, вроде бы активная. С другой, для успешной атаки необходимы дополнительные действия пользователя, что характерно исключительно для пассивных атак. Парадокс? Именно поэтому, XSS принято классифицировать по двум критериям: вектору и способу воздействия. Второй как раз и является теми самыми «активная/пассивная», однако с более внятными формулировками: активной является XSS не требующая каких-либо лишних действий со стороны пользователя с точки зрения функционала веб-приложения, в отличии от пассивной. А по вектору воздействия, XSS делится на отраженную (возвращаемую сервером в ответ на тот же запрос, в котором был передан вектор эксплуатации), устойчивую (сохраняемую на сервере и доступную во всех ответах на один и тот же запрос, не содержащий вектор эксплуатации) и основанную на объектной модели документа (проведение которой возможно без отправки каких-либо запросов на сервер). Таким образом, правильным ответом на вопрос о классификации приведенного примера атаки является: «устойчивая-пассивная».
Очевидно, что это не совсем так. Для того, чтобы выполнить произвольный сценарий в браузере жертвы, достаточно было бы заманить его на специально подготовленную страницу, размещенную на контролируемом злоумышленником сервере. XSS же направлена не просто на выполнение произвольного сценария, а на его выполнение в контексте источника конкретного сайта с целью обхода политик единого источника ( Same Origin Policy, SOP ) и, в результате, получения доступа к данным и функционалу клиентской части веб-приложения в рамках пользовательской сессии и с правами ее пользователя. Это атака, в первую очередь, на веб-приложение, реализующая угрозу именно в нем, а не в браузере пользователя.
На конференции PHDays 2012 , во время секции ” Безопасность Web 2.0. Продвинутые техники ” ее ведущий Андерс Рьянчо задал аудитории простой вопрос: «поднимите руки те, кто знает что такое политики единого источника». Как присутствовавший там, готов подтвердить: руки подняло от силы треть аудитории, состоящей целиком и полностью из веб-разработчиков и экспертов по безопасности. На видео этот исторический момент есть, жаль только, что вся аудитория в этот момент не попала в кадр. Честно говоря, я не совсем понимаю, как можно быть разработчиком или экспертом по безопасности веба и не знать об основном механизме защиты современных браузеров, поэтому для себя решил, что народ просто постеснялся поднимать руку перед иностранцем. Однако, даже простой обзор этих политик — задача не на пару абзацев, поэтому всех интересующихся могу направить во вторую часть электронной книги ” Browser Security Handbook ” Михаля Залевски. Еще глубже эта тема охвачена в ” The Tangled Web ” того же автора. Обе кстати, рекомендуются к прочтению всеми, кто имеет отношение к веб-разработке или анализу защищенности веб-приложений.
Не совсем понятно, с чего это вдруг атака на веб-приложение (см. выше) стала проблемой пользователя, а не владельца или разработчиков этого приложения. Тут скорее вопрос в том, какова их позиция в вопросах обеспечения защищенной работы пользователей. Риски, связанные с реализацией XSS, действительно зачастую носят репутационный характер. Однако же, если говорить о том, насколько серьезными могут быть последствия успешной XSS в отношении пользователей, рекомендую посмотреть доклад моего коллеги Дениса Баранова «Root через XSS», представленный на конференции ZeroNights 2011 и посвященный получению привилегированного доступа к компьютерам веб-разработчиков через атаку межсайтового выполнения сценариев (к сожалению, доступны только слайды , но общая идея, думаю будет понятна и без видео). Насколько сильным будет ущерб, нанесенный репутации ресурса, если с помощью XSS на его клиентскую часть, атакующие получат неограниченный доступ к компьютерам его пользователей? С учетом того, что средства, превращающие проведение массовой XSS в скрипткиддинг уже давно есть: взять, хотя бы, тот же BeEF . Кроме того, не стоит забывать также и о том, что с точки зрения XSS, администраторы веб-приложений являются точно такими же пользователями, как и все остальные (чьими проблемами якобы и является борьба с этим классом атак, ага).
Не только. Например, одним из способов применения уже упомянутой атаки расщепления HTTP-ответа, является внедрение HTML-документа (а следовательно и клиентских сценариев, если это необходимо) прямо в HTTP-заголовок, подверженный инъекции. Злоупотребление функционалом перенаправления вполне может быть использовано для редиректа браузера на URL’ы, использующие схему data: или javascript:. Более того, возможно и более неочевидное использование атаки на перенаправление с целью проведения XSS. Допустим, в нашем веб-приложении, помимо точки входа с уже рассмотренной проблемой перенаправления (доступной по адресу /redirect.php?url=) есть также точка со следующим кодом:
он добивается успешной XSS для пользователей этих двух браузеров. Разумеется, то же самое касается и возможности осуществления инъекции непосредственно в определения стилей.
UPD: Как подсказали в комментариях, -moz-binding не так давно приказал долго жить , увы.
Большинство векторов XSS, доступных для атакующего в тех или иных браузерах и версиях HTML, перечислено на сайте HTML5 Security Cheatsheet . Там же можно найти и исчерпывающий ответ на вопрос, озвученный в заголовке этого раздела.
В первую очередь, необходимо выявить все потоки данных, целостность или аутентичность которых не контролируется внутри рассматриваемого компонента веб-приложения. Под компонентом веб-приложения, как правило (хотя и не всегда), подразумеваются элементы его серверной или клиентской части, выполняющиеся в рамках одного процесса ОС.
В приведенном выше примере, недоверенными (и единственными) данными является параметр url, получаемый из строки GET-запроса.
Как можно ближе к месту появления таких данных в компоненте, необходимо обеспечить их приведение к ожидаемым типам. В статических языках это реализуется, собственно, приведением к типу или созданием экземпляра этого типа на основе десериализации или парсинга проверямых данных. Более того, в большинстве современных фреймворков, построенных на статических языках, этот функционал уже реализован в механизмах биндинга параметров запроса к объектам модели. В динамических языках все несколько грустнее, т.к. по сути там можно говорить только об имитации приведения (которую, тем не менее, необходимо осуществлять). Тем не менее, грамотная реализация даже такой условной типизации даст гарантию, что по нашему компоненту будут гулять данные именно тех типов, на работу с которыми он рассчитан. Вся дальнейшая работа с данными внутри компонента, должна осуществляться только через созданные на основе входных данных объекты. Важно помнить, что основным принципом этапа типизации является как можно меньшее количество объектов строкового типа на его выходе. URL, адреса электропочты, дата, время и т.п. после типизации должны представлять из себя объекты конкретных типов, отличных от строкового. В виде строк должны быть представлены только те данные, которые на самом деле являются строкой, т.е. которые действительно могут содержать произвольный полноалфавитный текст.
В нашем случае, достаточно воспользоваться функцией parse_url() и реализовать проверку появления в элементах полученного массива лишних знаков подчеркивания, означающих наличие в исходном URL запрещенных символов (соответственно, завершать типизацию с ошибкой, если были обнаружены такие символы или если parse_url() и вовсе вернула FALSE). В том случае, если в полученном массиве будет присутствовать ключ query, необходимо также обеспечить его разбор с помощью parse_str() и заменить на получившийся в итоге ассоциативный массив с параметрами запроса.
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
fullz sites 2021 best site for fullz