Безопасность веб-приложений

E-mail
sarybaeva_a@tsiauca.kg
2
Стандарт обеспечения
безопасности веб-приложений
 Веб-приложения — неотъемлемая часть
“ рабочего процесса большинства организаций.
Они аккумулируют в себе огромное количество
данных, обладающих коммерческой
ценностью.
Поэтому способствовать обеспечению
безопасности веб-приложений — одна из
ключевых задач для минимизации финансовых
и репутационных рисков бизнеса.
Зачем нужна защита web-приложений?

Безопасность веб-приложений
— это защитные меры, при
которых злоумышленник не
сможет получить доступ к
конфиденциальным данным как
извне при попытке взлома, так и
внутри компании через
нелегитимный доступ.
Использование веб-приложений в бизнесе
и в работе с конфиденциальными данными
невозможно без продуманной
всесторонней защиты от всех типов
существующих угроз и предиктивным
подходом к безопасности.
“ Приложения доступны из Интернета,
чем привлекают внимание
злоумышленников.
Для получения доступа к
конфиденциальным данным в них
содержащихся, они применяют
разнообразные векторы атак.
“
Использование рекомендаций
Open Web Application Security Project (OWASP)
давно стало стандартом обеспечения
безопасности веб-приложений.
Рейтинг угроз OWASP Top 10 обновляется каждые
3-4 года.
“ OWASP Top 10 – это отчет или
информационный документ, в котором
перечислены основные проблемы, связанные
с безопасностью веб-приложений.
Он регулярно обновляется, чтобы постоянно
отображать 10 наиболее серьезных рисков, с
которыми сталкиваются организации.
10 самых опасных уязвимостей веб-приложений
по итогам 2021 года

https://owasp.org/Top10/
10 самых опасных уязвимостей веб-приложений
по итогам 2021 года

А01:2021 - Нарушение контроля доступа (Broken Access Control)

А02:2021 - Сбои в криптографии (Cryptographic Failures)

А03:2021 - Внедрение кода (Injection)

А04:2021 - Небезопасный дизайн (Insecure Design)

А05:2021 - Неправильная конфигурация (Security Misconfiguration)

А06:2021 - Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components)

А07:2021 - Ошибки идентификации и аутентификации (Identification and Authentication Failures)

А08:2021 - Нарушение целостности данных и программного обеспечения (Software and Data Integrity Failures)

А09:2021 - Журнал безопасности и сбои мониторинга (Security Logging and Monitoring Failures)

А10:2021 - Подделка запросов со стороны сервера или же SSRF (Server-Side Request Forgery)
Нарушение контроля доступа
(Broken Access Control)
А01. Нарушение контроля доступа
(Broken Access Control)

Контроль доступа – это применение

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

Контроль доступа — это

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

Идентификация — процедура, в результате выполнения которой для

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

Аутентификация — процедура проверки подлинности, например

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

Авторизация предоставляет пользователю права на выполнение

определённых действий, а также процесс проверки
Авторизация (подтверждения) данных прав при попытке выполнения этих
действий.
Основные компоненты

id1258745692

Идентификация Аутентификация Авторизация

Определение Проверка Доступ
Кто там? Чем докажешь? Открываю
Типы контроля доступа

Существуют несколько типов контроля доступа с точки зрения пользователя.

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

Уязвимости некорректного контроля

доступа часто встречаются, и как
1. Вертикальное повышение правило, относятся к критическим
уязвимостям в приложении.
привилегий – получение
доступа к функционалу, к
Доступный без аутентификации
которому доступ не
функционал администратора
предполагался. (вертикальное повышение
привилегий)
2. Горизонтальное
повышение привилегий –
получение доступа к Информация о других
ресурсам, принадлежащим пользователях (заказах, и т.д.)
другим пользователям. (горизонтальное повышение
привилегий)
Распространенные примеры уязвимостей

- это ссылки на объекты, при обращении к которым

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

CSRF-атаки направлены на осуществление действий

от имени пользователя в уязвимом приложении без
Межсайтовая его ведома.
подделка
запросов (CSRF) Например причиной уязвимости м.б. передача
сессионных данных (Cookie) при любом запросе к
приложению.
Способы защиты

Небезопасные Если ресурс не должен быть доступен публично, то необходимо

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

На уровне кода необходимо определять для каждого ресурса, кто

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

Необходимо проводить проверку реализации и тестирование

механизмов авторизации.

Межсайтовая
Использование CSRF-токенов – случайных значений,
подделка
отправляемых с запросом.
запросов (CSRF)
Данный механизм уже реализован во многих фреймворках.
Сбои в криптографии
(Cryptographic Failures)
А02. Сбои в криптографии (Cryptographic Failures)
Данная уязвимость возникает
в приложениях, в которых не
защищены должным образом
конфиденциальные данные:
данные банковских карт,
имена , пароли пользователей
и т.д.
• Первое, что нужно сделать, это
определить потребности в
защите данных при передаче и в
состоянии покоя.
• Определите, какие данные
являются конфиденциальными в
соответствии с законами о
конфиденциальности,
нормативными требованиями
или потребностями бизнеса.
Раскрытие информации
Как предотвратить?
Классифицируйте данные, обрабатываемые, хранимые или передаваемые приложением.
Определите, какие данные являются конфиденциальными в соответствии с законами о
конфиденциальности, нормативными требованиями или потребностями бизнеса.

Не храните конфиденциальные данные без необходимости. Откажитесь от него как можно

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

Убедитесь, что все конфиденциальные данные зашифрованы в состоянии покоя.

Убедитесь в наличии современных и надежных стандартных алгоритмов, протоколов и

ключей; используйте надлежащее управление ключами.

Шифруйте все передаваемые данные с помощью безопасных протоколов, таких как TLS с
шифрами прямой секретности (FS), приоритизацией шифрования сервером и
параметрами безопасности. Применяйте шифрование с помощью директив, таких как
HTTP Strict Transport Security (HSTS).
Как предотвратить?
Отключите кэширование ответов, содержащих конфиденциальные данные.

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

Не используйте устаревшие протоколы, такие как FTP и SMTP, для передачи

конфиденциальных данных.

Не используйте устаревшие протоколы, такие как FTP и SMTP, для передачи

конфиденциальных данных.

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

памяти в виде массивов байтов. Если используете пароль, то он должен быть
преобразован в ключ с помощью соответствующей функции получения ключа на основе
пароля.
Избегайте устаревших криптографических функций и схем заполнения, таких как MD5,
SHA1, PKCS номер 1 v5.
Самостоятельно проверьте эффективность конфигурации и настроек.
Внедрение кода
(Injection)
Приложение уязвимо для атаки, когда:
Предоставленные пользователем
данные не проверяются, не
фильтруются и не
обрабатываются приложением.
Враждебные данные
используются в параметрах
поиска объектно-реляционного
сопоставления (ORM) для
извлечения дополнительных
конфиденциальных записей.
Динамические запросы или не
параметризованные вызовы без
контекстно-зависимого
экранирования используются
непосредственно в
интерпретаторе.
Враждебные данные
используются напрямую или
объединяются. SQL или команда
содержит структуру и
вредоносные данные в
динамических запросах,
командах или хранимых
процедурах.
Внедрение кода
Как предотвратить

Предотвращение внедрения Предпочтительным вариантом считается использование безопасного

требует хранения данных API, который полностью исключает использование интерпретатора,
отдельно от команд и запросов: предоставляет параметризованный интерфейс или переходит на
инструменты объектно-реляционного сопоставления (ORM).

Примечание. Даже при параметризации хранимые процедуры все равно

могут вводить SQL-инъекцию, если PL/SQL или T-SQL объединяют
запросы и данные или выполняют враждебные данные с помощью
EXECUTE IMMEDIATE или exec().

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

"белую" проверку ввода на специальные символы, используя специальный синтаксис
стороне сервера. Это не полная экранирования для этого интерпретатора.
защита, так как многим
приложениям требуются
специальные символы, такие как
Используйте ОГРАНИЧЕНИЯ и другие элементы управления SQL в
текстовые области или API для
запросах, чтобы предотвратить массовую утечку записей в случае
мобильных приложений.
внедрения SQL.
Недостатки проектирования
(Insecure Design)
А04. Недостатки проектирования
(Insecure Design)
Новая категория для 2021
года, в которой основное
• Уязвимости небезопасного
внимание уделяется рискам,
связанным с недостатками
проектирования.
Небезопасный дизайн включает в
себя различные риски,
возникающие из-за игнорирования
передовых методов
проектирования и архитектуры ,
начиная с этапа планирования до
фактической реализации.
дизайна возникают, когда
разработчики, QA и/или
специалисты по безопасности не
могут предвидеть и оценить
угрозы на этапе разработки кода.
Эти уязвимости также являются
следствием несоблюдения
передовых методов безопасности
при разработке приложения.
Уязвимости бизнес-логики
Как предотвратить?

Установите и используйте жизненный цикл безопасной разработки с профессионалами AppSec, чтобы

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

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

Разделите уровни на системные и сетевые в зависимости от потребностей в воздействии и защите.

Выделите арендаторов по дизайну на всех уровнях.

Ограничьте потребление ресурсов пользователем или сервисом.

Неправильная конфигурация
(Security Misconfiguration)
Неправильная конфигурация
Приложение может быть уязвимым, если:

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

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

Параметры безопасности на серверах приложений, платформах приложений (например, стойки,

пружины, ASP.NET), библиотеки, базы данных и т.д. не настроены на безопасные значения.
Сервер не отправляет заголовки или директивы безопасности, или они не настроены на
безопасные значения.
Программное обеспечение устарело или уязвимо (см. 06:2021 - Уязвимые и устаревшие
компоненты).
Как предотвратить?

Повторяемый процесс упрочнения позволяет быстро и легко развернуть

другую среду, которая соответствующим образом заблокирована.

Минимальная платформа без каких-либо ненужных функций, компонентов,

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

Сегментированная архитектура приложений обеспечивает эффективное и

безопасное разделение между компонентами или клиентами с помощью
сегментации, контейнеризации или облачных групп безопасности (ACL).

Отправка директив безопасности клиентам, например, заголовков

безопасности.

Автоматизированный процесс проверки эффективности конфигураций и

настроек во всех средах.
Уязвимые и устаревшие
компоненты
(Vulnerable and Outdated
Components)
Уязвимые и устаревшие компоненты
(Vulnerable and Outdated Components)

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

Если не знаете версии всех используемых вами компонентов (как на стороне клиента,
так и на стороне сервера). Это включает компоненты, которые вы используете
напрямую, а также со стороны.

Если программное обеспечение незащищено, не поддерживается или устарело. Это

включает операционную систему, веб-сервер/сервер приложений, систему управления
базами данных (СУБД), приложения, API и все компоненты, среды выполнения и
библиотеки.
Если не проводите регулярную проверку на наличие уязвимостей и не подписываетесь
на бюллетени по безопасности, относящиеся к используемым вами компонентам.
Если своевременно не исправите или не обновите базовую платформу, фреймворки и
зависимости с учетом рисков. Это обычно происходит в средах, когда исправление
выполняется ежемесячно или ежеквартально под контролем изменений, оставляя
организации открытыми для ненужного воздействия на дни или месяцы.

Если разработчики программного обеспечения не проверяют совместимость

обновленных, модернизированных или исправленных библиотек.
Как предотвратить?

Удалить неиспользуемые зависимости, ненужные функции, компоненты, файлы и

документацию.
Непрерывная инвентаризация версий как клиентских, так и серверных компонентов (например,
фреймворков, библиотек) и их зависимостей с использованием таких инструментов, как версии,
проверка зависимостей OWASP, retire.js, и т.д. Постоянно контролируйте источники, такие как
Общие уязвимости и риски (CVE), и Национальная база данных уязвимостей (NVD), на предмет
уязвимостей в компонентах. Используйте инструменты анализа состава программного
обеспечения для автоматизации процесса. Подпишитесь на уведомления по электронной почте
об уязвимостях безопасности, связанных с используемыми вами компонентами.
Приобретайте компоненты только из официальных источников по защищенным ссылкам.
Отдавайте предпочтение подписанным пакетам, чтобы уменьшить вероятность включения
измененного вредоносного компонента (см. A08:2021 - Сбои в целостности программного
обеспечения и данных).

Следите за библиотеками и компонентами, которые не поддерживаются или не создают

исправлений безопасности для более старых версий. Если исправление невозможно,
рассмотрите развертывание виртуального исправления для мониторинга, обнаружения или
защиты от проблемы.
Ошибки идентификации и
аутентификации
(Identification and Authentication
Failures)
Примеры уязвимостей
Проблемы с аутентификацией
позволяют злоумышленнику
использовать различные
методы для получения
контроля над любой учётной
записью в системе. В худшем
случае злоумышленники
получают полный контроль
над системой.
Подтверждение личности
пользователя, аутентификация и
управление сеансами имеет
решающее значение для защиты от
атак, связанных с аутентификацией.
Эта уязвимость опасна ещё и
потому, что веб-сайты с проблемами
аутентификации очень
распространены.
Проблема возникает из-за ошибок в
управлении сеансом, что позволяет
злоумышленникам взломать
пароли, ключи безопасности и т.д.
Уязвимости аутентификации

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

Допускает перебор или другие автоматические атаки.

Разрешает стандартные, слабые или хорошо известные пароли, например, "Password1" or "admin/admin". Разрешает
использование паролей по умолчанию, слабых или хорошо известных паролей, таких как "Password1" или " admin/admin".

Использует слабые или неэффективные процессы восстановления учетных данных и забытых паролей, такие как "ответы,
основанные на знаниях" (Вопрос-Ответ), которые нельзя сделать безопасными.

Использует хранилища данных с простым текстом, зашифрованными или слабо хэшированными паролями

Имеет отсутствующую или неэффективную многофакторную аутентификацию.

Предоставляет идентификатор сеанса в URL-адресе.

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

Неправильно аннулирует идентификаторы сеансов. Сеансы пользователей или токены аутентификации (в основном токены
единого входа (SSO)) не считаются недействительными во время выхода из системы или периода бездействия.
Как предотвратить?
Там, где это возможно, внедряйте многофакторную аутентификацию, чтобы предотвратить автоматический
ввод учетных данных, перебор и атаки на повторное использование украденных учетных данных.

Согласовать длину пароля, сложность и политики ротации с N.

Изучите Рекомендации Национального института стандартов и технологий (NIST) 800-63b в разделе 5.1.1 для
запоминания секретов или других современных, основанных на фактических данных политик паролей.

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

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

Используйте защищенный встроенный менеджер сеансов на стороне сервера, который генерирует новый
случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификатор сеанса не
должен содержаться в URL-адресе, надежно храниться и быть недействительным после выхода из системы,
простоя и абсолютных тайм-аутов.
Нарушение целостности данных и
программного обеспечения
(Software and Data Integrity Failures)
А08. Нарушение целостности данных и программного обеспечения
(Software and Data Integrity Failures)

Уязвимость позволяет
злоумышленнику удалённо
выполнять код в приложении, • Примером этого является
подделывать или удалять ситуация, когда приложение
полагается на плагины,
сериализованные (записанные
библиотеки или модули из
на диск) объекты, проводить
ненадежных источников,
атаки путём внедрения, хранилищ и сетей доставки
повторного воспроизведения. контента (CDN).
Эта проблема безопасности
приложений очень серьезная и,
к сожалению, затрагивает
большинство современных
систем.
Совместное использование ресурсов между
источниками
Как предотвратить?

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

Убедитесь, что библиотеки и зависимости, такие как npm или Maven, используют надежные хранилища. Если у
вас более высокий профиль риска, подумайте о размещении внутреннего проверенного репозитория с
известными качествами.
Убедитесь, что средство обеспечения безопасности цепочки поставок программного обеспечения, такое как
проверка зависимостей OWASP или OWASP Cyclone DX, используется для проверки того, что компоненты не
содержат известных уязвимостей.
Убедитесь, что существует процесс проверки изменений кода и конфигурации, чтобы свести к минимуму
вероятность того, что вредоносный код или конфигурация могут быть внедрены в ваш программный
конвейер.
Убедитесь, что ваш конвейер CI/CD имеет надлежащее разделение, конфигурацию и контроль доступа, чтобы
обеспечить целостность кода, проходящего через процессы сборки и развертывания.

Убедитесь, что неподписанные или незашифрованные сериализованные данные не отправляются

ненадежным клиентам без какой-либо проверки целостности или цифровой подписи для обнаружения
подделки или воспроизведения сериализованных данных.
Журнал безопасности и сбои
мониторинга
(Security Logging and Monitoring
Failures)
А09. Журнал безопасности и сбои мониторинга

Время от атаки до обнаружения

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

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

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

управлению журналами.

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

Убедитесь, что транзакции с высокой стоимостью имеют аудиторский след с контролем

целостности для предотвращения подделки или удаления, например, таблиц только на
добавление базы данных или аналогичных.
Команды DevSecOps должны наладить эффективный мониторинг и оповещение для быстрого
обнаружения подозрительных действий и реагирования на них.
Подделка запросов
на стороне сервера
(Server-Side Request Forgery)
А10. Подделка запросов на стороне сервера

Ошибки SSRF (server side request

forgery — программный код, с
помощью которого можно • Это дает злоумышленнику
заставить уязвимое приложение возможность перенаправить
созданный запрос в неожиданное
сделать запрос на
место назначения, обходя защиту
предоставленный URL)
брандмауэром, VPN или другими
возникают когда веб- средствами управления доступом
приложение извлекает к сети.
удаленный ресурс без проверки
предоставленного
пользователем URL-адреса.
Подделка запросов на стороне сервера
Подделка межсайтовых запросов

Подделка межсайтовых
запросов (также
известная как CSRF) — это
уязвимость веб-
безопасности, которая
позволяет злоумышленнику
побуждать пользователей
выполнять действия,
которые они не собираются
выполнять.
Как предотвратить?

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

Используйте схему URL-адреса, порт и пункт назначения с положительным списком разрешений.

Не отправляйте необработанные ответы клиентам.

Отключите перенаправление HTTP.

Следите за согласованностью URL-адресов, чтобы избежать атак, например, повторная привязка DNS и
условия гонки “время проверки до времени использования” (TOCTOU).

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

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

системах (например, OpenID). Управляйте локальным трафиком в этих системах (например, localhost). Для
интерфейсов с выделенными и управляемыми группами пользователей используйте сетевое шифрование
(например, VPN) в независимых системах для высокого уровня защиты.
Контакты
E-mail
sarybaeva_a@tsiauca.kg

Телефон
+(996) 551 428080