OWASP Top 10: самые опасные уязвимости, через которые хакеры получают доступ к системам и данным

OWASP — международная организация, которая помогает делать веб-приложения безопасными.

Она выпускает бесплатные гайды, инструменты и рекомендации для разработчиков и специалистов по безопасности. Главная цель OWASP — научить предотвращать киберугрозы и создавать защищенные системы.
Самый известный проект этой организации — OWASP Top 10: список из десяти самых распространенных уязвимостей в веб-среде. Он помогает выявлять слабые места, устранять их и повышать защиту пользователей. Эксперты OWASP регулярно обновляют список с учетом появления новых угроз.
Уязвимости из OWASP Top 10 — главные причины утечек, взломов аккаунтов и атак на бизнес. Если вы разрабатываете или тестируете веб-сервисы, знать эти уязвимости — обязательное условие для безопасности вашей компании.

На момент написания этой статьи в OWASP Top 10 входят такие уязвимости:

1. Нарушение контроля доступа,
2. Криптографические уязвимости,
3. Инъекции,
4. Небезопасный дизайн,
5. Неправильная настройка системы безопасности,
6. Устаревшие или уязвимые компоненты,
7. Нарушенная аутентификация и идентификация,
8. Сбои в работе программного обеспечения и целостности данных,
9. Недостаточный мониторинг и ведение логов,
10. Подделка серверных запросов (SSRF).

Теперь давайте разберемся с каждой из этих уязвимостей и рассмотрим способы ее предотвращения.

Контроль доступа ограничивает функциональность системы в зависимости от прав пользователя.

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

Рассказываем про основные причины появления уязвимости.

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

Полное отсутствие проверок. В некоторых системах контроль доступа вообще не реализован, либо проверка осуществляется только на клиентской стороне.

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

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

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

Если пользователь вручную изменит ID задачи, например, с 12345 на 67890, он увидит чужую задачу или сможет ее изменить:

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

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

Как предотвратить уязвимость

Приводим основные методы защиты, которые помогут предотвратить нарушение контроля доступа.

Проверяйте права на стороне сервера. Все проверки должны выполняться на стороне сервера. Не полагайтесь на интерфейсные ограничения, такие как скрытие кнопок или ссылок.

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

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

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

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

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

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

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

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

Как предотвратить уязвимость

Рассказываем про основные методы защиты чувствительной информации.

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

Используйте HTTPS для защиты при передаче данных. Настройте защищенный HTTPS для всех соединений. Установите SSL/TLS-сертификат, чтобы предотвратить перехват информации злоумышленниками и убедитесь, что она передается только по защищенным каналам.

Шифруйте данные при хранении. Используйте надежные алгоритмы шифрования, такие как AES-256. Это защитит информацию в случае утечки или несанкционированного проникновения в хранилище.

Хэшируйте пароли. Никогда не храните пароли в открытом виде. Используйте современные алгоритмы хэширования, такие как bcrypt, Argon2 или PBKDF2, чтобы защитить пароли пользователей. Добавляйте «соль» к каждому паролю перед хэшированием для повышения безопасности.

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

Контролируйте права на резервные копии и логи. Скрывайте файлы с резервной информацией и логами от общего доступа. Раздавайте права только тем, кому они нужны.

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

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

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

Посмотрим на самые распространенные виды инъекций.

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

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

Cross-Site Scripting, XSS. Атака, при которой злоумышленник внедряет вредоносный код в веб-страницы. Например, если сайт не экранирует ввод пользователя, злоумышленник может вставить скрипт, который выполнится в браузере другого пользователя, что приведет к краже информации или другим вредоносным действиям. В этой статье подробно разобрали XSS-атаки и рассказали, как от них защищаться.

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

Если злоумышленник в поле логина введет:

А в поле пароля оставит пустую строку, итоговый запрос станет:

Условие OR 1=1 всегда истинно, а все после игнорируется. Система «подумает», что логин и пароль верны, и даст злоумышленнику доступ.

Как предотвратить уязвимость

Рассказываем о простых методах, которые помогут защититься от инъекций.

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

Например, в PHP это можно сделать с помощью PDO:

Используйте LIMIT и другие SQL-контролы. В случае SQL-инъекции, использование LIMIT в запросах может предотвратить массовую утечку, например:

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

Используйте ORM или высокоуровневые фреймворки с осторожностью. Такие инструменты, как SQLAlchemy (Python), Hibernate (Java) или Django ORM, могут защитить от инъекций, но только если используются подготовленные выражения и параметризованные запросы. Убедитесь, что вы правильно настраиваете ORM для предотвращения инъекций.

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

Используйте безопасные API и библиотеки. Для выполнения системных команд, запросов к базе данных или работы с LDAP используйте безопасные API, которые предотвращают инъекции. Например, вместо прямого выполнения команд ОС через exec или system, используйте библиотеки, которые экранируют или параметризуют ввод.

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

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

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

Рассмотрим несколько распространенных ошибок проектирования.

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

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

Отсутствие ограничений на частоту операций. Система не ограничивает число попыток восстановления пароля, из-за чего становится уязвимой к атакам перебора.

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

Допустим, в приложении есть функция изменения номера телефона. Разработчики решили, что проверка прав не нужна, так как пользователь уже авторизован.

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

Как предотвратить уязвимость

Чтобы не допустить небезопасного дизайна, нужно учитывать риски еще на этапе проектирования.

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

Используйте Threat Modeling. Проводите анализ угроз на этапе проектирования, чтобы выявить потенциальные уязвимости в бизнес-логике. Это поможет заранее определить, где могут возникнуть проблемы, и разработать меры защиты.

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

Ограничивайте частоту операций. Внедрите ограничения на количество попыток выполнения критических операций, например, входа в систему и восстановления пароля.

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

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

Даже при корректной реализации система может оставаться уязвимой, если ее компоненты настроены неправильно. Ниже — примеры таких уязвимостей.

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

Открытые и неиспользуемые функции. Например, лишние порты, сервисы, страницы или учетные записи, которые не используются, но остаются активными — злоумышленник может воспользоваться ими для атаки.

Неизмененные учетные записи и пароли по умолчанию. Многие системы поставляются с предустановленными учетными записями и паролями, например, admin: admin. Если их не изменить, злоумышленник легко войдет в систему.

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

Отсутствие или неправильная настройка заголовков безопасности. Сервер может не отправлять важные заголовки, такие как Content-Security-Policy или X-Content-Type-Options, или эти заголовки могут быть настроены небезопасно.

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

Как предотвратить уязвимость

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

Меняйте настройки сразу после установки. Задавайте сложные пароли для административных учетных записей и удаляйте заводские пароли. Ограничьте возможность входа в административные панели — например, разрешите подключение только с определенных IP-адресов.

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

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

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

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

Например, компания разрабатывает сервис на Python и использует фреймворк Django. Несколько месяцев команда не обновляет Django, а позже появляется информация о том, что в их версии фреймворка есть уязвимость для SQL-инъекций. Разработчики выпускают обновление, но его никто не устанавливает. В итоге хакеры используют уязвимость и получают доступ к базе данных.

Другой пример — устаревшая библиотека JavaScript, например, jQuery 1.9.0. Если в ней есть ошибка, злоумышленники могут внедрить вредоносный код через XSS-атаку — межсайтовый скриптинг.

Как предотвратить уязвимость

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

Создайте полный перечень всех компонентов. Учитывайте не только основные библиотеки, но и все зависимости, включая косвенные. Используйте файлы манифестов, такие как package. json и requirements. txt, для отслеживания версий.

Регулярно проверяйте компоненты на уязвимости. Подпишитесь на рассылки безопасности для используемых технологий. OWASP рекомендует использовать инструменты вроде Dependency-Check для автоматического сканирования.

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

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

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

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

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

К уязвимости приводят разные ошибки в реализации механизма аутентификации. Ниже — распространенные примеры.

Доступны слабые пароли. Пользователи могут устанавливать простые пароли, такие как «123 456» или «password». Такие комбинации легко угадываются или подбираются с помощью автоматических скриптов.

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

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

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

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

Как предотвратить уязвимость

Чтобы защитить систему, важно устранить ключевые ошибки в аутентификации и идентификации.

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

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

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

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

Ограничьте попытки ввода пароля. Блокируйте аккаунт после нескольких неудачных попыток входа.

Шифруйте пароли. Храните их в виде безопасных хэшей. Подойдут алгоритмы bcrypt, Argon2 или PBKDF2.

Надежно управляйте сессиями. Генерируйте новые идентификаторы сессий после аутентификации. Устанавливайте разумные сроки действия сессий и обязательно инвалидируйте их после выхода пользователя.

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

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

Севрис становится уязвимым, если:

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

Например, В 2020 году произошел реальный инцидент с атакой на цепочку поставок — взлом SolarWinds. Компонент программы SolarWinds Orion обновлялся через официальный сервер разработчиков, однако злоумышленники внедрили вредоносный код в один из пакетов обновления.

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

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

Как предотвратить уязвимость

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

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

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

Внедрите инструменты безопасности цепочки поставок. Используйте OWASP Dependency Check или OWASP CycloneDX для выявления уязвимостей в компонентах.

Организуйте процесс проверки изменений. Внедрите ревью кода и конфигураций для предотвращения попадания вредоносного кода в пайплайн.

Защитите CI/CD конвейер. Обеспечьте правильное разделение, конфигурацию и контроль доступа в процессах сборки и развертывания.

Защитите сериализованные данные. Не отправляйте неподписанные или незашифрованные сериализованные объекты ненадежным клиентам без проверки их целостности.

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

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

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

Как предотвратить уязвимость

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

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

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

Обеспечьте защищенное хранение логов. Используйте централизованное хранилище с контролем целостности данных. Применяйте механизмы WORM (Write Once Read Many) для важных журналов аудита.

Внедрите процесс реагирования на инциденты. Разработайте четкие процедуры обработки предупреждений. Обеспечьте эскалацию критических инцидентов в соответствии с принятыми стандартами (NIST 800−61r2).

Централизуйте и защищайте логи. Собирайте все логи в одном месте с помощью систем, таких как ELK Stack, Splunk или Graylog. Шифруйте логи, не смогли их прочитать или использовать.

Server-Side Request Forgery (SSRF) — популярная уязвимость веб-сервисов, с помощью которой злоумышленники заставляют сервер делать запросы к произвольным адресам. Проблема возникает, если приложение доверяет пользовательским данным и не проверяет их.

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

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

Сервер загружает файл по указанному адресу. Но что если хакер вводит URL, который ведет к внутреннему ресурсу, например:

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

Успешность такой атаки зависит от типа запроса, конфигурации сети, настроек внутренних сервисов и дополнительных мер защиты.

В облачных приложениях атака может быть еще опаснее. Например, злоумышленник может запросить:

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

Как предотвратить уязвимость

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

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

Валидируйте все входные данные. Тщательно проверяйте и очищайте все данные, которые предоставляет клиент. Реализуйте строгую проверку URL, в том числе на схему, порт и назначение.

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

Контролируйте локальный трафик. Не размещайте критически важные сервисы, такие как OpenID, на фронтенд-системах. Ограничивайте доступ к localhost и другим внутренним интерфейсам.

Используйте дополнительные меры защиты. Для систем с высокими требованиями к безопасности применяйте VPN или другие механизмы сетевого шифрования. Регулярно пересматривайте и обновляйте правила фильтрации.

Читайте нашу статью, чтобы узнать больше о том, как работает SSRF-атака и как обезопасить сайт от подделки серверных запросов.

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