Тестирование безопасности в качестве базовой защиты Приложения должны быть защищены от серьезных угроз безопасности, зная о распространенных уязвимостях. Злоумышленники часто вкладывают больше ресурсов, чем защитники, а средства защиты, как правило, реагируют, поэтому системы должны, по крайней мере, противостоять известным угрозам и применять превентивные меры, используя статистику и аналитику. Тестирование безопасности неизбежно при веб-разработке и требует знания категорий угроз и векторов атак. Тестировщики должны проверять соответствие требованиям безопасности, выявлять уязвимости и предлагать рекомендации по их устранению. Эти возможности существенно повышают профессиональную ценность при одновременном снижении потенциальных потерь данных, информации и финансов.
Топ-10 открытых ресурсов OWASP OWASP ‑ международная некоммерческая организация, занимающаяся повышением безопасности программного обеспечения с помощью анализа данных и глобальных опросов; в ее бесплатных проектах с открытым исходным кодом участвуют тысячи компаний и специалистов. Топ‑10 OWASP является стандартом безопасности веб-приложений де-факто и рекомендуется в качестве основы для снижения рисков. Этот список меняется чаще по мере усиления атак, ранжируется по распространенности и последствиям и дополняется руководствами по тестированию, базами знаний по безопасности, рекомендациями по мобильному тестированию и общими правилами обнаружения атак. На официальном сайте представлено сравнение за 2017-2021 годы, позволяющее отслеживать изменения, новые категории и объединенные риски для анализа на уровне продукта.
Нарушенный Контроль Доступа Приводит к Доступу к Данным с Ограниченным Доступом Отсутствие надежных проверок авторизации позволяет пользователям получать доступ к объектам и функциям, выходящим за рамки их роли. Фоновые запросы и серверные конечные точки без проверки подлинности позволяют злоумышленникам изменять параметры или URL‑адреса для просмотра или модификации чужих данных. К нарушениям относятся IDOR, изменение запросов API и манипулирование токенами или файлами cookie для повышения привилегий. Неконтролируемые входные данные могут даже включать загрузку внешних скриптов или разблокировку неактивных функций, нарушая режим наименьших привилегий.
Криптографические сбои Открывают Доступ к Конфиденциальным Данным Слабая или неправильно используемая криптография приводит к раскрытию паролей, платежных реквизитов, медицинских карт и налоговой информации. Безопасность зависит от надежных алгоритмов, протоколов, генерации и обработки ключей, хеширования и проверки сертификатов. Конфиденциальные данные не должны передаваться открытым текстом; шифруйте их при передаче, хэшируйте пароли с помощью современных алгоритмов и отключайте кэширование конфиденциальных данных. Внимание злоумышленников к краже личных данных усилилось, что повышает требования к правильному использованию криптографии.
Внедрение позволяет скомпрометировать базу данных и систему К недостаткам внедрения относятся запросы SQL и LDAP, внедрение команд операционной системы, неправильное использование синтаксического анализатора XML и внедрение заголовка SMTP. Обработанные входные данные со специальными символами и операторами могут обходить аутентификацию, выполнять эксфильтрацию, изменять базы данных или удалять их. Злоумышленники могут проникнуть на сервер, извлечь информацию и внести изменения в систему.
Небезопасный дизайн открывает путь ко всем другим рискам Недостатки в дизайне и архитектуре, особенно при добавлении новых функций без эффективного контроля, создают системную угрозу. Пробелы в бюджете, плохо продуманные бизнес‑требования, несовершенная бизнес‑логика и неправильно поставленные задачи способствуют рискованному внедрению. Планирование и обеспечение безопасности на всех этапах проектирования, разработки и тестирования имеют решающее значение; даже небольшая функция, содержащая ошибки проектирования, может стать точкой входа для взлома.
Неправильная Настройка Системы Безопасности Усиливает Риск Неправильные разрешения в облачных сервисах, подробные сообщения об ошибках и неправильно настроенные функции безопасности повышают риск. Проблему усугубляют использование уязвимых или устаревших компонентов, задержка обновления и отсутствие автоматической проверки конфигурации в разных средах. В качестве примеров можно привести доступ к общедоступному облаку по умолчанию, трассировку стека, показывающую версии компонентов, и отключенные флаги cookie, позволяющие XSS красть сеансовые файлы cookie.
Устаревшие компоненты подрывают работу стека Безопасность снижается, когда не отслеживаются версии всех клиентских и серверных компонентов и переходных зависимостей. Риски связаны с операционными системами, веб-серверами и серверами приложений, системами баз данных, API, средами выполнения и библиотеками, особенно когда базы, фреймворки и зависимости не обновляются вовремя. Используйте только официальные обновления, заменяйте неподдерживаемые или устаревшие библиотеки поддерживаемыми аналогами и защищайте конфигурации компонентов.
Слабые средства управления идентификацией и сеансом могут привести к захвату учетной записи К недостаткам относятся неправильная проверка сертификата, ненадлежащая аутентификация и фиксация сеанса. Последствия варьируются от раскрытия учетных данных и успешного использования грубой силы до входа в систему с использованием паролей по умолчанию или ненадежных паролей и небезопасных процедур восстановления учетной записи. Небезопасное хранение или передача паролей, отсутствие MFA, идентификаторов сеансов в URL-адресах, повторное использование идентификаторов сеансов и невозможность аннулирования токенов при выходе из системы или бездействии увеличивают риск. Меры по снижению риска включают MFA, устранение учетных данных по умолчанию, проверку новых паролей по известным спискам, согласование политик с NIST, блокирование перечисления с помощью унифицированных сообщений, ограничение скорости входа в систему без использования DoS, регистрацию сбоев с предупреждениями и безопасное управление сеансами на стороне сервера с помощью новых идентификаторов после входа в систему и надлежащих тайм‑аутов.
Нарушения целостности подрывают цепочку поставок Использование плагинов, библиотек или модулей из ненадежных источников или CDN может привести к появлению вредоносного кода и компрометации систем. Автоматические обновления, применяемые без проверки целостности, могут привести к повреждению даже высоконадежных приложений. Средства защиты включают цифровые подписи, надежные хранилища (например, Maven), проверенные внутренние зеркала на наличие профилей повышенного риска, настройки CI, гарантирующие целостность кода при сборке и развертывании, а также предотвращающие отправку неподписанных или незашифрованных данных ненадежным клиентам без проверки целостности.
Недостаточное ведение журнала скрывает атаки Эффективное ведение журнала лежит в основе подотчетности, наглядности, оповещения и судебной экспертизы; сбои включают в себя ненейтрализованный вывод журнала, отсутствие сведений, имеющих отношение к безопасности, и утечку конфиденциальных данных в журналы. Если такие события, как успешный или неудачный вход в систему и динамическое сканирование, не отслеживаются и не активизируются, активные атаки остаются незамеченными. К недостаткам относятся локальные журналы, неясные сообщения, отсутствие пороговых значений и задержки; доступ к журналам должен быть основан на ролях, данные должны быть зашифрованы и обеспечена защита от несанкционированного доступа. Для эффективности обнаружение должно происходить в режиме реального времени или почти в режиме реального времени.
Подделка запросов на стороне сервера превращает серверы в прокси‑серверы SSRF позволяет злоумышленникам заставить сервер отправлять запросы к внутренним или внешним ресурсам, контролируя весь запрос или его части, такие как домен. Приложения, которые получают доступ к удаленным ресурсам или взаимодействуют со сторонними службами, уязвимы, когда запросы обрабатываются пользователем. Доверие к заголовку хоста - распространенный недостаток; злоумышленники могут изменить его с помощью прокси-серверов, поэтому значения должны быть проверены. Меры по устранению проблемы включают внесение адресатов в белый список, блокирование внутреннего доступа с помощью брандмауэра и сетевых списков управления доступом по умолчанию, отказ от ретрансляции необработанных ответов клиентам и отключение перенаправлений.