Безопасность приложения

редактировать

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

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

Содержание
  • 1 Термины
  • 2 Методы
  • 3 Угрозы и атаки приложений
  • 4 Безопасность мобильных приложений
  • 5 Тестирование безопасности приложений
  • 6 Защита приложений
  • 7 Скоординированное выявление уязвимостей
  • 8 Стандарты и нормы безопасности
  • 9 См. Также
  • 10 Ссылки
Термины
  • Актив. Ценный ресурс, такой как данные в базе данных, деньги на счете, файл в файловой системе или любой системный ресурс.
  • Уязвимость. Слабость или пробел в программе безопасности, которые могут быть использованы угрозами для получения несанкционированного доступа к активу.
  • Атака (или использование). Действие, предпринятое для нанесения вреда активу.
  • Угроза. Все, что может использовать уязвимость и получить, повредить или уничтожить актив.
Методы

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

  • Проверка безопасности Whitebox или проверка кода. Это инженер по безопасности, глубоко разбирающийся в приложении, вручную просматривая исходный код и замечая недостатки безопасности. Путем понимания приложения можно найти уникальные уязвимости.
  • Аудит безопасности «черного ящика». Это возможно только при использовании приложения, тестирующего его на наличие уязвимостей, исходный код не требуется.
  • Обзор проекта. Перед написанием кода прорабатывается модель угроз приложения. Иногда вместе со спецификацией или конструкторским документом.
  • Инструменты. Существует множество автоматизированных инструментов, которые проверяют уязвимости безопасности, часто с более высоким уровнем ложных срабатываний, чем участие человека.
  • Скоординированные платформы уязвимостей. Это хакерские решения безопасности приложений, предлагаемые многими веб-сайтами и разработчиками программного обеспечения, с помощью которых люди могут получить признание и компенсацию за сообщения об ошибках.

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

Угрозы и атаки приложений

Согласно книге «Шаблоны и методы улучшения безопасности веб-приложений», следующие классы являются классами общих угроз и атак безопасности приложений:

КатегорияУгрозы и атаки
Проверка вводаПереполнение буфера ; межсайтовый скриптинг ; SQL-инъекция ; канонизация
Взлом программного обеспечения Злоумышленник изменяет поведение существующего приложения во время выполнения для выполнения неавторизованных действий; эксплуатируется посредством двоичного исправления, подстановки кода или расширения кода
Аутентификация Перехват сети; Атака грубой силой ; словарные атаки ; воспроизведение файлов cookie; кража учетных данных
Авторизация Повышение привилегий; разглашение конфиденциальных данных; подделка данных; заманивание атак
Управление конфигурацией Несанкционированный доступ к интерфейсам администрирования; несанкционированный доступ к хранилищам конфигурации; получение данных конфигурации в открытом виде; отсутствие индивидуальной ответственности; сверхпривилегированные учетные записи процессов и служб
Конфиденциальная информация Доступ к конфиденциальному коду или данным в хранилище; прослушивание сети; вмешательство кода / данных
Управление сеансом Взлом сеанса ; воспроизведение сеанса ; человек посередине
Криптография Плохая генерация ключей или управление ключами; слабое или нестандартное шифрование
Изменение параметровУправление строкой запроса; манипулирование полями формы; манипуляции с файлами cookie; Обработка HTTP-заголовка
Управление исключениямиРаскрытие информации; отказ в обслуживании
Аудит и ведение журналаПользователь запрещает выполнение операции; злоумышленник бесследно использует приложение; злоумышленник скрывает свои следы

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

КатегорияУгрозы / атаки
ВнедрениеSQL-инъекция; NoSQL ; Команда ОС; Объектно-реляционное сопоставление ; Внедрение LDAP
Нарушение аутентификацииЗаполнение учетных данных ; атаки методом грубой силы; слабые пароли
Раскрытие конфиденциальных данныхСлабая криптография; не принудительное шифрование
внешние объекты XMLатака на внешние объекты XML
нарушение контроля доступанеправильная конфигурация CORS; принудительный просмотр; повышение привилегий
Неверная конфигурация безопасностиНеисправленные недостатки; невозможность установить значения безопасности в настройках; устаревшее или уязвимое программное обеспечение
Межсайтовый скриптинг (XSS)Отраженный XSS; Сохраненный XSS; DOM XSS
Небезопасная десериализацияОбъект и структура данных изменены; фальсификация данных
Использование компонентов с известными уязвимостямиУстаревшее программное обеспечение; отказ от поиска уязвимостей; неспособность исправить базовые платформы платформы; сбой обновленной или обновленной совместимости библиотеки
Недостаточное ведение журнала и мониторингСбой регистрации событий, подлежащих аудиту; невозможность создания сообщений ясного журнала: несоответствующие предупреждения; невозможность обнаружения или предупреждения об активных атаках в реальном времени или почти в реальном времени
Безопасность мобильных приложений

Ожидается, что доля мобильных устройств, обеспечивающих функциональность открытой платформы, будет продолжать расти в будущем. Открытость этих платформ предлагает значительные возможности для всех частей мобильной экосистемы, предоставляя возможность гибкого предоставления программ и услуг = опции, которые могут быть установлены, удалены или обновлены несколько раз в соответствии с потребностями и требованиями пользователя. Однако открытость влечет за собой ответственность, и неограниченный доступ к мобильным ресурсам и API-интерфейсам со стороны приложений неизвестного или ненадежного происхождения может привести к повреждению пользователя, устройства, сети или всего перечисленного, если не будет управляться подходящими архитектурами безопасности и сетевыми мерами предосторожности. Безопасность приложений в той или иной форме обеспечивается на большинстве мобильных устройств с открытой ОС (Symbian OS, Microsoft, BREW и т. Д.). В 2017 году Google расширил свою Программу вознаграждения за уязвимости, чтобы покрыть уязвимости, обнаруженные в приложениях, разработанных третьими сторонами и доступных через Google Play Store. Отраслевые группы также разработали рекомендации, включая GSM Association и Open Mobile Terminal Platform (OMTP).

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

  • Белый список приложений
  • Обеспечение безопасности транспортного уровня
  • Строгая аутентификация и авторизация
  • Шифрование данных при записи в память
  • Изолирование приложений
  • Предоставление доступа к приложению на уровне API
  • Процессы, привязанные к идентификатору пользователя
  • Предопределенные взаимодействия между мобильным приложением и ОС
  • Требование ввода данных пользователем для привилегированных / повышенный доступ
  • Правильная обработка сеанса
Тестирование безопасности для приложений

Методы тестирования безопасности ищут уязвимости или дыры в безопасности в приложениях. Эти уязвимости делают приложения открытыми для эксплуатации. В идеале тестирование безопасности должно проводиться на протяжении всего жизненного цикла разработки программного обеспечения (SDLC), чтобы можно было своевременно и тщательно устранять уязвимости. К сожалению, тестирование часто проводится в конце цикла разработки. С ростом популярности моделей разработки и развертывания программного обеспечения Непрерывная доставка и DevOps модели непрерывной безопасности становятся все более популярными.

Сканеры уязвимостей и, в частности, веб-приложения сканеры, иначе известные как инструменты тестирования на проникновение (т. е. этические хакерские инструменты), исторически использовались организациями безопасности внутри корпораций и консультантами по безопасности для автоматизации тестирования безопасности HTTP-запросов / ответов; однако это не заменяет необходимость фактического обзора исходного кода. Проверка физического кода исходного кода приложения может выполняться вручную или автоматически. Учитывая общий размер отдельных программ (часто 500 000 строк кода и более), человеческий мозг не может выполнить всесторонний анализ потока данных, необходимый для полной проверки всех обходных путей прикладной программы для поиска уязвимых мест. Человеческий мозг больше подходит для фильтрации, прерывания и составления отчетов о выходных данных автоматических инструментов анализа исходного кода, доступных на рынке, в отличие от попыток проследить все возможные пути через скомпилированную базу кода, чтобы найти уязвимости на уровне первопричины.

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

Статическое тестирование безопасности приложений (SAST) - это технология, которая часто используется в качестве инструмента анализа исходного кода. Метод анализирует исходный код на наличие уязвимостей до запуска приложения и используется для усиления кода. Этот метод дает меньше ложных срабатываний, но для большинства реализаций требуется доступ к исходному коду приложения, экспертная конфигурация и большая вычислительная мощность.

Динамическое тестирование безопасности приложений (DAST) - это технология, которая может находить видимые уязвимости введя URL-адрес в автоматический сканер. Этот метод хорошо масштабируется, легко интегрируется и работает быстро. Недостатки DAST заключаются в необходимости экспертной настройки и высокой вероятности ложных срабатываний и отрицательных результатов.

Интерактивное тестирование безопасности приложений (IAST) - это решение, которое оценивает приложения изнутри. Этот метод позволяет IAST сочетать сильные стороны методов SAST и DAST, а также обеспечивает доступ к коду, HTTP-трафику, библиотечной информации, внутренним соединениям и информации о конфигурации. Некоторые продукты IAST требуют атаки на приложение, тогда как другие можно использовать во время обычного тестирования качества.

Защита приложений

Достижения в области профессионального вредоносного ПО нацелены на Интернет-клиенты онлайн-организаций заметили изменения в требованиях к дизайну веб-приложений с 2007 года. Обычно предполагается, что значительный процент пользователей Интернета будет скомпрометирован с помощью вредоносного ПО и что любые данные, поступающие с их зараженного хоста, могут быть испорченным. Таким образом, безопасность приложений начала проявлять более совершенные системы защиты от мошенничества и эвристического обнаружения в бэк-офисе, а не в коде на стороне клиента или веб-сервера. По состоянию на 2016 год были разработаны технологии самозащиты исполняемых приложений (RASP). RASP - это технология, развертываемая в среде выполнения приложения или вместе с ней, которая инструментирует приложение и позволяет обнаруживать и предотвращать атаки.

Скоординированное раскрытие уязвимостей

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

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

Стандарты и нормы безопасности
См. Также
Ссылки
Последняя правка сделана 2021-06-11 22:28:38
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте