Когда дело доходит до безопасности корпоративного стека, самым слабым звеном являются программные приложения. В Состояние безопасности приложений, 2020, Forrester утверждает, что большинство внешних атак происходит либо с использованием уязвимости программного обеспечения (42%), либо через веб-приложение (35%).
Разработчики вынуждены выпускать функции как можно скорее, поскольку приложения становятся более сложными, а сроки разработки сокращаются. Для достижения дифференцированной и убедительной функциональности приложений разработчики все чаще полагаются на сторонние библиотеки.
Этот переход к компонентам с открытым исходным кодом делает безопасность практика более сложная для компаний. Новые платформы, такие как контейнеры и API, еще больше усложняют безопасность приложений.
Поскольку разработчиков постоянно вынуждают выпускать новые функции, организации сталкиваются с реальным риском нарушения безопасности. Безопасность может быть достигнута путем включения передовых методов обеспечения безопасности приложений в жизненный цикл разработки программного обеспечения и их реализации.
Почему важно тестирование веб-безопасности?
Тестирование веб-приложений и их конфигураций на наличие уязвимостей является целью тестирования веб-безопасности. Атаки на уровне приложений (т. Е. Нацеленные на приложения на основе HTTP) являются основными целями.
Обычно в веб-приложение отправляются различные типы входных данных, чтобы спровоцировать ошибки и заставить его вести себя неожиданно. В этих так называемых «отрицательных тестах» система проверяется на предмет непреднамеренного поведения.
Важно также отметить, что Тестирование веб-безопасности это не просто тестирование функций безопасности, реализованных в приложении (например, аутентификация и авторизация).
Также необходимо проверить, что другие функции (например, бизнес-логика и проверка ввода и вывода) реализованы безопасным способом. Целью является безопасный доступ к функциям веб-приложения.
Какие существуют типы тестов безопасности?
- Тест динамической безопасности приложений (ДАСТ). Этот автоматический тест безопасности приложений идеально подходит для внутренних приложений с низким уровнем риска для соответствия нормативным требованиям. Комбинация ручного тестирования веб-безопасности и DAST - лучший подход для приложений со средней степенью риска и критических приложений, которые претерпевают незначительные изменения.
- Статический тест безопасности приложений (САСТ). Такой подход к проверке безопасности приложений как вручную, так и автоматически. Таким образом можно протестировать приложение без необходимости запускать его в производственной среде. Кроме того, он позволяет разработчикам систематически обнаруживать и устранять уязвимости безопасности программного обеспечения путем сканирования исходного кода.
- Тест на проникновение. Этот ручной тест безопасности приложений идеально подходит для приложений, претерпевающих серьезные изменения. Оценка включает бизнес-логику и тестирование на злоумышленника для выявления сложных сценариев атак.
- Самозащита приложения во время выполнения (RASP). В этом развивающемся подходе к безопасности приложений используется ряд технологических приемов, позволяющих настроить приложение таким образом, чтобы можно было отслеживать атаки по мере их выполнения и, в идеале, блокировать в режиме реального времени.
Как тестирование безопасности приложений снижает риски вашей организации?
Большинство атак на веб-приложения
- Техника SQL-инъекций
- Межсайтовый скриптинг (XSS)
- Выполнение команд удаленно
- Обход пути
Результаты атаки
- Контент, доступ к которому ограничен
- Учетные записи, которые были скомпрометированы
- Установка вредоносного ПО
- Потерянный доход
- Клиенты теряют доверие
- Репутационный ущерб
- А также многое другое
Современная веб-среда подвержена широкому кругу проблем. Помимо информации о том, как можно использовать приложение, знание потенциальных результатов атаки поможет вашей компании превентивно устранить уязвимости и точно протестировать их.
Смягчающие меры могут применяться на ранних этапах SDLC после определения основной причины уязвимостей. Кроме того, тест безопасности веб-приложения может использовать знания о том, как работают эти атаки, для нацеливания на известные точки интереса.
Чтобы управлять рисками вашей компании, вы должны понимать последствия атаки, поскольку их можно использовать для оценки общей серьезности уязвимости.
В результате проверки безопасности определение серьезности обнаруженных проблем может помочь вам эффективно и результативно расставить приоритеты в усилиях по исправлению. Сведите к минимуму риск вашей фирмы, начав с вопросов критической важности и перейдя к вопросам с меньшим воздействием.
Оценка потенциального воздействия каждого приложения в библиотеке приложений вашей компании до выявления проблемы может помочь при определении приоритетов тестирования безопасности приложений.
Когда для тестирования веб-безопасности есть установленный список высококлассных приложений, мы можем запланировать тестирование так, чтобы в первую очередь были нацелены на критически важные приложения вашей компании, чтобы снизить риск для вашего бизнеса.
Какие функции следует проверять во время тестирования безопасности веб-приложений?
Во время тестирования безопасности веб-приложений следует изучить несколько функций, но этот список не является исчерпывающим. Ваша организация может подвергнуться серьезному риску из-за неправильной реализации каждого из них.
- Конфигурация приложения и сервера- Дефекты могут быть связаны с конфигурацией шифрования, конфигурациями веб-сервера и т. Д.
- Проверка ввода и обработка ошибок- Наиболее распространенные уязвимости, связанные с инъекциями, включая SQL-инъекции и межсайтовые сценарии (XSS), являются результатом плохой обработки ввода и вывода.
- Аутентификация и управление сеансом- Уязвимости могут привести к выдаче себя за пользователей. Также важна строгая политика учетных данных.
- Авторизация- Проверка способности приложения предотвращать вертикальное и горизонтальное повышение привилегий.
- Бизнес-логика- Этот тип логики важен для большинства бизнес-приложений.
- Клиентская логика Этот тип функции становится все более распространенным на современных веб-сайтах с большим количеством JavaScript, а также на веб-сайтах, использующих другие клиентские технологии (например, Silverlight, Flash, Java-апплеты).
10 лучших практик безопасности веб-приложений
Ниже приведены десять лучших практик безопасности приложений, которые ваша организация уже должна внедрить.
# 1 Отслеживайте свои активы
Если вы не знаете, что у вас есть, вы не сможете это защитить.
Для каких функций или приложений вы используете определенные серверы? В каких веб-приложениях вы используете компоненты с открытым исходным кодом?
Вы думаете, что отслеживать свои активы не важно? Очень важно помнить, какое программное обеспечение работает в каждом приложении - просто спросите Equifax, который был оштрафован на 700 миллионов долларов за неспособность защитить данные более 145 миллионов клиентов.
Один из клиентских веб-порталов кредитного рейтингового агентства был взломан после того, как не был исправлен компонент с открытым исходным кодом Apache Struts. Компания заявляет, что не знала, что клиентский портал использовал уязвимый компонент с открытым исходным кодом.
Чем раньше вы начнете отслеживать свои активы, тем меньше у вас будет головной боли и бедствий. По мере того, как организации масштабируют свое развитие, этот процесс может казаться сизифовой задачей.
Вам также следует классифицировать свои активы, отмечая те, которые имеют решающее значение для функций вашего бизнеса, и те, которые имеют меньшее значение. Затем вы можете оценить угрозы и устранить их позже.
# 2 Выполните оценку угроз
Если вы составите список того, что вам нужно защитить, вы сможете определить угрозы, с которыми вы сталкиваетесь, и способы их устранения.
Как хакеры смогут взломать ваше приложение? Какие существующие меры безопасности у вас есть? Какие дополнительные инструменты требуются?
Вы должны ответить на эти и другие вопросы в рамках оценки угроз.
Тем не менее, вы также должны реалистично оценивать уровень безопасности, которым вы можете наслаждаться. Независимо от того, насколько защищена ваша система, вы все равно можете ее взломать. Кроме того, вы должны быть честны в отношении мер, которые ваша команда может поддерживать с течением времени.
Вы можете рискнуть, что ваши стандарты и методы безопасности будут проигнорированы, если будете слишком настаивать. Относитесь к безопасности серьезно и не торопитесь.
Используйте следующую формулу, чтобы оценить свой риск:
Риск = вероятность атаки x влияние атаки.
Риск также можно рассматривать как вероятность того, что что-то произойдет, в зависимости от серьезности последствий.
Хотя было бы катастрофой, если бы кит все же упал с неба и раздавил вас, маловероятно, что это произойдет.
С другой стороны, укус комара в походе весьма вероятен, но вряд ли причинит значительный вред, кроме нескольких зудящих шишек.
# 3 Будьте в курсе ваших исправлений
Устанавливаете последние исправления в свои операционные системы? Вы используете стороннее программное обеспечение? Скорее всего, вы отстаете, то есть разоблачены.
Один из наиболее важных шагов, которые вы должны предпринять для обеспечения безопасности своего программного обеспечения, - это обновить программное обеспечение либо от коммерческого поставщика, либо от сообщества с открытым исходным кодом.
Когда уязвимость обнаруживается и ответственно сообщается владельцам продукта или проекта, она публикуется на сайтах с рекомендациями по безопасности и в базах данных, таких как База данных уязвимостей WhiteSource.
Если возможно, перед публикацией следует создать и выпустить исправление, чтобы предоставить пользователям возможность защитить свое программное обеспечение.
Однако, если вы не примените исправление, когда оно станет доступным, вы не получите преимущества от повышения безопасности.
Если вы беспокоитесь, что обновление до последней версии может сломать ваш продукт, автоматизированные инструменты может очень помочь. В любой день недели вы должны уделять первоочередное внимание обновлению и установке исправлений в рамках лучших практик безопасности вашего приложения.
# 4 Управляйте своими контейнерами
В последние годы популярность контейнеров возросла по мере того, как все больше организаций внедряют эту технологию из-за ее гибкости, которая упрощает процесс разработки, тестирования и развертывания компонентов в различных средах на протяжении всего жизненного цикла разработки программного обеспечения (SDLC).
Принято считать, что контейнеры предлагают преимущества безопасности, которые дают им преимущество. Кроме того, из-за своей автономной среды ОС они сегментированы по дизайну, что снижает уровень риска.
Тем не менее, контейнеры по-прежнему уязвимы для эксплойтов, таких как прорыв, при котором изоляция нарушена. Контейнеры также могут содержать уязвимость в коде, хранящемся в них.
Для обеспечения безопасности конвейера CI / CD вы должны сканировать уязвимости от начала до конца, в том числе в ваших реестрах.
В дополнение к этим проверкам передовые методы обеспечения безопасности приложений при работе с контейнерами также включают важные задачи, такие как подписание ваших собственных образов с помощью таких инструментов, как Docker Content Trust, если вы используете Docker Hub, или Shared Access Signature, если ваша команда использует Microsoft Azure.
# 5 Сделайте приоритетными свои операции по исправлению положения
В последние годы наблюдается рост числа уязвимостей, и в ближайшее время эта тенденция не замедлится.
Следовательно, разработчики заняты исправлением ошибок. Для команд, которые хотят защитить свои приложения, оставаясь при этом в здравом уме, важна приоритезация.
Оценка угроз выполняется на основе серьезности уязвимости (рейтинг CVSS), критичности затронутого приложения и ряда других факторов.
Вам нужно знать, действительно ли уязвимость с открытым исходным кодом влияет на ваш проприетарный код, когда речь идет об уязвимостях с открытым исходным кодом.
Неэффективно и не представляет большого риска, даже если рейтинг уязвимого компонента по CVSS является критическим, если он не принимает звонки от вашего продукта.
Умные стратегии - это стратегии, в которых первоочередные приоритеты определяются наиболее серьезными угрозами на основе имеющихся факторов, а решения с низким уровнем риска оставляются на потом.
# 6 Шифрование, шифрование, шифрование
В топ-10 OWASP на протяжении многих лет включается шифрование данных в состоянии покоя и в пути, что делает его обязательным для любого списка передовых методов обеспечения безопасности приложений.
Атаки «злоумышленник посередине» и другие формы вторжений могут раскрыть конфиденциальные данные, если вы не сможете должным образом заблокировать свой трафик.
Когда вы хранить пароли и идентификаторы пользователей в виде обычного текста, например, вы подвергаете риску своих клиентов.
Убедитесь, что вы используете SSL с обновленным сертификатом как часть основного контрольного списка для шифрования. Не позволяйте себе отставать сейчас, когда HTTPS является стандартом. Также рекомендуется хеширование.
Кроме того, вы никогда не должны «раскатывать собственную криптовалюту», как говорится. Подумайте о продуктах безопасности, которые поддерживаются специальной командой, имеющей опыт для правильного выполнения работы.
# 7 Управление привилегиями
Вам не нужно предоставлять доступ ко всему каждому в вашей организации. Приложения и данные доступны только тем, кто в них нуждается, следуя рекомендациям по сетевой безопасности и лучшим практикам безопасности приложений.
На это есть две причины. Первое, что вам нужно сделать, это запретить хакеру использовать маркетинговые учетные данные для получения доступа к системе, которая содержит другие более конфиденциальные данные, такие как финансовые или юридические.
Инсайдерские угрозы также вызывают беспокойство, будь то непреднамеренные (например, потеря ноутбука или отправка неправильного вложения в электронное письмо) или злонамеренные.
Принцип наименьших привилегий, заключающийся в предоставлении сотрудникам только тех данных, которые им нужны, когда дело доходит до доступа к данным, может снизить вашу уязвимость по сравнению с отсутствием контроля.
# 8 Используйте автоматизацию для управления уязвимостями
Безопасность их приложений становится все более важной для разработчиков в последние несколько лет, особенно когда речь идет о таких задачах, как управление уязвимостями.
Чтобы устранить сдвиг безопасности влево, команды разработчиков проводят тестирование на раннем этапе и часто, продвигая как можно больше проверок безопасности на ранних этапах процесса разработки, когда исправить уязвимости проще и дешевле.
Чтобы управлять громоздким процессом тестирования из-за огромного количества уязвимостей, разработчикам требуются автоматизированные инструменты.
Чтобы найти потенциальные уязвимости безопасности в вашем проприетарном коде, во время разработки можно использовать статическое тестирование безопасности приложений (SAST) и динамическое тестирование безопасности приложений (DAST).
Бреши в безопасности закрываются с помощью SAST и DAST, однако проприетарный код составляет относительно небольшую часть вашего общего кода.
В более чем 92% всех современных приложений компоненты с открытым исходным кодом составляют 60-80% вашей кодовой базы. Контрольный список безопасности вашего приложения должен отдавать приоритет защите компонентов с открытым исходным кодом.
Используя инструменты анализа состава программного обеспечения, группы могут запускать автоматические проверки безопасности и отчеты по всему SDLC, идентифицируя каждый компонент с открытым исходным кодом в своей среде и указывая, какой из них имеет известную уязвимость, представляющую угрозу безопасности для ваших приложений.
Вы можете лучше управлять своими уязвимостями, переместив автоматическое тестирование проблем безопасности с открытым исходным кодом влево.
# 9 Тестирование на проникновение
Список лучших практик безопасности приложений был бы неполным без упоминания тестирования на проникновение, даже несмотря на то, что автоматизированные инструменты помогают выявить подавляющее большинство проблем безопасности.
Тестирование с помощью ручки и бумаги позволяет вам тыкать и подталкивать ваше приложение, чтобы найти слабые места. Если решительный хакер попытается взломать ваше приложение, хорошие пентестеры точно знают, какие шаги им нужно предпринять.
Можно нанять хакерские фирмы или фрилансеры могут участвовать в программах вознаграждения за ошибки, таких как BugCrowd и HackerOne. Ваша компания должна спонсировать вознаграждение за обнаружение ошибок, если вы еще этого не сделали.
Если вы нанимаете пентестеров, гораздо лучше платить за них, чем разбираться с последствиями реального взлома.
# 10 Будьте осторожны с токенами
Несмотря на то, что это легко защитить, многие разработчики не защищают свои токены должным образом от третьих лиц.
Выполняя поиск на популярных сайтах разработчиков, вы можете легко найти в Интернете незащищенные токены. Вместо того, чтобы хранить детали токенов в другом месте, разработчики просто включают их в свои репозитории с открытым исходным кодом.
Базовая рекомендация по обеспечению безопасности приложений - это надежная защита сторонних токенов. Вы не должны оставлять токены, которые вы приобрели, лежать в коде, чтобы их мог забрать кто-либо.
Рекомендации по обеспечению безопасности приложений как базовые методы
Каждый из описанных здесь передовых методов должен быть интегрирован в процесс непрерывного развития вашей организации. Приложения и данные вашей компании подвергаются риску, если вы не минимизируете этот риск. Выполните следующие действия, чтобы минимизировать риск.
Избегать ошибок, которые могут совершить другие, - это один из способов опередить хакеров, чтобы вас было труднее стать мишенью для атак. Никогда не будет полностью защищенной от взлома меры безопасности периметра или приложения.
Однако следование этим основным передовым методам может иметь большое значение для того, чтобы ваше приложение не стоило хлопот хакерам.
