Как обеспечить безопасность приложения? 8 ответов от безопасников

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

А так ли это на самом деле?

Какие уязвимости можно найти в приложении?

Ещё живут различные инъекции (SQL, NoSQL, LDAP, OS, XML, XQuery, XPath, XSLT), LFI-уязвимости, закладки (внедрённые в код функции, которые срабатывают в определённый момент), слабые алгоритмы шифрования, небезопасная работа с логами и cookie, а также утечка информации через социнжиниринг.

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

И это лишь вершина айсберга.

Правда ли, что львиная доля атак приходится на бреши в механизмах аутентификации?

Согласно статистике Positive Technologies, наиболее часто встречающиеся уязвимости веб-приложений за 2019 год связаны с неправильной настройкой безопасности. А вот самому высокому риску подвержены сайты со слабой аутентификацией. Такая проблема была обнаружена в 45% исследованных веб-приложений:

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

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

Обеспечение безопасности приложения — это задача безопасников?

Не совсем, ведь уже на стадии разработки нужно обращать внимание на очевидные уязвимости.

Разработчик должен с первой редакции сайта или приложения заложить основные инструменты защиты данных пользователя, например Web Application Firewall. В дальнейшем, с выходом патчей, закрывать появляющиеся уязвимости. В идеальной ситуации разработчик должен либо самостоятельно, либо с привлечением дополнительных специалистов тестировать продукт на проникновение, раз за разом применяя популярные методы взлома и после анализируя полученный результат.

Что включает в себя обеспечение безопасности приложения?

Это все меры, в том числе и те, которые предшествуют этапу разработки:

1. Корректная постановка цикла разработки и деплоя. Это также включает выбор релевантного подхода к разработке (Agile/Waterfall), применение лучших практик DevOps, использование доверенного серверного оборудования.
2. В команде должен быть один или несколько специалистов, которые отвечают за информационную безопасность.
3. Сформированная модель угроз безопасности — метрики, которые нужно постоянно отслеживать, особенно при каждом обновлении или изменении внешних факторов. Стоит понимать, что модели угроз будут разными для разных приложений.
4. Использование технических средств анализа защищённости кода.
5. Использование защищённой среды разработки.

Application security — сложная задача, особенно в больших командах. Здесь важна грамотная работа архитекторов, которая предусмотрит механизмы безопасности для каждого из «кирпичиков» проекта, тем самым обеспечивая многоуровневую защиту продукта.

Какими бывают технические средства анализа защищённости кода?

Основной пласт анализаторов включает в себя:

• Статические — это анализаторы исходного кода на базе механизма статического анализа (SAST). Проверка происходит без запуска самой программы на промежуточных этапах разработки или на этапе сборки. К SAST-решениям относятся Synopsys, AppScan, Checkmarks, Veracode, Appercut, Application Inspector, Micro Focus.
• Динамические — применяются к готовому коду и ориентированы в основном на веб-приложения. Работают на базе динамического тестирования безопасности (DAST) через подачу URL-адреса в автоматический сканер.
• Интегрированные в CI (Continuous Integration) — сканируют статический и динамический код.
• Инструменты пентестера.

Как создать защищённую среду разработки?

Стоит помнить, что обеспечить безопасность приложения можно только комплексно, поэтому уделяйте внимание каждому из этапов:

1. Сегментировать сеть и организовать управление сетевыми проходами.
2. Настроить права доступа для каждой роли.
3. Хранить пароли в хешированном виде с применением так называемой соли.
4. Организовать защищённый удалённый доступ.
5. Управлять обновлениями.
6. Мониторить и документировать.
7. Обезличивать важные данные при работе с БД в тестовом режиме.

На что должен обращать внимание разработчик, чтобы защитить приложение от взлома?

Позаботиться о безопасности сервиса лучше на самых ранних этапах его разработки. В этом помогут проекты от сообщества OWASP, например руководства «Проактивная защита: Топ-10 требований OWASP» (набор практик для изначального повышения безопасности приложения) и рейтинг 10 самых опасных угроз безопасности веб-приложений OWASP Top 10. Также важным является включение безопасности как составляющей цепочки CI/CD вашего приложения, например использование SAST и DAST-решений. Причём необязательно сразу покупать и внедрять коммерческие решения, ведь существуют и вполне достойные варианты из мира свободного ПО.

По моему опыту, один из главных шагов к безопасности приложения — это ограничение функциональности для каждого пользователя по принципу need-to-know. Этот принцип возник в военной среде, однако полезен и в разработке: соблюдая его, вы не даёте пользователю получать больше информации, чем ему нужно.Не менее важны процессы код-ревью и независимого анализа защищённости. Для второго можно привлекать собственную команду безопасности, обращаться в специализированные компании или добавить приложение в программу bug bounty, чтобы сотни исследователей со всего мира непрерывно искали за вас баги.Также важно изучать уязвимости чужого кода, который вы вносите в проект: посмотрите issue на GitHub, проверьте продукт в базе уязвимостей. Есть замечательный проект наших коллег Vulners, который агрегирует данные по существующим уязвимостям из различных источников.

На заключительных этапах разработки не будет лишним позаботиться о защите кода от чтения и дизассемблирования. Здесь тоже имеются проверенные временем методики: от простой обфускации до применения ассемблерных вставок и продвинутых средств защиты от отладчиков. Вообще, хорошей практикой является «чистка» кода перед отправкой его в продакшн. Пользователю ведь никак не помогут комментарии, объясняющие, как работает тот или иной вызов либо функция. А вот для атакующего это большое подспорье при анализе продукта. Кроме того, следует избегать прописывания различных конфиденциальных данных внутри самого кода. Например, не рекомендуется встраивать ссылки с данными авторизации на сервере для автоматического тестирования.

А как обстоят дела с безопасностью мобильных приложений?

Безопасная разработка мобильного приложения включает три этапа.Во-первых, важно заранее учитывать, что приводит к уязвимостям, и ещё во время разработки предусмотреть все меры профилактики. Так, для предотвращения утечки данных необходимо использовать криптографические алгоритмы, многофакторную аутентификацию, генерировать непредсказуемые идентификаторы сессии и хранить авторизационные токены в наиболее безопасных частях операционной системы.Безопасность передачи информации осуществляется за счёт подтверждения достоверности источников связи, корректных версий SSL и проверки согласования. Права доступа к скрытым разделам приложения необходимо давать только узкому кругу ответственных за них специалистов.Далее необходимо протестировать приложение на предмет наличия подобных уязвимостей. В основном используются методы белого и чёрного ящика. Метод белого ящика (статистическое тестирование безопасности SAST) подразумевает проверку разработчиком, имеющим доступ к коду. Метод чёрного ящика предполагает анализ только пользовательского опыта, без оценки кода. Тестировать можно вручную или с помощью специальных сервисов.И последнее, перед собственно отработкой выявленных уязвимостей расставьте приоритеты. В первую очередь устраните ошибки, при которых работа приложения невозможна. Затем идут критические баги: зависание системы или временные падения. После смотрите на ошибки, не влияющие на работу, например, недочёты дизайна. В самом конце устраняйте мелкие баги.Рекомендую использовать параметризованные запросы к базе данных, не конструировать запросы внутри системы, для доступа к БД использовать отдельную учётку и не забывать про журналы безопасности.

Резюмируя

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

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