Получить консультацию по Solar appScreener

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

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

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

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

  • Инъекции / инъекционные атаки. Сводятся к внедрению в форму веб-интерфейса специальных кодов, содержащих SQL (чаще всего) или другие виды запросов. При реализации этой угрозы злоумышленники получают доступ к базам данных, которые используются веб-приложениями, и могут читать, модифицировать или удалять хранящуюся там информацию. Риски от таких угроз варьируют от кражи конфиденциальных данных до удаления важной для компании информации и фактической блокировки ее работы. Для предотвращения таких угроз уже на этапе проектирования веб-приложения нужно предусмотреть фильтрацию (валидацию) входных данных, передающихся через веб-формы и другие средства взаимодействия с пользователями / сторонними ресурсами.

  • XSS – межсайтовый скриптинг. Механизм атаки схож с инъекцией. В этом случае в приложение внедряется код (как правило, JavaScript), который выполняется в браузере на стороне пользователя, что чревато кражей пользовательских данных, вводимых им в приложении, либо cookies. При реализации такой угрозы возможна подмена информации (например, отображение неверных сведений для денежного перевода, чтобы пользователь отправил деньги на счет злоумышленников). Для предотвращения таких инцидентов при проектировании веб-приложений следует предусмотреть экранирование пользовательского ввода (очистку ввода).

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

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

Это далеко не полный перечень. При проектировании важно предусмотреть нейтрализацию недочетов системы аутентификации и хранения сессий (2FA – в помощь). Нужно отказаться от прямых ссылок на объекты (поможет перенос директории с файлами на уровень выше, вне корня веб-приложения, либо запрет прямого скачивания через .htaccess). Ни в коем случае нельзя хранить пароли открытым текстом (вариант защиты – использование MD5 и salt).

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

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

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

В первом случае применяются библиотеки и справочные системы с описанием типовых уязвимостей. Разработчики изучают их и проверяют код приложения на возможность реализации описанных в них угроз. Популярны такие источники сведений о типовых уязвимостях, как Open Web Application Security Project (OWASP), Web Application Security Consortium (WASC) или Open Source Security Testing Methodology Manual (OSSTMM).

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

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

  • SAST. Метод белого ящика, или статический анализ кода. Один из наиболее популярных среди разработчиков. Его главный плюс – проверка без запуска веб-приложения (а значит, возможность использовать на любом этапе разработки). SAST-инструменты, такие как наш Solar appScreener и его аналоги, сканируют код и выявляют в нем ошибки/уязвимости, которые могут привести к реализации угроз информационной безопасности. Инструменты легко встраиваются в процесс разработки. Пользоваться ими могут не только разработчики, но и специалисты по ИБ, например.

  • IAST. Объединяет подходы, используемые в DAST и SAST. Сложнее в реализации, чем статический анализ, поэтому не так популярен. Такие инструменты анализируют код веб-приложения, конфигурации, потоки данных, запросы, подключаемые компоненты (библиотеки, фреймворки и проч.).

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

ДРУГИЕ СТАТЬИ ПРОДУКТА

Еще больше о наших возможностях

Zero Day уязвимость: что такое уязвимость нулевого дня

Zero Day уязвимость: что такое уязвимость нулевого дня

Узнать больше
White Box-тестирование: что это такое, и когда применяется

White Box-тестирование: что это такое, и когда применяется

Узнать больше
Cross Site Scripting: что такое XSS-атаки и как от них защититься

Cross Site Scripting: что такое XSS-атаки и как от них защититься

Узнать больше