Перевод статьи подготовлен в преддверии старта курса «Безопасность веб-приложений».
В этой статье, первой из трех, мы рассмотрим угрозы в области веб-безопасности, а также поговорим о том, как инструменты обеспечения безопасности на стороне клиента справляются с часто упускаемым классом кибератак, примером которого является Magecart. Здесь описаны традиционные способы защиты от угроз в области веб-безопасности, которые основаны на стандартах со стороны клиента, таких как политика безопасности контента и целостность подресурсов. Эти развивающиеся подходы рассматриваются в контексте репрезентативной платформы безопасности на стороне клиента.
Пожалуй, краеугольным камнем кибербезопасности как профессиональной дисциплины является ее непрерывная изменчивость. То есть, как только возникают кибератаки, которые затрагивают аспекты конфиденциальности, целостности или доступности некоторых интернет-ресурсов, для их устранения разрабатываются соответствующие решения. Как только эти решения интегрируются в инфраструктуру скомпрометированного ресурса, появляются новые кибератаки, изобретаются новые решения и цикл замыкается.
В некоторых случаях защитные кибер-решения имеют механизмы, которые предвосхищают новые формы вредоносных атак – и в случаях, когда это срабатывает, рисков в области безопасности удается избежать во множестве сценариев. Например, двухфакторная аутентификация была создана как мера против угадывания пароля, а теперь она является важным компонентом повышения уровня безопасности в разработке новых протоколов сообщения между устройствами Интернета Вещей.
Нигде процесс появления и преодоления угроз не является более очевидным, чем в области веб-безопасности, которую еще называют безопасностью веб-приложений. С учетом того, что ценные активы чаще всего обрабатываются и управляются с помощью веб-интерфейсов, ценность веб-эксплойтов продолжает расти. Одним из следствий этого роста является то, что несмотря на множество технологий защиты веб-ресурсов, растет и разрыв между количеством атак и уровнем защиты.
Основной предпосылкой создания этой технической серии статей является пробел в области веб-безопасности, который появляется из-за того, что большинство приложений выполняются в современных браузерах. Сообщество веб-безопасности уже давно осознало необходимость развертывания функциональных элементов для защиты от уязвимостей на стороне сервера, раздающего статику и контент клиентам. Однако слишком мало внимания уделяется безопасности на стороне клиента, которая является не менее привлекательной для злоумышленников, но в значительной степени игнорируется современной инфраструктурой безопасности.
В этой серии из трех статей мы хотим устранить этот пробел. В первой части мы поговорим о наиболее распространенных кибератаках на веб-сайты. Во второй части рассмотрим решения в области веб-безопасности, которые сегодня чаще всего разворачиваются на продакшене. И в третьей части мы расскажем о том, как репрезентативное решение в области безопасности на стороне клиента может помочь найти в инфраструктуре уязвимые места, которые могут эксплуатироваться злоумышленниками.
В середине 90-х годов прошлого века одновременно с идеями Тима Бернерса-Ли от уровня протоколов передачи гипертекста и языков разметки до Internet protocol (IP) появились и средства нападения на инфраструктуры, системы и приложения, составляющие так называемую паутину или сеть (web). Тогда и зародилась такая дисциплина как веб-безопасность, которую можно определить как совокупность защитных мер, необходимых для управления рисками в области безопасности сетевых вычислений.
Как и следовало ожидать, таксономия проблем в области веб-безопасности быстро развивалась в разных направлениях, однако на ранних этапах основное внимание уделялось предотвращению атак типа «отказ в обслуживании», защите инфраструктуры хостинга и обеспечению свободного потока сетевого контента для пользователей. Такое внимание к вопросам доступности было продиктовано тем, что если веб-сайт не работает или работает не так как нужно, то электронные транзакции не смогут проходить безопасно, что имеет очевидные последствия для получения прибыли.
В дополнение к проблемам на уровне инфраструктуры, развивалось соображение о том, что проблемы на уровне приложений также могут иметь серьезные последствия, в частности, для клиентов, которые посещают веб-сайт. Так родилась так называемая угроза (threat) в области сетевой безопасности, которая из небольшого вопроса эволюционировала в большую задачу безопасности. Даже сегодня найти уязвимое веб-приложение достаточно легко.
В последние несколько лет появился стандартный набор стратегий нападения, которые крайне трудно пресечь. Назойливость этих проблем обусловлена сложностью разработки многих веб-приложений, а также относительной неопытностью и невежеством многих сетевых администраторов. Ниже мы расскажем о четырех стратегиях, которые приводят к возникновению уязвимостей в инфраструктуре электронной торговли и создают проблемы для многих компаний и их команд обеспечения безопасности.
Наиболее распространенной атакой на уровне приложений является межсайтовый скриптинг или попросту XSS. В своей основе межсайтовая атака несет такой метод, как инъекция – это когда злоумышленник находит способ встроить сторонний скрипт в сайт и заставить его работать. Конечная цель состоит в том, чтобы целевое веб-приложение отправило код злоумышленника в браузер пользователя без ведома последнего. XSS-атака лучше всего работает, когда веб-сайт принимает, обрабатывает и использует входные данные без особой проверки.
Конечная цель состоит в том, чтобы внедрить код в чей-нибудь браузер. Скомпрометированный пользователь ожидает, что все пришедшие скрипты будут безопасными, поскольку весь динамический контент пришел с посещаемого и предположительного надежного веб-сайта. Браузер пользователя выполнит этот код, часто на JavaScript, таким образом раскрывая злоумышленнику конфиденциальную информацию, такую как токены сессии или файлы cookie. Код XSS также может перенаправить пользователя на какой-либо зараженный сайт.
Рисунок 1. Схема XSS-атаки
Такие организации как Open Web Application Security Project (OWASP) предлагают различные средства защиты от XSS-атак. Их рекомендации, многие, из которых до сих пор игнорируются практиками, включают в себя осмысленные процедуры написания кода и администрирования веб-ресурсов, которые улучшают обработку данных, приходящих от пользователей. Большинство из них предполагают лучшую валидацию входных данных на стороне сервера, что приветствуется как мера контроля безопасности и должно присутствовать в любой сетевой экосистеме.
В последнее время все чаще стали проявлять себя атаки, связанные с инъекциями контента и рекламы, известные как malvertising. Однако эта тенденция не должна вызывать удивления, учитывая рост экосистемы онлайн-рекламы как движущей силы современного бизнеса. По некоторым оценкам, объем онлайн-рекламы в настоящее время достигает $100 млрд. Хакеры и преступники осознают наличие такой тенденции и используют в своих интересах доступные уязвимости.
Принцип работы malvertising аналогичен XSS: злоумышленники находят способ внедрить свой код на веб-сайты через легитимные рекламные сети. Цель также аналогична XSS, она состоит в том, чтобы перенаправлять посетителей одного сайта на другой целевой сайт с вредоносным кодом, который является основной любой атаки, такой как, например, кража учетных данных.
Некоторые говорят о процессе инъекции, как о drive-by download. Этот термин относится к пользователю, который просматривает рекламу в браузере с уязвимостью (что, к сожалению, является весьма распространённым сценарием). Когда пользователь взаимодействует с рекламой, происходит перенаправление, в результате которого вредоносное ПО попадает к ничего не подозревающему посетителю сайта.
Рисунок 2. Drive-By Download через Malvertising
Традиционное решение этой проблемы заключается в использовании элемента управления, такого как брандмауэр веб-приложения (web application firewall, WAF). WAF будет настроен на использование сигнатурного или поведенческого анализа для остановки выполнения вредоносного кода из ненадежных источников. Как и в случае с XSS, такая защита на стороне сервера обычно используется в рекламных экосистемах как основной контрольный элемент. Описанный подход применим к malvertising, но не будет работать против всех форм атак.
Хакерская группировка Magecart возникла несколько лет назад, начав терроризировать веб-сайты такой атакой как скимминг карт. Обычно хакерские группировки появляются и исчезают достаточно быстро, однако Magecart долго нервировали сайты и веб-приложения компаний. Большое количество организаций пострадали от взломов, и решения по обеспечению безопасности не были очевидны для большинства жертв.
Атаку man-in-the-middle от Magicart представить достаточно просто: сначала вредоносный код добавляется к коду на JavaScript, который отправляется с сервера на клиент. Затем вредоносный код выслеживает и собирает конфиденциальные данные, такие как информация о кредитных картах пользователей, которые заходят на сайт через свой браузер. Данные отправляются на вредоносный сайт и незаконно выгружаются. Все очень просто.
Рисунок 3. Скимминг карт от Magicart
Однако главная проблема заключается в том, что обычные средства безопасности на стороне сервера не учитывают атаку типа man-in-the-browser (MITB), поскольку она происходит на стороне клиента. Например, брандмауэры веб-приложений (WAF) не видят действий JavaScript и не имеют средств сканирования библиотек на предмет инъекций кода. Когда атака исходит от сторонних сайтов, результат получается каскадным, и случается то, что называется piggy-backing.
Узнать о курсе подробнее.
В этой статье, первой из трех, мы рассмотрим угрозы в области веб-безопасности, а также поговорим о том, как инструменты обеспечения безопасности на стороне клиента справляются с часто упускаемым классом кибератак, примером которого является Magecart. Здесь описаны традиционные способы защиты от угроз в области веб-безопасности, которые основаны на стандартах со стороны клиента, таких как политика безопасности контента и целостность подресурсов. Эти развивающиеся подходы рассматриваются в контексте репрезентативной платформы безопасности на стороне клиента.
Введение
Пожалуй, краеугольным камнем кибербезопасности как профессиональной дисциплины является ее непрерывная изменчивость. То есть, как только возникают кибератаки, которые затрагивают аспекты конфиденциальности, целостности или доступности некоторых интернет-ресурсов, для их устранения разрабатываются соответствующие решения. Как только эти решения интегрируются в инфраструктуру скомпрометированного ресурса, появляются новые кибератаки, изобретаются новые решения и цикл замыкается.
В некоторых случаях защитные кибер-решения имеют механизмы, которые предвосхищают новые формы вредоносных атак – и в случаях, когда это срабатывает, рисков в области безопасности удается избежать во множестве сценариев. Например, двухфакторная аутентификация была создана как мера против угадывания пароля, а теперь она является важным компонентом повышения уровня безопасности в разработке новых протоколов сообщения между устройствами Интернета Вещей.
Нигде процесс появления и преодоления угроз не является более очевидным, чем в области веб-безопасности, которую еще называют безопасностью веб-приложений. С учетом того, что ценные активы чаще всего обрабатываются и управляются с помощью веб-интерфейсов, ценность веб-эксплойтов продолжает расти. Одним из следствий этого роста является то, что несмотря на множество технологий защиты веб-ресурсов, растет и разрыв между количеством атак и уровнем защиты.
Основной предпосылкой создания этой технической серии статей является пробел в области веб-безопасности, который появляется из-за того, что большинство приложений выполняются в современных браузерах. Сообщество веб-безопасности уже давно осознало необходимость развертывания функциональных элементов для защиты от уязвимостей на стороне сервера, раздающего статику и контент клиентам. Однако слишком мало внимания уделяется безопасности на стороне клиента, которая является не менее привлекательной для злоумышленников, но в значительной степени игнорируется современной инфраструктурой безопасности.
В этой серии из трех статей мы хотим устранить этот пробел. В первой части мы поговорим о наиболее распространенных кибератаках на веб-сайты. Во второй части рассмотрим решения в области веб-безопасности, которые сегодня чаще всего разворачиваются на продакшене. И в третьей части мы расскажем о том, как репрезентативное решение в области безопасности на стороне клиента может помочь найти в инфраструктуре уязвимые места, которые могут эксплуатироваться злоумышленниками.
Распространенные атаки на веб-сайты
В середине 90-х годов прошлого века одновременно с идеями Тима Бернерса-Ли от уровня протоколов передачи гипертекста и языков разметки до Internet protocol (IP) появились и средства нападения на инфраструктуры, системы и приложения, составляющие так называемую паутину или сеть (web). Тогда и зародилась такая дисциплина как веб-безопасность, которую можно определить как совокупность защитных мер, необходимых для управления рисками в области безопасности сетевых вычислений.
Как и следовало ожидать, таксономия проблем в области веб-безопасности быстро развивалась в разных направлениях, однако на ранних этапах основное внимание уделялось предотвращению атак типа «отказ в обслуживании», защите инфраструктуры хостинга и обеспечению свободного потока сетевого контента для пользователей. Такое внимание к вопросам доступности было продиктовано тем, что если веб-сайт не работает или работает не так как нужно, то электронные транзакции не смогут проходить безопасно, что имеет очевидные последствия для получения прибыли.
В дополнение к проблемам на уровне инфраструктуры, развивалось соображение о том, что проблемы на уровне приложений также могут иметь серьезные последствия, в частности, для клиентов, которые посещают веб-сайт. Так родилась так называемая угроза (threat) в области сетевой безопасности, которая из небольшого вопроса эволюционировала в большую задачу безопасности. Даже сегодня найти уязвимое веб-приложение достаточно легко.
В последние несколько лет появился стандартный набор стратегий нападения, которые крайне трудно пресечь. Назойливость этих проблем обусловлена сложностью разработки многих веб-приложений, а также относительной неопытностью и невежеством многих сетевых администраторов. Ниже мы расскажем о четырех стратегиях, которые приводят к возникновению уязвимостей в инфраструктуре электронной торговли и создают проблемы для многих компаний и их команд обеспечения безопасности.
Межсайтовый скриптинг (XSS)
Наиболее распространенной атакой на уровне приложений является межсайтовый скриптинг или попросту XSS. В своей основе межсайтовая атака несет такой метод, как инъекция – это когда злоумышленник находит способ встроить сторонний скрипт в сайт и заставить его работать. Конечная цель состоит в том, чтобы целевое веб-приложение отправило код злоумышленника в браузер пользователя без ведома последнего. XSS-атака лучше всего работает, когда веб-сайт принимает, обрабатывает и использует входные данные без особой проверки.
Конечная цель состоит в том, чтобы внедрить код в чей-нибудь браузер. Скомпрометированный пользователь ожидает, что все пришедшие скрипты будут безопасными, поскольку весь динамический контент пришел с посещаемого и предположительного надежного веб-сайта. Браузер пользователя выполнит этот код, часто на JavaScript, таким образом раскрывая злоумышленнику конфиденциальную информацию, такую как токены сессии или файлы cookie. Код XSS также может перенаправить пользователя на какой-либо зараженный сайт.
Рисунок 1. Схема XSS-атаки
Такие организации как Open Web Application Security Project (OWASP) предлагают различные средства защиты от XSS-атак. Их рекомендации, многие, из которых до сих пор игнорируются практиками, включают в себя осмысленные процедуры написания кода и администрирования веб-ресурсов, которые улучшают обработку данных, приходящих от пользователей. Большинство из них предполагают лучшую валидацию входных данных на стороне сервера, что приветствуется как мера контроля безопасности и должно присутствовать в любой сетевой экосистеме.
Инъекции контента и рекламы
В последнее время все чаще стали проявлять себя атаки, связанные с инъекциями контента и рекламы, известные как malvertising. Однако эта тенденция не должна вызывать удивления, учитывая рост экосистемы онлайн-рекламы как движущей силы современного бизнеса. По некоторым оценкам, объем онлайн-рекламы в настоящее время достигает $100 млрд. Хакеры и преступники осознают наличие такой тенденции и используют в своих интересах доступные уязвимости.
Принцип работы malvertising аналогичен XSS: злоумышленники находят способ внедрить свой код на веб-сайты через легитимные рекламные сети. Цель также аналогична XSS, она состоит в том, чтобы перенаправлять посетителей одного сайта на другой целевой сайт с вредоносным кодом, который является основной любой атаки, такой как, например, кража учетных данных.
Некоторые говорят о процессе инъекции, как о drive-by download. Этот термин относится к пользователю, который просматривает рекламу в браузере с уязвимостью (что, к сожалению, является весьма распространённым сценарием). Когда пользователь взаимодействует с рекламой, происходит перенаправление, в результате которого вредоносное ПО попадает к ничего не подозревающему посетителю сайта.
Рисунок 2. Drive-By Download через Malvertising
Традиционное решение этой проблемы заключается в использовании элемента управления, такого как брандмауэр веб-приложения (web application firewall, WAF). WAF будет настроен на использование сигнатурного или поведенческого анализа для остановки выполнения вредоносного кода из ненадежных источников. Как и в случае с XSS, такая защита на стороне сервера обычно используется в рекламных экосистемах как основной контрольный элемент. Описанный подход применим к malvertising, но не будет работать против всех форм атак.
Magecart
Хакерская группировка Magecart возникла несколько лет назад, начав терроризировать веб-сайты такой атакой как скимминг карт. Обычно хакерские группировки появляются и исчезают достаточно быстро, однако Magecart долго нервировали сайты и веб-приложения компаний. Большое количество организаций пострадали от взломов, и решения по обеспечению безопасности не были очевидны для большинства жертв.
Атаку man-in-the-middle от Magicart представить достаточно просто: сначала вредоносный код добавляется к коду на JavaScript, который отправляется с сервера на клиент. Затем вредоносный код выслеживает и собирает конфиденциальные данные, такие как информация о кредитных картах пользователей, которые заходят на сайт через свой браузер. Данные отправляются на вредоносный сайт и незаконно выгружаются. Все очень просто.
Рисунок 3. Скимминг карт от Magicart
Однако главная проблема заключается в том, что обычные средства безопасности на стороне сервера не учитывают атаку типа man-in-the-browser (MITB), поскольку она происходит на стороне клиента. Например, брандмауэры веб-приложений (WAF) не видят действий JavaScript и не имеют средств сканирования библиотек на предмет инъекций кода. Когда атака исходит от сторонних сайтов, результат получается каскадным, и случается то, что называется piggy-backing.
Узнать о курсе подробнее.
