Безопасность приложений
Безопасность приложения ( англ. Application Security ) включает в себя меры, принимаемые для повышения безопасности приложения, часто путем обнаружения, исправления и предотвращения уязвимостей в безопасности. Для выявления уязвимостей на разных этапах жизненного цикла приложений, таких как проектирование, разработка, развертывание, обновление, обслуживание, используются различные методы. В основном в программах наблюдается рост количества разного рода дефектов и уязвимостей, которые со временем могут нанести существенный вред программному обеспечению.
Термины
[править | править код]- Актив. Ценный ресурс, например: данные в базе данных, деньги на счете, файл в файловой системе или любой системный ресурс.
- Уязвимость. «Слабое место» в программе, которое может быть использовано угрозами для получения несанкционированного доступа к активу.
- Атака . Действие, предпринятое для нанесения вреда активу.
- Угроза. Все, что может использовать уязвимости для получения доступа, повреждения или уничтожения актива.
Методы
[править | править код]Различные методы позволяют находить различные классы уязвимостей безопасности в приложении и наиболее эффективны на определенных этапах жизненного цикла программного обеспечения.
- Whitebox («белый ящик»), или проверка кода. Инженер по безопасности, глубоко разбирающийся в приложении, просматривает исходный код вручную и ищет недостатки безопасности. Благодаря пониманию принципа работы приложения могут быть найдены уникальные уязвимости для данного программного обеспечения.
- Проверка безопасности Blackbox («черный ящик»). Проверка на наличие уязвимостей только посредством использования приложения, исходный код не требуется.
- Пересмотр дизайна. Перед написанием кода, с помощью моделирования угроз.
- Автоматизированная проверка. Существует множество автоматизированных инструментов, которые проверяют недостатки безопасности, часто с более высоким уровнем ложноположительных результатов, чем при участии человека.
- Bug Bounty. Это программа, предлагаемая многими веб-сайтами и разработчиками программного обеспечения, с помощью которой люди могут получить признание и вознаграждение за нахождение уязвимостей.
Правильное использование этих методов для обеспечения максимальной безопасности в течение всего жизненного цикла разработки программного обеспечения является задачей команды, занимающейся вопросами безопасности.
Угрозы приложениям (атаки)
[править | править код]В соответствии с шаблонами и опытом, описываемыми в книге «Improving Web Application Security», ниже приведены классы распространенных угроз / атак безопасности приложений:
| Категория | Угрозы / Атаки |
|---|---|
| Проверка Ввода | Переполнение буфера; межсайтовый скриптинг; внедрение SQL-кода; стандартизация (канонизация) |
| Фальсификация программного обеспечения | Злоумышленник изменяет поведение приложения для выполнения несанкционированных действий, путем бинарного исправления, замены кода или его расширения |
| Аутентификация | Прослушивание сети; атака «грубой силой»; перебор по словарю; воспроизведение файлов cookie; кража учетных данных |
| Авторизация | Повышение привилегий; раскрытие конфиденциальных данных; подделка данных |
| Управление конфигурацией | Несанкционированный доступ к интерфейсам администрирования; несанкционированный доступ к файлам настроек; поиск текстовых данных конфигурации; чрезмерно привилегированные процессы и службы |
| Конфиденциальная информация | Доступ к чувствительному коду или данным в хранилище; подслушивание сети; внедрение вредоносного кода / данных |
| Управление сеансом | Похищение сеанса; атака повторного воспроизведения; атака «человек посередине» |
| Криптография | Генерация не криптографически стойких ключей или плохое управление ключами; слабое или нестандартное шифрование |
| Манипуляция параметрами | Манипулирование строкой запроса, полем формы; манипуляции с файлами cookie; манипулирование заголовком HTTP |
| Управление исключениями | Раскрытие информации; отказ в обслуживании (DoS) |
| Аудит и вход в систему | Пользователь запрещает выполнение операции; злоумышленник использует приложение без следа; злоумышленник скрывает свои следы |
Сообщество OWASP опубликовало список 10 самых уязвимых мест веб-приложений и описывает лучшие методы обеспечения безопасности для организаций, стремясь создать открытые стандарты для отрасли.[1] Основные угрозы безопасности приложений по состоянию на 2017 год:[2]
| Категория | Угрозы / Атаки |
|---|---|
| Внедрение | Внедрение SQL-кода; NoSQL; внедрение команд ОС; объектно-реляционное отображение (ORM); LDAP injection |
| Взлом аутентификации | Атаки с использованием учетных данных (утечки / взломы баз данных); атака «грубой силой»; слабый пароль |
| Воздействие на чувствительные данные | Слабая криптография; отсутствие шифрования |
| Внешний объект XML | Атака внешнего объекта XML |
| Взлом контроля доступа | Неправильная конфигурация CORS; принудительный просмотр; повышение привилегий |
| Неправильная настройка безопасности | Неисправленные недостатки; невозможность установить значения параметров безопасности в настройках; устаревшее или уязвимое программное обеспечение |
| Межсайтовый скриптинг (XSS) | Отражённые (Непостоянные); Хранимые (Постоянные); DOM-модели |
| Небезопасная десериализация | Изменение объектов и структур данных; подделка данных |
| Использование компонентов с известными уязвимостями | Устаревшее программное обеспечение; не обнаруженные уязвимости; неспособность исправить базовые фреймворки |
| Недостаточное логирование и мониторинг | Неспособность зарегистрировать проверяемые события; невозможность генерировать понятные сообщения журнала: неуместные предупреждения; неспособность обнаружить или предупредить об активных атаках в режиме реального времени |
Защита мобильных приложений
[править | править код]Ожидается, что в будущем доля мобильных устройств, предоставляющих функциональные возможности открытой платформы, будет продолжать расти. Открытость этих платформ дает значительные возможности для всех частей мобильной экосистемы, благодаря возможности гибкого предоставления программ и услуг - опций, которые могут быть установлены, удалены или обновленные множество раз согласно потребностям и требованиям пользователя. Однако с открытостью появляется и неограниченный доступ к мобильным ресурсам и API-интерфейсам приложениями неизвестного или ненадежного происхождения, что может привести к причинению вреда пользователю, устройству, сети или всего вместе взятого, если не используются соответствующие архитектуры безопасности и сетевые меры предосторожности. Безопасность приложения обеспечивается в той или иной форме на большинстве мобильных устройств с открытой ОС (Symbian OS,[3] Microsoft, BREW, и т.д.). В 2017 году Google расширил свою программу вознаграждений за найденные уязвимости, чтобы охватить уязвимости, обнаруженные в приложениях, разработанных третьими лицами и доступных через Google Play Store.[4] Промышленные группы также разработали рекомендации, включая Ассоциацию GSM и Open Mobile Terminal Platform (OMTP).[5]
Существует несколько стратегий повышения безопасности мобильных приложений:
- Составление «белого списка» приложений
- Обеспечение безопасности транспортного уровня
- Строгая аутентификация и авторизация
- Шифрование данных при записи в память
- Песочница приложений
- Предоставление доступа приложениям на уровне API
- Привязка процессов к идентификатору пользователя
- Предопределение взаимодействия между мобильным приложением и ОС
- Требование подтверждения пользователя для предоставления привилегированного / повышенного доступа приложению
- Правильная обработка сеанса
Тестирование безопасности приложений
[править | править код]Методы тестирования безопасности выявляют уязвимости или дыры в безопасности приложений. Эти уязвимости оставляют приложения открытыми для эксплойта. В идеале тестирование безопасности должно осуществляться на протяжении всего жизненного цикла разработки программного обеспечения, чтобы уязвимости можно было своевременно и тщательно устранять. К сожалению, тестирование часто проводится в конце цикла разработки. С ростом популярности DevOps и Continuous delivery (непрерывная доставка) как моделей разработки и развертывания программного обеспечения,[6] модели непрерывного обеспечения безопасности становятся все более популярными.[7]
Сканеры уязвимостей и, более конкретно, сканеры веб-приложений, также известные как инструменты тестирования на проникновение (например, инструменты этичного хакера), исторически использовались организациями и консультантами по безопасности для автоматизации тестирования безопасности запросов / ответов HTTP; тем не менее, это не заменяет необходимость фактической проверки исходного кода. Проверка исходного кода приложения может выполняться вручную или в автоматическом режиме. Учитывая общий размер отдельных программ (часто 500 000 строк кода или более), человек не может выполнить всесторонний анализ данных, необходимый для полной проверки всех возможных уязвимостей вручную. Для этого используются автоматизированные инструменты анализа исходного кода с последующей фильтрацией и анализом результатов.
Существует много разновидностей автоматизированных инструментов для выявления уязвимостей в приложениях. Некоторые из них требуют большого опыта проведения экспертизы безопасности, а другие предназначены для полностью автоматизированного использования. Результаты зависят от типов информации (исходные файлы, двоичные файлы, трафик HTTP, конфигурации, библиотеки, соединения), предоставленных анализатору, качества анализа и охваченных уязвимостей. Общие технологии, используемые для выявления уязвимостей приложений, включают в себя:
Статическое тестирование безопасности приложений (SAST) - это технология, которая часто используется в качестве инструмента анализа исходного кода. Метод анализирует исходный код на наличие уязвимостей перед запуском приложения. Этот метод дает меньше ложноположительных результатов, но для большинства реализаций требуются доступ к исходному коду приложения[8], экспертная конфигурация и большие вычислительные мощности.
Динамическое тестирование безопасности приложений (DAST) - это технология, которая способна находить видимые уязвимости путем подачи URL-адреса в автоматический сканер. Этот метод легко масштабируется, легко интегрируется и быстр. Недостатки DAST заключаются в необходимости экспертной конфигурации и высокой вероятности ложного срабатывания.[8]
Интерактивное тестирование безопасности приложений (IAST) - это решение, которое оценивает приложения изнутри, используя программные средства. Этот метод позволяет IAST использовать преимущества SAST и DAST, а также предоставляет доступ к коду, HTTP-трафику, информации о библиотеках, внутренних соединениях и информации о конфигурации.[9] Некоторые продукты IAST требуют, чтобы приложение подвергалось атаке, в то время как другие могут использоваться во время обычного тестирования качества.[10][11]
Обеспечение безопасности приложений
[править | править код]Развитие вредоносных программ, направленных на кибер-атаку клиентов компаний, ведущих свою коммерческую деятельность в сети Интернет, послужило стимулом к изменению требований к веб-приложениям, начиная с 2007 года. Предполагается, что значительное количество пользователей Интернета скомпрометированы вредоносным ПО и поэтому любые данные, отправленные с заражённых машин, могут быть вредоносными. В связи с этим, внедряется больше продвинутых систем защиты информации и блокировки атак именно на бекенде, чем на клиентской стороне, либо веб-сервере.[12] По состоянию на 2016 год, широкое применение находили технологии самозащиты ПО.[8][13] RASP внедряется совместно со средой выполнения, либо вживляется в неё, что позволяет обнаруживать и предотвращать хакерские атаки.[14][15]
Скоординированное обнаружение уязвимостей
[править | править код]Координационный центр CERT описывает скоординированное раскрытие уязвимостей - CVD (англ. Coordinated Vulnerability Disclosure) как «процесс уменьшения преимущества противника при уменьшении уязвимости информационной безопасности»..[16] CVD - это итеративный многоэтапный процесс, в котором участвуют несколько заинтересованных сторон (пользователи, поставщики программного обеспечения, специалисты по безопасности), которые должны работать вместе для устранения уязвимостей. Поскольку в процессах CVD участвуют несколько заинтересованных сторон, управление коммуникацией и устранение уязвимостей имеют решающее значение для успеха.
С эксплуатационной точки зрения многие инструменты и процессы могут помочь в CVD. К ним относятся системы отслеживания ошибок и программы Bug Bounty.
Стандарты и требования безопасности
[править | править код]- Стандарт написания кода CERT
- CWE[17]
- Техническое руководство по безопасности (STIG)
- ISO/IEC 27034-1:2011 Information technology — Security techniques — Application security -- Part 1: Overview and concepts
- ISO/IEC TR 24772:2013 Information technology — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use
- NIST Special Publication 800-53
- OWASP
- Стандарт безопасности данных индустрии платежных карт PCI DSS
См. также
[править | править код]- Безопасность баз данных
- Информационная безопасность
- Жизненный цикл безопасной разработки
- Веб-приложение
- Каркас веб-приложений
- CERT
Ссылки
[править | править код]- ↑ What is OWASP, and Why it Matters for AppSec. Contrast Security (23 февраля 2017). Дата обращения: 10 апреля 2018. Архивировано 11 апреля 2018 года.
- ↑ OWASP Top 10 - 2017. OWASP (2017). Дата обращения: 10 апреля 2018. Архивировано 26 июля 2018 года.
- ↑ "Platform Security Concepts" Архивная копия от 23 декабря 2017 на Wayback Machine, Simon Higginson.
- ↑ Google launched a new bug bounty program to root out vulnerabilities in third-party apps on Google Play. The Verge (22 октября 2017). Дата обращения: 15 июня 2018. Архивировано 15 августа 2018 года.
- ↑ Application Security Framework. Архивировано из оригинала 29 марта 2009 года., Open Mobile Terminal Platform
- ↑ DevOps Survey Results: Why Enterprises Are Embracing Continuous Delivery=01 December 2017. cloud bees. Дата обращения: 26 июня 2018. Архивировано 22 декабря 2018 года.
- ↑ Tapping Hackers for Continuous Security=31 March 2017. HackerOne. Дата обращения: 4 июля 2018. Архивировано 4 июля 2018 года.
- ↑ 1 2 3 Interactive Application Security Testing : Things to Know. TATA Cyber Security Community (9 июня 2016). Дата обращения: 20 декабря 2018. Архивировано из оригинала 20 июня 2018 года.
- ↑ Williams, Jeff I Understand SAST and DAST But What is an IAST and Why Does it Matter? Contrast Security (2 июля 2015). Дата обращения: 10 апреля 2018. Архивировано 11 апреля 2018 года.
- ↑ Abezgauz, Irene Introduction to Interactive Application Security Testing. Quotium (17 февраля 2014). Дата обращения: 20 декабря 2018. Архивировано 3 апреля 2018 года.
- ↑ Rohr, Matthias IAST: A New Approach For Agile Security Testing. Secodis (26 ноября 2015). Дата обращения: 20 декабря 2018. Архивировано 20 июня 2018 года.
- ↑ Continuing Business with Malware Infected Customers. Gunter Ollmann (октябрь 2008). Дата обращения: 20 декабря 2018. Архивировано 4 апреля 2016 года.
- ↑ What is IAST? Interactive Application Security Testing. Veracode. Дата обращения: 20 декабря 2018. Архивировано 26 января 2018 года.
- ↑ IT Glossary: Runtime Application Self-Protection. Gartner. Дата обращения: 20 декабря 2018. Архивировано 6 марта 2018 года.
- ↑ Feiman, Joseph Security Think Tank: RASP - A Must-Have Security Technology. Computer Weekly (июнь 2012). Дата обращения: 20 декабря 2018. Архивировано 26 января 2018 года.
- ↑ The CERT Guide to Coordinated Vulnerability Disclosure. Software Engineering Institute, Carnegie Mellon University (август 2017). Дата обращения: 20 июня 2018. Архивировано 13 февраля 2019 года.
- ↑ Common Weakness Enumeration (CWE). Дата обращения: 19 декабря 2018. Архивировано 10 мая 2016 года.