OWASP Top 10: самые распространённые уязвимости веб-приложений
2026-02-21 06:33 Diff
https://skillbox.ru/media/code/owasp-top-10-samye-rasprostranyennye-uyazvimosti-vebprilozheniy/

#статьи

  • 13 окт 2023
  • 0

Изучаем атаки и учимся от них защищаться по международным стандартам.

Иллюстрация: Colowgee / Stable Diffusion / Wikimedia Commnons / Cottonero / Freepik / Colowgee для Skillbox Media

Пишет о сетях, инструментах для разработчиков и языках программирования. Любит готовить, играть в инди‑игры и программировать на Python.

Некоммерческая организация OWASP Foundation выпускает рекомендации по обеспечению безопасности веб-приложений. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.

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

OWASP (Open Web Application Security Project) — открытый проект по безопасности веб-приложений, созданный и поддерживаемый некоммерческой организацией OWASP Foundation.

Эксперты организации каждые 3–4 года обновляют OWASP Top Ten — список критических уязвимостей веб-приложений. Он помогает разработчикам и специалистам по информационной безопасности создавать и поддерживать безопасные сайты и приложения.

В последней редакции OWASP Top Ten названы следующие уязвимости:

Познакомимся с каждым видом уязвимостей и разберёмся, как их можно устранить.

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

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

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

Что делать:

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

Чего не стоит делать:

  • Полагаться только на скрытие ссылок или кнопок в пользовательском интерфейсе для ограничения доступа. Это не предотвратит доступ к закрытой функциональности по прямым запросам.
  • Доверять пользовательским входным данным при авторизации. Всегда следует проводить проверку на сервере.
  • Оставлять прежней политику контроля доступа при изменении требований и бизнес-логики приложения.

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

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

Что делать:

  • Обновляйте и пересматривайте криптографические методы и ключи с учётом последних рекомендаций и стандартов.
  • Храните криптографические ключи в надёжном месте. Избегайте их хранения вместе с кодом приложения или в открытом виде.

Чего не стоит делать:

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

Инъекция — это пользовательский ввод с вредоносным кодом. Чаще всего инъекции включают SQL-запросы и команды на языке оболочки операционной системы.

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

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

Что делать:

  • Используйте параметризованные запросы или ORM (object-relational mapping) для работы с базой данных.
  • Валидируйте и фильтруйте входные данные. Принимайте только допустимые символы и структуры данных.
  • Применяйте принцип наименьших привилегий: ограничивайте права доступа к базе данных необходимыми.
  • Используйте LIMIT и другие элементы управления SQL в запросах для предотвращения массового раскрытия записей в случае SQL-инъекции.

Чего не стоит делать:

  • Конкатенировать и вставлять непроверенные данные пользователя напрямую в SQL-запросы, команды операционной системы или другие исполняемые на сервере контексты.
  • Надеяться на то, что фильтрация одного типа данных предотвратит инъекции. Злоумышленники могут использовать разные методы атак.
  • Хранить конфиденциальные данные в чистом тексте без шифрования в базе данных.

Широкая категория уязвимостей, впервые появившаяся в последней версии OWASP Top Ten. Уязвимости этой категории возникают потому, что сама логика работы приложения может позволять использовать существующие функции для взлома.

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

Что делать:

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

Чего не стоит делать:

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

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

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

Что делать:

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

Чего не стоит делать:

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

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

У злоумышленников даже есть автоматизированные инструменты, которые помогают находить непропатченные или неправильно сконфигурированные системы. Например, поисковая система Shodan IoT ищет устройства, которые страдают от уязвимости Heartbleed, исправленной в апреле 2014 года. Удивительно, но они встречаются и в 2023 году.

Что делать:

  • Регулярно обновляйте используемые компоненты. Следите за выпуском обновлений и исправлений, касающихся безопасности компонентов.
  • Удаляйте неиспользуемые зависимости, ненужные функции, компоненты и файлы.
  • Используйте источники, которые предоставляют информацию о безопасности компонентов: OWASP Dependency-Check, Retire.js и другие.

Чего не стоит делать:

  • Использовать устаревшие компоненты без обновления.
  • Игнорировать предупреждения о безопасности, которые касаются используемых компонентов.

Слабые пароли, недостаточная проверка подлинности, неэффективные системы учёта сеансов — всё это OWASP относит к ошибкам идентификации и аутентификации.

Предположим, что веб-приложение допускает слабые пароли, такие как «123456», «admin» или «qwerty». Злоумышленник может легко взломать аккаунт, угадав такой пароль или просто перебрав варианты.

Сюда же относятся:

  • незащищённые способы восстановления паролей — например, подходы на основе знаний, когда человек должен ответить на секретный вопрос;
  • отсутствие многофакторной авторизации;
  • раскрытие идентификатора сессии в URL.

Что делать:

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

Чего не стоит делать:

  • Разрешать пользователям использовать слабые пароли или пароли по умолчанию.
  • Хранить пароли пользователей в открытом виде в базе данных. Храните хеши паролей с солью.

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

Что делать:

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

Чего не стоит делать:

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

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

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

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

Что делать:

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

Чего не стоит делать:

  • Оставлять логирование без внимания. Регулярно анализируйте логи для выявления аномальных событий.
  • Обходиться без мониторинга. Обязательно убедитесь, что система мониторинга активна и правильно настроена.
  • Использовать только автоматические уведомления о состоянии системы. Регулярно вручную проверяйте состояние системы и логов.

Подделка запросов на стороне сервера (server-side request forgery, SSRF) — это тип уязвимости, при котором злоумышленник заставляет сервер отправлять запросы к внутренним ресурсам или внешним сайтам.

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

Что делать:

  • Ограничивайте или фильтруйте пользовательский ввод, который используется для формирования запросов.
  • Используйте белый список (whitelist) разрешённых адресов, на которые сервер может отправлять запросы.
  • Ограничьте и контролируйте доступ сервера к внутренним ресурсам.

Чего не стоит делать:

  • Доверять непроверенным или неконтролируемым URL-адресам, переданным пользователем.
  • Открывать доступ сервера к внутренним ресурсам без проверки.
  • Использовать пользовательский ввод напрямую для формирования запросов на стороне сервера.

Перечисленные топ-10 уязвимостей OWASP опубликовал осенью 2021 года. Следите за обновлениями и рекомендациями сообщества на официальном сайте и помните — абсолютной защиты от хакерских атак не бывает.

Бесплатный курс по кибербезопасности
Пройдите курс и узнайте реальные техники взлома и защиты веб-серверов. Решите 3 практические задачи и получите ценные подарки. Пройти курс →