 | Эта статья может нуждаться в реорганизации, чтобы соответствовать рекомендациям Википедии по разметке . ( Август 2016 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
| Часть серии по |
| Информационная безопасность |
|---|
| Связанные категории безопасности |
| Угрозы |
|
| Защиты |
|
Безопасность приложения включает в себя меры, принимаемые для повышения безопасности приложения, часто путем поиска, исправления и предотвращения уязвимостей безопасности . Для выявления таких уязвимостей безопасности на разных этапах жизненного цикла приложений, таких как проектирование , разработка , развертывание , обновление , обслуживание , используются разные методы .
Постоянно развивающийся, но в значительной степени согласованный набор общих недостатков безопасности наблюдается в разных приложениях, обратите внимание на общие недостатки .
Условия [ править ]
- Актив . Ценный ресурс, такой как данные в базе данных, деньги на счете, файл в файловой системе или любой системный ресурс.
- Уязвимость . Слабость или пробел в программе безопасности, которые могут быть использованы угрозами для получения несанкционированного доступа к активу.
- Атаковать (или эксплуатировать). Действие, предпринятое для нанесения вреда активу.
- Угроза . Все, что может использовать уязвимость и получить, повредить или уничтожить актив.
Методы [ править ]
Различные методы обнаруживают различные подмножества уязвимостей безопасности, скрывающихся в приложении, и наиболее эффективны в разное время жизненного цикла программного обеспечения. Каждый из них представляет собой разный компромисс времени, усилий, затрат и обнаруженных уязвимостей.
- Проверка безопасности Whitebox или проверка кода. Это инженер по безопасности, глубоко разбирающийся в приложении, вручную просматривая исходный код и замечая недостатки безопасности. Путем понимания приложения могут быть обнаружены уникальные уязвимости приложения.
- Аудит безопасности Blackbox. Это возможно только при использовании приложения, тестирующего его на наличие уязвимостей, исходный код не требуется.
- Обзор дизайна. Перед написанием кода прорабатывается модель угроз приложения. Иногда вместе со спецификацией или дизайнерским документом.
- Инструменты. Существует множество автоматизированных инструментов, которые проверяют недостатки безопасности, часто с более высоким уровнем ложных срабатываний, чем при участии человека.
- Скоординированные платформы уязвимостей . Это разработанные хакерами решения безопасности приложений, предлагаемые многими веб-сайтами и разработчиками программного обеспечения, благодаря которым люди могут получить признание и компенсацию за сообщения об ошибках.
Правильное использование этих методов на протяжении жизненного цикла разработки программного обеспечения (SDLC) для максимальной безопасности - это роль группы безопасности приложений.
Угрозы и атаки приложений [ править ]
В соответствии с книгой по шаблонам и методам улучшения безопасности веб-приложений , ниже приведены классы распространенных угроз и атак безопасности приложений:
| Категория | Угрозы и атаки |
|---|---|
| Проверка ввода | Переполнение буфера ; межсайтовый скриптинг ; SQL-инъекция ; канонизация |
| Взлом программного обеспечения | Злоумышленник изменяет поведение существующего приложения во время выполнения для выполнения несанкционированных действий; эксплуатируется с помощью двоичного исправления, подстановки кода или расширения кода |
| Аутентификация | Подслушивание сети; Атака грубой силой ; словарные атаки ; воспроизведение файлов cookie; кража учетных данных |
| Авторизация | Повышение привилегий; разглашение конфиденциальных данных; подделка данных; заманивающие атаки |
| Управление конфигурацией | Несанкционированный доступ к интерфейсам администрирования; несанкционированный доступ к хранилищам конфигурации; получение данных конфигурации в открытом виде; отсутствие индивидуальной ответственности; сверхпривилегированные учетные записи процессов и служб |
| Конфиденциальная информация | Доступ к конфиденциальному коду или данным в хранилище; прослушивание сети; подделка кода / данных |
| Управление сессией | Захват сеанса ; воспроизведение сеанса ; человек посередине |
| Криптография | Плохая генерация ключей или управление ключами; слабое или нестандартное шифрование |
| Манипулирование параметрами | Манипуляция строкой запроса; манипулирование полями формы; манипуляции с файлами cookie; Манипуляции с HTTP-заголовками |
| Управление исключениями | Раскрытие информации; отказ в обслуживании |
| Аудит и логирование | Пользователь отрицает выполнение операции; злоумышленник бесследно использует приложение; злоумышленник заметает следы |
OWASP сообщество публикует список из 10 лучших уязвимостей для веб - приложений и лучшие способы достижения безопасности для организаций и стремясь создать открытые стандарты для отрасли. [1] [ рекламный источник? ] По состоянию на 2017 год организация перечисляет основные угрозы безопасности приложений следующим образом: [2]
| Категория | Угрозы / атаки |
|---|---|
| Инъекция | SQL-инъекция; NoSQL ; Команда ОС; Объектно-реляционное отображение ; LDAP-инъекция |
| Сломанная аутентификация | Учетная начинка ; атаки методом перебора; слабые пароли |
| Раскрытие конфиденциальных данных | Слабая криптография; непринужденное шифрование |
| Внешние сущности XML | Атака на внешний объект XML |
| Сломанный контроль доступа | Неправильная конфигурация CORS; принудительный просмотр; повышение привилегий |
| Неправильная конфигурация безопасности | Неисправленные недостатки; невозможность установить значения безопасности в настройках; устаревшее или уязвимое программное обеспечение |
| Межсайтовый скриптинг (XSS) | Отраженный XSS; Сохраненный XSS; DOM XSS |
| Небезопасная десериализация | Изменена структура объекта и данных; подделка данных |
| Использование компонентов с известными уязвимостями | Устаревшее программное обеспечение; отказ от поиска уязвимостей; неспособность исправить базовые платформы платформы; отказ обновленной или обновленной совместимости библиотеки |
| Недостаточное ведение журнала и мониторинг | Неспособность регистрировать события, подлежащие аудиту; невозможность создания сообщений ясного журнала: несоответствующие предупреждения; неспособность обнаружить или предупредить об активных атаках в реальном времени или почти в реальном времени |
Безопасность мобильных приложений [ править ]
Ожидается, что доля мобильных устройств, обеспечивающих функциональность открытой платформы, в будущем будет увеличиваться. Открытость этих платформ предлагает значительные возможности для всех частей мобильной экосистемы, предоставляя возможность гибкого предоставления программ и услуг = опции, которые могут быть установлены, удалены или обновлены несколько раз в соответствии с потребностями и требованиями пользователя. Однако открытость влечет за собой ответственность, и неограниченный доступ к мобильным ресурсам и API-интерфейсам со стороны приложений неизвестного или ненадежного происхождения может привести к повреждению пользователя, устройства, сети или всего перечисленного, если не будет управляться подходящими архитектурами безопасности и сетевыми мерами предосторожности. Безопасность приложений в той или иной форме обеспечивается на большинстве мобильных устройств с открытой ОС ( Symbian OS , [3] Microsoft , [ необходима ссылка ] BREW и т. Д.). В 2017 году Google расширил свою программу вознаграждения за уязвимости, чтобы покрыть уязвимости, обнаруженные в приложениях, разработанных третьими сторонами и доступных через Google Play Store. [4] Отраслевые группы также создали рекомендации, включая Ассоциацию GSM и Открытую платформу мобильных терминалов (OMTP). [5]
Существует несколько стратегий повышения безопасности мобильных приложений, в том числе:
- Белый список приложений
- Обеспечение безопасности транспортного уровня
- Надежная аутентификация и авторизация
- Шифрование данных при записи в память
- Песочница приложений
- Предоставление доступа к приложению на уровне API
- Процессы, привязанные к идентификатору пользователя
- Предопределенные взаимодействия между мобильным приложением и ОС
- Требование ввода данных пользователем для привилегированного / повышенного доступа
- Правильная обработка сеанса
Тестирование безопасности приложений [ править ]
Методы тестирования безопасности ищут уязвимости или дыры в безопасности в приложениях. Эти уязвимости делают приложения открытыми для эксплуатации . В идеале тестирование безопасности проводится на протяжении всего жизненного цикла разработки программного обеспечения (SDLC), так что уязвимости могут быть устранены своевременно и тщательно. К сожалению, тестирование часто проводится на опоздании в конце цикла разработки. С ростом непрерывной доставки и DevOps как популярных моделей разработки и развертывания программного обеспечения [6] [ рекламный источник? ] модели непрерывной безопасности становятся все более популярными. [7] [ рекламный источник?] [8] [ рекламный источник? ]
Сканеры уязвимостей , а точнее сканеры веб-приложений, также известные как инструменты тестирования на проникновение (т. Е. Этический взломtools) исторически использовались организациями безопасности внутри корпораций и консультантами по безопасности для автоматизации тестирования безопасности HTTP-запросов / ответов; однако это не заменяет необходимость фактического обзора исходного кода. Проверка физического кода исходного кода приложения может выполняться вручную или автоматически. Учитывая общий размер отдельных программ (часто 500 000 строк кода или более), человеческий мозг не может выполнить всесторонний анализ потока данных, необходимый для полной проверки всех обходных путей прикладной программы для поиска точек уязвимости. Человеческий мозг больше подходит для фильтрации,прерывание и составление отчетов о результатах работы инструментов автоматического анализа исходного кода, доступных на рынке, по сравнению с попыткой проследить все возможные пути через скомпилированную базу кода, чтобы найти уязвимости на уровне первопричины.
Существует много видов автоматизированных инструментов для выявления уязвимостей в приложениях. Для использования некоторых требуется большой опыт в области безопасности, а другие предназначены для полностью автоматизированного использования. Результаты зависят от типов информации (источник, двоичный код, HTTP-трафик, конфигурация, библиотеки, соединения), предоставляемой инструменту, качества анализа и объема обнаруженных уязвимостей. Общие технологии, используемые для выявления уязвимостей приложений, включают:
Статическое тестирование безопасности приложений (SAST) - это технология, которая часто используется в качестве инструмента анализа исходного кода. Метод анализирует исходный код на наличие уязвимостей перед запуском приложения и используется для усиления кода. Этот метод дает меньше ложных срабатываний, но для большинства реализаций требуется доступ к исходному коду приложения [9], а также экспертная конфигурация и большая вычислительная мощность. [10] [ рекламный источник? ]
Динамическое тестирование безопасности приложений (DAST) - это технология, которая может находить видимые уязвимости, вводя URL-адрес в автоматический сканер. Этот метод хорошо масштабируется, легко интегрируется и работает быстро. Недостатки DAST заключаются в необходимости экспертной настройки и высокой вероятности ложных срабатываний и отрицательных результатов. [9]
Интерактивное тестирование безопасности приложений (IAST) - это решение, которое оценивает приложения изнутри с помощью программных инструментов . Этот метод позволяет IAST сочетать сильные стороны методов SAST и DAST, а также обеспечивает доступ к коду, HTTP-трафику, библиотечной информации, внутренним соединениям и информации о конфигурации. [11] [12] Некоторые продукты IAST требуют атаки на приложение, в то время как другие могут использоваться во время обычного тестирования качества. [13] [ рекламный источник? ] [14] [ рекламный источник? ]
Защита приложений [ править ]
Достижения в области профессионального вредоносного ПО, нацеленного на интернет-клиентов онлайн-организаций, претерпели изменения в требованиях к дизайну веб-приложений с 2007 года. Обычно предполагается, что значительный процент интернет-пользователей будет скомпрометирован с помощью вредоносных программ и что любые данные, поступающие с их зараженного хоста может быть испорчен. Таким образом, безопасность приложений начала проявлять более совершенные системы защиты от мошенничества и эвристического обнаружения в бэк-офисе, а не в коде на стороне клиента или веб-сервера. [15] [ рекламный источник? ] По состоянию на 2016 год были разработаны технологии самозащиты исполняемых приложений (RASP). [9] [16]RASP - это технология, развернутая в среде выполнения приложения или вместе с ней, которая инструментарий приложения и позволяет обнаруживать и предотвращать атаки. [17] [18]
Скоординированное раскрытие уязвимостей [ править ]
Координационный центр CERT описывает скоординированное раскрытие уязвимостей (CVD) как «процесс уменьшения преимущества противника при уменьшении уязвимости информационной безопасности». [19] CVD - это итеративный, многоэтапный процесс, в котором участвуют несколько заинтересованных сторон (пользователи, поставщики, исследователи безопасности), у которых могут быть разные приоритеты и которые должны работать вместе для устранения уязвимости. Поскольку в процессах сердечно-сосудистых заболеваний участвует множество заинтересованных сторон, управление информацией об уязвимости и ее устранении критически важно для успеха.
С операционной точки зрения, многие инструменты и процессы могут помочь при сердечно-сосудистых заболеваниях. К ним относятся электронная почта и веб-формы, системы отслеживания ошибок и скоординированные платформы уязвимостей . [20]
Стандарты и правила безопасности [ править ]
- CERT безопасное кодирование
- CWE
- ДИСА-СТИГ
- Закон Грэмма-Лича-Блайли
- Закон о переносимости и подотчетности медицинского страхования (HIPAA)
- ISO / IEC 27034-1: 2011 Информационные технологии. Методы обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и концепции.
- ISO / IEC TR 24772: 2013 Информационные технологии. Языки программирования. Руководство по предотвращению уязвимостей в языках программирования посредством выбора и использования языков.
- Специальная публикация NIST 800-53
- OWASP
- Стандарт безопасности данных PCI ( PCI DSS )
- Закон Сарбейнса-Оксли (SOX)
- ETSI TS 103 645 [21]
См. Также [ править ]
- Поверхность атаки портфеля приложений
- Контрмера
- Безопасность данных
- Безопасность базы данных
- ГЕРАС-АФ
- Информационная безопасность
- Жизненный цикл разработки надежных компьютерных систем безопасности
- веб приложение
- Фреймворк веб-приложений
Ссылки [ править ]
- ^ «Что такое OWASP и почему он важен для AppSec» . Контрастная безопасность. 23 февраля 2017 . Проверено 10 апреля 2018 года .
- ^ "OWASP Top 10 - 2017" (PDF) . OWASP. 2017 . Проверено 10 апреля 2018 года .
- ^ "Концепции безопасности платформы" , Саймон Хиггинсон.
- ^ "Google запустил новую программу вознаграждения за ошибки, чтобы искоренить уязвимости в сторонних приложениях в Google Play" . Грань. 22 октября 2017 . Проверено 15 июня 2018 .
- ^ «Структура безопасности приложений» . Архивировано из оригинального 29 марта 2009 года., Открытая платформа мобильных терминалов
- ^ «Результаты опроса DevOps: почему предприятия переходят на непрерывную поставку = 1 декабря 2017 г.» . облачные пчелы . Проверено 26 июня 2018 .
- ^ «Непрерывная безопасность в мире DevOps = 5 июля 2016 г.» . Конференция RMLL 2016 . Проверено 4 июля 2018 года .
- ^ «Использование хакеров для непрерывной безопасности = 31 марта 2017 г.» . HackerOne . Проверено 4 июля 2018 года .
- ^ a b c «Интерактивное тестирование безопасности приложений: что нужно знать» . Сообщество кибербезопасности TATA. 9 июня 2016 года в архив с оригинала на 20 июня 2018 года . Проверено 25 января 2018 года .
- ^ Уильямс, Джефф (22 сентября 2015 г.). «Почему безумие доверять статическому анализу» . ТЕМНОЕЧтение . Проверено 10 апреля 2018 года .
- ^ Уильямс, Джефф (2 июля 2015 г.). «Я понимаю SAST и DAST, но что такое IAST и почему это важно?» . Контрастная безопасность . Проверено 10 апреля 2018 года .
- ↑ Веласко, Роберто (7 мая 2020 г.). «Что такое IAST? Все об интерактивном тестировании безопасности приложений» . Hdiv Security . Дата обращения 7 мая 2020 .
- ^ Абезгауз, Irene (17 февраля 2014). «Введение в интерактивное тестирование безопасности приложений» . Quotium.
- Рианна Рор, Матиас (26 ноября 2015 г.). «IAST: новый подход к гибкому тестированию безопасности» . Secodis.
- ^ «Продолжение бизнеса с клиентами, зараженными вредоносным ПО» . Гюнтер Оллманн. Октябрь 2008 г.
- ^ «Что такое IAST? Интерактивное тестирование безопасности приложений» . Veracode.
- ^ «ИТ-глоссарий: самозащита приложений во время выполнения» . Gartner.
- ^ Фейман, Джозеф (июнь 2012 г.). «Аналитический центр безопасности: RASP - обязательная технология безопасности» . Computer Weekly.
- ^ «Руководство CERT по скоординированному раскрытию уязвимостей» . Институт программной инженерии, Университет Карнеги-Меллона. Август 2017 . Проверено 20 июня 2018 .
- ^ «Руководство CERT по скоординированному раскрытию уязвимостей» . Институт программной инженерии, Университет Карнеги-Меллона. Август 2017 . Проверено 20 июня 2018 .
- ^ "ETSI TS 103 645" (PDF) .
