Что такое OWASP Top-10 и как использовать указанные риски и уязвимости

При управлении сайтом важно быть в курсе наиболее значимых уязвимостей и угроз безопасности. Рейтинг OWASP Top 10 — отличная отправная точка для ознакомления с самыми серьёзными угрозами для веб-приложений, существующими на данный момент.

Что такое OWASP?

OWASP (расшифровывается как Open Web Application Security Project) — это онлайн-сообщество, которое выпускает статьи на тему безопасности веб-приложений, а также документацию, различные инструменты и технологии.

Что такое OWASP Топ-10?

OWASP Топ-10 — это список из десяти самых распространённых на данный момент уязвимостей веб-приложений. Благодаря этому списку пользователи будут осведомлены о наиболее критичных рисках и угрозах, их последствиях и мерах противодействия. Обновляется список OWASP каждые три-четыре года (последний раз он был выпущен в 2018 году). Давайте познакомимся с ним поближе.

10 основных уязвимостей OWASP 2020 года:

Инъекционные атаки (Injections)
Нарушенная аутентификация (Broken Authentication)
Незащищённость критичных данных (Sensitive Data Exposure)
Внешние объекты XML (XXE) (XML External Entities (XXE))
Нарушение контроля доступа (Broken Access control)
Небезопасная конфигурация (Security misconfigurations)
Межсайтовый скриптинг (XSS) (Cross Site Scripting (XSS))
Небезопасная десериализация (Insecure Deserialization)
Использование компонентов с известными уязвимостями (Using Components with known vulnerabilities)
Неэффективный мониторинг (Insufficient logging and monitoring)

Инъекционная атака

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

Возможно, наиболее распространённой разновидностью этой уязвимости системы безопасности является внедрение кода через SQL-запрос, использующий ненадёжные данные. Один из примеров от OWASP вы можете увидеть ниже:

String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;

Этот запрос можно использовать, вызвав веб-страницу с URL-адреса http://example.com/app/accountView?id='’ или 1’=’1, что приводит к возврату всех строк, хранящихся в таблице базы данных.

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

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

Вот ещё один пример SQL-внедрения, затронувшего более полумиллиона сайтов, на которых был установлен плагин YITH WooCommerce Wishlist для WordPress:

Показанное выше SQL-внедрение может привести к серьёзной утечке конфиденциальных данных.

Как предотвратить внедрение кода?

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

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

Вот технические рекомендации OWASP по предотвращению угрозы SQL-внедрения:

Для предотвращения SQL-внедрения данные требуется хранить отдельно от команд и запросов.
Предпочтительным вариантом является использование безопасного API, который полностью избегает применения интерпретатора или предоставляет параметризованный интерфейс. Допускается также переход на использование инструментов объектно-реляционного отображения (ORM). Примечание: даже при параметризации хранимые процедуры всё равно допускают SQL-внедрение, если PL/SQL или T-SQL объединяют запросы и данные.
Используйте положительную проверку («белый список») входных данных на стороне сервера. Это, однако, не даёт вам полную защиту, поскольку многим приложениям требуются специальные символы.
Для любых остаточных динамических запросов экранируйте специальные символы, используя синтаксис экранирования для этого интерпретатора. Примечание: структуры SQL (имена таблиц, имена столбцов и т.д.) не могут быть экранированы, поэтому имена структур, задаваемые пользователем, опасны. Это распространённая проблема в программном обеспечении для написания отчётов.
Используйте LIMIT и другие элементы управления SQL в запросах, чтобы предотвратить массовое раскрытие записей в случае SQL-внедрения.

Из этих рекомендаций можно сделать два вывода:

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

Инъекционные атаки представляют собой серьёзный риск для владельцев сайтов, так как используют лазейки в системе безопасности для кражи конфиденциальной информации.

Нарушенная аутентификация

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

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

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

/administrator в Joomla!,
/wp-admin/ в WordPress,
/index.php/admin в Magento,
/user/login в Drupal.

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

Типы некорректной аутентификации

Согласно OWASP Top-10, подобная уязвимость может проявляться во многих формах. Веб-приложение содержит неисправную аутентификацию, если оно:

Допускает автоматизированные атаки, такие как подбор или автоматизированное заполнение учётных данных;
Разрешает использование стандартных, слабых или хорошо известных паролей, таких как Password1 или admin/admin;
Использует слабые или неэффективные процессы восстановления учётных данных и забытых паролей, в том числе «ответы на основе знаний»;
Не использует многофакторную аутентификацию;
Предоставляет идентификаторы сеанса в URL;
Не меняет идентификаторы сеанса после успешного входа в систему;
Не делает недействительными идентификаторы сеанса. Сеансы пользователей или токены аутентификации (в частности, токены единого входа (SSO)) не аннулируются должным образом при выходе из системы или в период бездействия.

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

Как свести к минимуму уязвимости с нарушенной аутентификацией?

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

Технические рекомендации OWASP заключаются в следующем:

По возможности внедряйте многофакторную аутентификацию, чтобы предотвратить автоматизированные атаки злоумышленников.
Не используйте учётные данные по умолчанию, особенно это касается учётных данных администраторов.
Внедрите проверку надёжности паролей, включая тестирование новых или изменённых паролей по списку из 10 000 самых плохих паролей.
Согласуйте политику длины, сложности и ротации паролей с рекомендациями NIST800-63 B или другими современными политиками безопасности паролей.
Убедитесь, что пути регистрации и восстановления учётных данных защищены от атак перечисления учётных записей.
Ограничивайте или задерживайте по времени неудачные попытки входа в систему. Регистрируйте все сбои и предупреждайте администраторов при обнаружении вброса учётных данных, их перебора или других атак.
Используйте безопасный встроенный диспетчер сеансов, который после входа в систему генерирует новый случайный идентификатор сеанса с высокой энтропией. Идентификаторы сеанса не должны быть указаны в URL-адресе. Идентификаторы также должны быть надёжно сохранены и аннулированы после выхода из системы или простоя.

Незащищённость критичных данных

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

Примеры конфиденциальных данных

Некоторые конфиденциальные данные, требующие защиты:

Номера кредитных карт,
Медицинская информация,
Информация, позволяющая идентифицировать личность (PII),
Другая личная информация.

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

Ответственное отношение к сбору и обработке конфиденциальных данных стало более заметным после появления Общего регламента по защите данных (GDPR). Этот новый закон о конфиденциальности данных, вступивший в силу в 2018 году, определяет, как компании должны собирать, изменять, обрабатывать, хранить и удалять персональные данные.

Существует два типа данных:

Хранимые данные — данные в состоянии покоя;
Передаваемые данные — данные, которые передаются между серверами или в веб-браузеры.

Оба типа данных должны быть надёжно защищены.

Защита передаваемых данных

Один из способов защитить передаваемые данные на сайте — это наличие SSL сертификата.

SSL — это аббревиатура от Secure Sockets Layer. Это стандартная технология безопасности для установления зашифрованного соединения между сервером и браузером. Сертификаты SSL помогают защитить целостность данных, передаваемых между хостом (сервером или брандмауэром) и клиентом (браузером).

Каковы риски раскрытия конфиденциальных данных

Вот несколько примеров того, что может случиться при раскрытии конфиденциальных данных:

Сценарий №1. Приложение автоматически шифрует номера кредитных карт в базе данных. Однако при получении эти данные автоматически расшифровываются, что позволяет уязвимости SQL-внедрения получать номера кредитных карт в виде открытого текста.
Сценарий №2. Сайт не использует TLS для всех страниц или поддерживает слабое шифрование. Злоумышленник отслеживает сетевой трафик (например в незащищённой беспроводной сети), понижает уровень соединения с HTTPS до HTTP, перехватывает запросы и крадёт файлы cookie сеанса пользователя. Затем злоумышленник повторно воспроизводит эти файлы cookie и перехватывает сеанс пользователя (уже аутентифицированный), получая доступ к личным данным пользователя.
Сценарий №3. База данных паролей использует «несолёные» или простые хэши для хранения паролей всех пользователей. Ошибка загрузки файла позволяет злоумышленнику завладеть базой данных паролей. Все «несолёные» хэши могут быть вскрыты с помощью радужной таблицы предварительно рассчитанных хешей. Хэши, сгенерированные простыми или быстрыми хэш-функциями, могут быть взломаны графическими процессорами, даже если они были «солёными».

Почему раскрытие конфиденциальных данных так распространено?

За последние несколько лет раскрытие конфиденциальных данных стало одной из самых распространённых проблем во всём мире. Вот некоторые примеры утечек, которые привели к раскрытию конфиденциальных данных:

Кибератака на бразильскую сеть магазинов модной одежды C&A, произошедшая в августе 2018 года;
Взлом Uber в 2016 году, в результате которого была раскрыта личная информация 57 миллионов пользователей Uber, а также 600 000 водителей;
Утечка данных из хранилища Target, в результате чего была раскрыта информация о кредитных/дебетовых картах и контактная информация около 110 миллионов человек.

Отсутствие шифрования конфиденциальных данных — основная причина того, что эти атаки всё ещё происходят так часто. Даже зашифрованные данные могут быть взломаны из-за слабых:

Процесса генерации ключей;
Процесса управления ключами;
Используемого алгоритма;
Используемого протокола;
Используемых шифров;
Методов хранения паролей.

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

Как предотвратить раскрытие данных

Предотвратить раскрытие данных, согласно OWASP, можно, придерживаясь следующих правил:

Классифицируйте данные, обрабатываемые, хранящиеся или передаваемые приложением.
Определите, какие данные являются конфиденциальными в соответствии с законами о конфиденциальности, нормативными требованиями или бизнес-потребностями.
Применяйте элементы управления в соответствии с классификацией.
Не храните конфиденциальные данные без надобности. Данные, которые не хранятся, не могут быть украдены.
Обязательно шифруйте все конфиденциальные данные, находящиеся в состоянии покоя.
Обеспечьте наличие современных и надёжных стандартных алгоритмов, протоколов и ключей; используйте надлежащее управление ключами.
Шифруйте все передаваемые данные с помощью безопасных протоколов, таких как TLS, с безопасными параметрами и приоритизацией шифрования сервером.
Отключите кэширование для ответов, содержащих конфиденциальные данные.
Храните пароли, используя мощные адаптивные и «солёные» функции хеширования, например Argon2, scrypt, bcrypt или PBKDF2.
Обеспечьте независимую проверку эффективности конфигурации и настроек.

Внешние объекты XML (XXE)

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

Большинство синтаксических анализаторов XML по умолчанию уязвимы для XXE-атак. Ответственность за то, чтобы приложение не содержало этой уязвимости, лежит в основном на разработчике.

Каковы векторы атак на внешние объекты XML?

Согласно OWASP Top 10, основные направления атаки внешних объектов XML (XXE) включают использование:

Уязвимых XML-процессоров (злоумышленники могут загружать XML или включать вредоносное содержимое в XML-документ);
Уязвимого кода;
Уязвимых зависимостей;
Уязвимых интеграций.

Как предотвратить атаки внешних объектов XML

Для этого OWASP рекомендует:

По возможности использовать менее сложные форматы данных, такие как JSON, и избегать сериализации конфиденциальных данных.
Исправить или обновить все процессоры и библиотеки XML, используемые приложением или базовой операционной системой.
Использовать средства проверки зависимостей (обновить SOAP до SOAP 1.2 или выше).
Отключить внешние объекты XML и обработку DTD во всех синтаксических анализаторах XML в приложении в соответствии с памяткой OWASP «Предотвращение XXE».
Реализовать положительную проверку («белый список») входных данных на стороне сервера и фильтрацию для предотвращения использования вредоносных данных в XML-документах, заголовках или узлах.
Убедиться, что функция загрузки XML- или XSL-файлов проверяет входящий XML с помощью XSD или аналогичного средства.
Использовать инструменты SAST, что может помочь обнаружить XXE в исходном коде (хотя ручная проверка кода — лучшая альтернатива в больших и сложных приложениях с множеством интеграций).

Если эти способы контроля по каким-то причинам нереализуемы, рассмотрите возможность использования:

Виртуальных патчей.
Шлюзов безопасности API.
Межсетевых экранов веб-приложений (WAFs), позволяющих обнаруживать и блокировать XXE-атаки.

Нарушение контроля доступа

В области безопасности сайтов контроль доступа — это ограничение доступа посетителей к отдельным разделам или страницам.

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

В наши дни это проблема почти всех основных систем управления содержимым (CMS). По умолчанию доступ к странице входа администратора предоставлен всем. В большинстве случаев не используется даже метод двухфакторной аутентификации (2FA).

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

Примеры нарушенного контроля доступа

Вот несколько примеров того, что мы включаем в понятие «доступ»:

Доступ к панели управления хостингом/административной панели.
Доступ к серверу через FTP/SFTP/SSH.
Доступ к административной панели сайта.
Доступ к другим приложениям на вашем сервере.
Доступ к базе данных.

Злоумышленники могут использовать недостатки авторизации в следующих целях:

Доступ к неавторизованным функциям и/или данным.
Просмотр конфиденциальных файлов.
Изменение прав доступа.

Каковы риски нарушения контроля доступа?

Вот несколько примеров того, что, согласно OWASP, может случиться при нарушении контроля доступа:

Сценарий №1. Приложение использует непроверенные данные в вызове SQL, который обращается к информации об учётной записи:

pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults =pstmt.executeQuery( );

Злоумышленник просто изменяет параметр «acct» в браузере, чтобы отправить любой номер учётной записи, который он хочет. В случае отсутствия надлежащей проверки злоумышленник может получить доступ к учётной записи любого пользователя:

http://example.com/app/accountInfo?acct=notmyacct

Сценарий №2. Злоумышленник просто просматривает целевые URL-адреса. Для доступа к странице администратора необходимы права администратора.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

Большинство разрабов знакомы с приведёнными выше сценариями, но помните, что уязвимости неработающего контроля доступа могут проявляться во многих формах и почти во всех существующих веб-технологиях.

Снижение рисков нарушения контроля доступа

Чтобы снизить риски, связанные с нарушением контроля доступа, вы можете сделать следующее:

Используйте наименее привилегированные концепции — применяйте роль, соответствующую задаче, и только на время, необходимое для выполнения указанной задачи, и не более.
Избавьтесь от учётных записей, которые вам не нужны. Ликвидируйте аккаунты пользователей, если последние в них больше не нуждаются.
Регулярно проверяйте свои серверы и сайты — кто и что делал, когда и зачем.
Если возможно, примените многофакторную аутентификацию ко всем точкам доступа.
Отключите точки доступа до тех пор, пока они не понадобятся, чтобы просто уменьшить их количество.
Удалите ненужные службы с вашего сервера.
Сравните приложения, доступные извне, с приложениями, привязанными к вашей сети.
Если вы разрабатываете сайт, имейте в виду, что рабочая версия не должна быть местом для тестирования.

Предотвращение нарушения контроля доступа

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

Технические рекомендации OWASP по предотвращению нарушения контроля доступа:

Запрет должен быть по умолчанию, за исключением общедоступных ресурсов.
Внедряйте механизмы управления доступом и используйте их на всех этапах работы приложения. Минимизируйте использование CORS.
Элементы управления доступом должны обеспечивать право собственности на записи. Не следует допускать того, чтобы пользователь мог создавать, читать, обновлять или удалять любую запись. Например, если пользователь входит в систему как «Джон», он может создавать, читать, обновлять или удалять только записи, связанные с идентификатором «Джон», но не записи других пользователей.
Отключите список каталогов веб-сервера и убедитесь, что метаданные файлов (например, .git) и файлы резервных копий отсутствуют в корневом каталоге веб-сервера.
Регистрируйте сбои контроля доступа, при необходимости (например, при повторяющихся сбоях) предупреждайте администраторов. Примечание: мы рекомендуем для этого бесплатный плагин для сайтов WordPress, который вы можете скачать прямо с официального репозитория WordPress.
Ограничьте частоту запросов к API для минимизации ущерба от автоматизированных атак.
Токены JWT должны быть аннулированы на сервере после выхода из системы.
Разработчики и тестировщики программного обеспечения должны включать функциональные блоки управления доступом и интеграционные тесты.

Небезопасная конфигурация

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

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

Одна из наиболее распространённых ошибок веб-мастеров — сохранение настроек CMS по умолчанию.

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

Права доступа к файлам — ещё один пример настройки по умолчанию, которую можно и нужно усилить.

Где встречаются небезопасные конфигурации?

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

Сетевые услуги.
Платформу.
Веб-сервер.
Сервер приложений.
Базу данных.
Фреймворки.
Пользовательский код.
Предустановленные виртуальные машины.
Контейнеры.
Хранилища.

Один из самых последних примеров неправильной конфигурации приложений — это серверы memcached, используемые для DDoS-атак на огромные сервисы в технологической индустрии.

Примеры сценариев атак, ставших возможными из-за небезопасной конфигурации

Сценарий №1. Сервер приложений поставляется с образцами приложений, обладающими известными недостатками безопасности. Злоумышленники могут использовать их для взлома сервера. Если одним из этих приложений является консоль администратора (при этом учётные записи по умолчанию не были изменены), злоумышленник входит в систему с паролями по умолчанию и берёт на себя управление.
Сценарий №2. Список каталогов на сервере не был отключён. Злоумышленник обнаруживает, что может просто перечислить каталоги. Он загружает скомпилированные классы Java, которые декомпилирует и реконструирует для просмотра кода.
Сценарий №3. Конфигурация сервера приложений позволяет возвращать пользователям подробные сообщения об ошибках. Это потенциально раскрывает конфиденциальную информацию, такую как версии компонентов.
Сценарий №4. Поставщик облачных услуг имеет по умолчанию разрешения на совместное использование. Это позволяет злоумышленникам получить доступ к конфиденциальным данным в облачном хранилище.

Как получить безопасные настройки

Чтобы предотвратить атаки, связанные с неправильными настройками безопасности, требуется:

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

Межсайтовый скриптинг (XSS)

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

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

Уязвимость XSS присутствует примерно в двух третях всех приложений.

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

Примеры уязвимостей XSS

Представьте, что вы, находясь на своей панели администратора WordPress, добавляете новый пост. Если вы используете плагин с сохранённой уязвимостью XSS, хакер сможет заставить ваш браузер создать нового пользователя-администратора, пока вы находитесь в панели wp-admin. Кроме того, он может редактировать ваше сообщение и выполнять другие подобные действия.

Уязвимость XSS даёт злоумышленнику почти полный контроль над самым важным в настоящее время программным обеспечением компьютеров — браузерами.

Типы XSS

Согласно OWASP Top 10, существует три типа межсайтового скриптинга:

Отражённый XSS: приложение или API включает в себя непроверенный и неэкранированный пользовательский ввод как часть вывода HTML. Успешная атака позволит злоумышленнику загрузить произвольный HTML и выполнить JavaScript в браузере жертвы. Как правило, пользователю необходимо провзаимодействовать с какой-либо вредоносной ссылкой, которая указывает на страницу, контролируемую злоумышленником.
Сохранённый XSS: приложение или API хранит неочищенный пользовательский ввод, который позже просматривается другим пользователем или администратором. Сохранённый XSS-код часто считается высоким или критическим риском.
DOM XSS: JavaScript-фреймворки, одностраничные приложения и API, которые динамически включают данные, контролируемые злоумышленником, уязвимы для DOM XSS.

Снижение рисков XSS

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

Как предотвратить проблемы, вызванные XSS-уязвимостями

Превентивные меры по снижению вероятности XSS-атак должны включать отделение ненадёжных данных от активного содержимого браузера. OWASP даёт несколько практических советов о том, как этого добиться:

Используйте фреймворки, которые благодаря своей «конструкции» автоматически избегают XSS. К таким фреймворкам относится, например, последняя версия Ruby on Rails. Изучите ограничения XSS-защиты каждого фреймворка и примите соответствующие меры.
Экранирование ненадёжных данных HTTP-запроса на основе контекста в выходных данных HTML (тело, атрибут, JavaScript, CSS или URL) позволит устранить отражённые и сохранённые уязвимости XSS. Руководство OWASP по предотвращению XSS содержит подробные сведения о способах экранирования данных.
Применение контекстно-зависимого кодирования при изменении документа браузера на стороне клиента действует против DOM XSS. Когда этого нельзя избежать, к API-интерфейсам браузера можно применить контекстно-зависимые методы экранирования, аналогичные тем, что описаны в руководстве OWASP по предотвращению XSS на основе DOM.
Включение политики безопасности содержимого (CSP) — это комплексная защита, снижающая риск XSS-атак. Она эффективна, если не существует других уязвимостей, которые позволили бы разместить вредоносный код через локальные файлы.

Небезопасная десериализация

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

Каждому веб-разработчику следует смириться с тем фактом, что злоумышленники будут пытаться «играть» со всем, что взаимодействует с его приложением, — от URL-адресов до сериализованных объектов.

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

В информатике объект — это структура данных, а точнее способ структурирования данных.
Процесс сериализации — это преобразование объектов в байтовые строки.
Процесс десериализации — это преобразование байтовых строк в объекты.

Примеры сценариев десериализационной атаки

Сценарий №1. Приложение React вызывает набор микросервисов Spring Boot. Будучи функциональными программистами, разработчики старались обеспечить неизменность своего кода. Решение, которое они придумали, — это сериализация состояния пользователя и его передача туда и обратно с каждым запросом. Злоумышленник замечает сигнатуру объекта «R00» и использует инструмент Java Serial Killer для удалённого выполнения кода на сервере приложений.
Сценарий №2. PHP-форум использует сериализацию объекта PHP для сохранения «супер» cookie, содержащего идентификатор пользователя, его роль, хэш пароля и другие состояния:

a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;

i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}

Злоумышленник изменяет сериализованный объект, чтобы получить права администратора:

a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;

i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}

Одним из векторов атаки, как вы видите, является суперфайл cookie, содержащий сериализованную информацию о вошедшем в систему пользователе. В этом файле cookie указана роль пользователя.

Если злоумышленник успешно десериализует данный объект, он затем изменит пользовательские права, предоставив себе роль администратора, и снова сериализует объект. Этот набор действий может поставить под угрозу всё веб-приложение.

Как предотвратить небезопасную десериализацию

Лучший способ защитить ваше веб-приложение от риска такого типа — не принимать сериализованные объекты из ненадёжных источников.

Если вы не можете этого сделать, OWASP Security предоставляет дополнительные технические рекомендации, которые вы можете попытаться реализовать:

Внедрение проверок целостности любых сериализованных объектов для выявления создания вредоносных объектов или подделки данных;
Обеспечение строгих ограничений во время десериализации (были продемонстрированы способы обхода этой техники, поэтому полагаться исключительно на неё не рекомендуется);
Изоляция и запуск кода, который десериализуется в средах с низким уровнем привилегий, когда это возможно;
Ведение журнала исключений и сбоев десериализации;
Ограничение или мониторинг входящих и исходящих сетевых подключений от десериализуемых контейнеров или серверов;
Мониторинг десериализации — оповещение, если пользователь выполняет десериализацию постоянно.

Использование компонентов с известными уязвимостями

В наши дни даже простые сайты, такие как личные блоги, имеют множество зависимостей.

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

Например, в 2019 году 56% всех приложений CMS на момент их заражения были устаревшими.

Почему мы не обновляем наше программное обеспечение вовремя? Почему сегодня это всё ещё такая огромная проблема?

Есть несколько вариантов ответа на этот вопрос, например:

Веб-мастера/разработчики не успевают за обновлениями (в конце концов, правильное обновление требует времени).
Устаревший код не будет работать с более новыми версиями своих зависимостей.
Веб-мастера боятся, что их сайт перестанет правильно функционировать.
У веб-мастеров нет опыта, чтобы правильно установить обновление.

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

Какой бы ни была причина использования устаревшего программного обеспечения в вашем веб-приложении, вы не можете оставить его незащищённым. И Sucuri, и OWASP рекомендуют виртуальные патчи в случаях, когда внесение исправлений невозможно.

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

Уязвимые приложения

В соответствии с рекомендациями OWASP приложения можно считать потенциально уязвимыми, если:

Программное обеспечение не поддерживается или устарело. Под программным обеспечением в данном случае следует понимать ОС, веб-сервер/сервер приложений, систему управления базами данных (DBMS), приложения, API, а также все компоненты, среды и библиотеки.
Вы не знаете версии всех используемых вами компонентов (как на стороне сервера, так и на стороне клиента). Речь идёт о компонентах, которые вы используете непосредственно, а также о вложенных зависимостях.
Вы не обновляете своевременно базовую платформу, фреймворки и зависимости. Это обычно происходит в средах, где установка исправлений выполняется ежемесячно или ежеквартально, что оставляет организацию уязвимой на многие дни или даже месяцы.
Разработчики программного обеспечения не проверяют совместимость обновлённых или исправленных библиотек.
Вы не обеспечиваете безопасность конфигураций компонентов.

Как избежать использования компонентов с известными уязвимостями

Вот некоторые из способов избежать использования уязвимых компонентов:

Удалите все ненужные зависимости.
Проведите инвентаризацию всех ваших компонентов — как на стороне сервера, так и на стороне клиента.
Отслеживайте такие источники, как Common Vulnerabilities and Disclosures (CVE) и National Vulnerability Database (NVD), для знакомства с новыми уязвимостями в компонентах.
Приобретайте компоненты только из официальных источников.
Избавьтесь от компонентов, которые активно не используются.
Используйте виртуальные патчи.

Неэффективный мониторинг

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

Отсутствие эффективного мониторинга может привести к увеличению ущерба от взлома сайта.

Примеры атак, ставших возможными из-за неэффективного мониторинга

Вот несколько примеров сценариев атак, причиной которых можно считать недостаточный мониторинг:

Сценарий №1. Форум с открытым исходным кодом, управляемый небольшой командой, был взломан с использованием уязвимости в его программном обеспечении. Злоумышленникам удалось уничтожить внутренний репозиторий со всем содержимым форума. Содержимое можно восстановить, но отсутствие мониторинга привело к гораздо более серьёзным последствиям. В результате форум проекта больше не активен.
Сценарий №2. Злоумышленник ищет пользователей с общим паролем. Он может получить доступ ко всем учётным записям с этим паролем. Для всех остальных пользователей это сканирование оставляет только один ложный вход в систему. Через несколько дней он может повторить то же самое с другим паролем.
Сценарий №3. У крупного американского ритейлера была внутренняя «песочница» для анализа вложений с целью поиска вредоносного программного обеспечения. «Программа-песочница» обнаружила потенциально нежелательное ПО, но никто не отреагировал на это. В течение некоторого времени «песочница» выдавала предупреждения. Продолжалось это до тех пор, пока не были обнаружены мошеннические транзакции по картам внешнего банка.

Как обеспечить эффективный мониторинг сайта

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

#web #OWASP