В этой главе представлен высокоуровневый обзор нескольких методов тестирования, которые могут быть включены в программу тестирования. В ней будет описана суть техник, а также их плюсы и минусы. В частности, мы осветим следующее:
- Ручной анализ и интервью
- Моделирование угроз
- Анализ исходного кода
- Тестирование на проникновение
Ручной анализ и интервью
Ручной анализ обычно используется для проверки безопасности людей, политик и процессов. Кроме этого, он применяется для оценки технологических решений, например, проектирования архитектуры. Ручной анализ чаще всего включает в себя анализ документации либо интервью с проектировщиками или владельцами системы.
Концепция ручного анализа и человеческого интервью проста, но может быть причислена к самым эффективным среди известных методов. Просто спросив у нужного человека «как это работает?», тестировщик может быстро определить, есть ли здесь поводы для беспокойства в плане безопасности. Ручной анализ и интервью являются одними из немногих способов протестировать сам процесс ЖЦ разработки ПО и удостовериться в том, что имеющаяся политика отвечает всем требованиям и навыки людей соответствуют ожиданиям.
CTF исходный код — HackerTest #3
При проведении ручного анализа и интервью рекомендуется придерживаться принципа «доверяй, но проверяй», поскольку не всё, что показывают или говорят тестировщику, будет в действительности так.
Ручной анализ и интервью хорошо отражают то, понимают ли люди процесс обеспечения безопасности, поставили ли их в известность о политиках и имеют ли они необходимые навыки для проектирования или создания безопасного приложения.
Другие активности, включающие ручной анализ документации (стандарты безопасного программирования, требования безопасности, проектирование архитектуры) должны также быть выполнены.
В итоге, можно выделить следующие плюсы и минусы данного метода:
- плюсы:
- не требует использования технологий
- можно применить к разным ситуациям
- гибкость
- способствует командной работе
- можно применять на ранних стадиях ЖЦ
- может занять много времени
- документация не всегда доступна
- эффективность метода зависит от знаний и опыта проверяющего
Моделирование угроз
Моделирование угроз стало популярной техникой для помощи проектировщикам систем в части угроз безопасности, с которыми могут столкнуться их системы и приложения. По этой причине моделирование угроз так часто встречается в качестве метода оценки рисков для приложений. Оно позволяет проектировщикам разрабатывать меры по снижению риска потенциальных уязвимостей, не уделяя вопросу безопасности слишком много времени, и таким образом помогает им сфокусироваться на своих основных задачах.
Рекомендуется разрабатывать и документировать модель угроз для всех приложений. Они должны быть созданы на ранних стадиях ЖЦ и периодически пересматриваться в процессе развития приложения.
Reverse engineering | Исходный код из исполняемого файла | ghidra
- Декомпозицию приложения – ручной анализ для понимания того, как приложение работает: его ресурсы, функциональность и связность;
- Определение и классификацию ресурсов – разделение ресурсов на материальные/нематериальные и ранжирование их с точки зрения важности для бизнеса;
- Поиск потенциальных уязвимостей – технических, операционных или организационных;
- Поиск потенциальных угроз – взгляд сверху на возможные векторы атаки, взгляд с точки зрения атакующего, используя сценарии реализации угроз или деревья атак;
- Создание мер по снижению риска – разработка плана действий по снижению ущерба от реализации каждой из потенциальных угроз.
Результатом создания модели угроз является куча списков и диаграмм. Не существует понятия правильной или неправильной модели угроз, а также того, как именно проводить оценку рисков в приложении.
- Плюсы данного метода:
- взгляд на систему со стороны злоумышленника;
- гибкость;
- можно использовать на ранних стадиях ЖЦ.
- относительно новый метод;
- из хорошей модели угроз не следует то, что ПО качественное.
Анализ исходного кода
Анализ исходного кода — это процесс ручной проверки исходного кода веб приложения на наличие проблем безопасности. Многие серьёзные уязвимости не могут быть обнаружены другими способами анализа или тестирования. Как говорится: «если вы не понимаете, что происходит, начните разбор с источника».
Почти все специалисты по ИБ согласны с тем, что не существует замены методу анализа исходного кода. Вся информация, позволяющая идентифицировать проблемы с безопасностью, находится где-то внутри него. При тестировании веб приложений (особенно если они были разработаны внутри компании) исходный код должен быть доступен для проверки.
Многие случайные, но значимые проблемы безопасности тяжело обнаружить иными видами проверок, как например тестирование на проникновение. С исходным кодом тестировщик может точно определить, что происходит (или должно происходить) и перестать догадываться, как это бывает при тестировании методом черного ящика.
Например, в ходе анализа исходного кода выявляются такие проблемы, как:
- проблемы с параллелизмом;
- проблемы с бизнес-логикой;
- проблемы с управлением доступом;
- криптографические уязвимости;
- бэкдоры;
- трояны;
- «пасхальные яйца»;
- логические бомбы;
- временные бомбы;
- и другие формы вредоносного кода.
Такие уязвимости являются наиболее опасными для вебсайтов. Кроме того, анализ исходного кода может быть эффективен в поиске проблем с проверкой ввода там, где она не была создана или же когда контролирующие ввод процедуры дают сбой. Следует держать во внимании то, что рабочие процедуры должны быть проанализированы отдельно, поскольку реально внедрённый код может отличаться от того, что вы анализируете.
- Плюсы данного метода:
- полнота и эффективность
- точность
- скорость анализа (для опытных тестировщиков)
- требуются высококвалифицированные специалисты по ИБ
- можно пропустить ошибки в коде скомпилированных библиотек
- тяжело обнаружить ошибки, которые появляются в процессе работы приложения
- код используемого приложения может отличается от анализируемого
Больше информации по анализу исходного кода можно найти в проекте OWASP code review [https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project].
Тестирование на проникновение
Тестирование на проникновение является распространённой техникой, которую используют для тестирования сетевой безопасности уже несколько лет. Оно также было широко известно как тестирование методом чёрного ящика или этичный хакинг. Пентест можно считать искусством удалённого тестирования приложения, безо всякой информации о его внутренних механизмах, с целью поиска уязвимостей. Чаще всего команда пентестеров имеет такой же доступ к приложению, как и обычный пользователь, но они действуют как злоумышленники и пытаются обнаружить и эксплуатировать уязвимости.
Пентест зарекомендовал себя как эффективный метод анализа сетевой безопасности, однако в части анализа веб-приложений он не настолько хорош. Когда тестирование на проникновение проводится на сетях и операционных системах большая часть работы заключается в поиске и эксплуатировании известных уязвимостей в отдельных технологиях. Но дело в том, что веб-приложения, по большей части, сделаны на заказ, поэтому при их анализе нельзя применять общие методы. Это исследование, и инструменты пентеста в нём лишь помогают автоматизировать процесс, но не проделать его целиком.
Многие люди сегодня используют тестирование на проникновение веб-приложений как основной метод тестирования безопасности. Пентест имеет место в программе тестирования, но мы не считаем, что он должен считаться основным или единственным способом. Гэри МакГроу [http://www.drdobbs.com/security/beyond-the-badness-ometer/189500001] высказывал своё мнение о пентесте:
«Если вы провалили пентест – вы, конечно, знаете, что у вас серьёзные проблемы. Если же вы успешно прошли пентест – вы не знаете о том, что у вас нет серьёзных проблем».
Поэтому пентест не может считаться лучшим и основным методом анализа безопасности веб-приложений. Однако он может быть использован для целенаправленной проверки того, была ли исправлена та или иная уязвимость.
Плюсы данного метода:
- может быть выполнен быстро (и, следовательно, дёшево)
- требует меньше навыков, чем, например, при анализе исходного кода
- тестирует код, который в настоящий момент используется и работает
- используется на слишком поздних стадиях ЖЦ
- тестирование только прямых атак
Необходим комплексный подход
С таким количеством техник и подходов к тестированию безопасности веб-приложений может быть сложно понять, какие методы нужно применять и когда их использовать. Однако многие компании принимают всего один подход. Исторически сложилось так, что им стал пентест. Несмотря на все его преимущества, пентест не может быть эффективен во многих ситуациях, которые требуется проверить.
Правильно будет использовать сбалансированный подход, который включает несколько техник: от ручного анализа до технического тестирования. Он может быть применён в тестировании на всех стадиях ЖЦ, так как в нём используются наиболее подходящие техники в зависимости от текущей стадии.
Конечно бывают случаи, когда есть возможность использовать всего один метод. Например, тестирование выпущенного веб-приложения при том, что тестирующая сторона не имеет доступа к исходному коду. В таком случае пентесты явно лучше, чем отсутствие тестирования вовсе. Тестирующей стороне рекомендуется оспаривать такие предпосылки, как отсутствие доступа к исходному коду, и искать возможности для проведения более полного тестирования.
Сбалансированный подход меняется в зависимости от множества факторов, таких как зрелость процесса тестирования и корпоративной культуры. Рекомендуемая программа для сбалансированного тестирования должна быть распределена примерно так, как на диаграммах ниже.
Следующая диаграмма показывает типичное пропорциональное распределение ресурсов для тестирования на стадиях ЖЦ приложения. Важно, чтобы в компании делали упор на ранние стадии разработки ПО.
Рис. 3. Распределение ресурсов для тестирования по стадиям ЖЦ
Следующая диаграмма показывает типичное распределение ресурсов по методам тестирования в рамках одной стадии ЖЦ.
Рис. 4. Распределение ресурсов для тестирования по методам тестирования
Немного о сканерах веб-приложений
Многие организации начали использовать автоматические сканеры веб приложений. Они, несомненно, имеют место в программе тестирования, но следует понимать некоторые их фундаментальные проблемы. Выделение таких проблем нужно не для препятствия в их использовании, а с целью удостовериться в том, что ограничения были поняты и программы тестирования спланированы надлежащим образом.
Следующие примеры показывают, почему автоматическое тестирование методом чёрного ящика бывает неэффективным.
Пример 1: магические параметры
Представьте себе простое веб-приложение, которое принимает пару имя-значение «магии» и затем само значение. Для упрощения, запрос GET может выглядеть следующим образом:
Чтобы ещё больше упростить этот пример, значения могут быть только в кодировке ASCII, буквы a – z (в верхнем либо нижнем регистре) и цифры 0-9.
Проектировщики приложения создали административный бэкдор во время тестирования, но скрыли его, чтобы пользователь случайно не его нашёл. Если вставить значение sf8g7sfjdsurtsdieerwqredsgnfg8d (30 символов), то пользователь будет аутентифицирован как администратор с полным контролем за приложением. HTTP запрос получается такой:
Если предположить, что остальные параметры были простыми двух-трёх символьными полями, невозможно начать перебор комбинаций с приблизительно 30-ю символами. Сканеру веб-приложения придётся брутфорсить (или угадать) все возможные варианты строки из 30 символов, а это 30^28, то есть триллионы HTTP запросов. Это всё равно что искать электрон в цифровом стоге сена.
Код для этого экземпляра магического параметра может выглядеть приблизительно так:
код по примеру 1
public void doPost (HttpServletRequest request, HttpServletResponse response)
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals (request.getParameter(“magic”));
if (admin) doAdmin (request, response);
else …. // normal processing
Но, посмотрев в код, уязвимость легко обнаруживается и является потенциальной проблемой.
Пример 2: плохая криптография
Криптография широко используется в веб приложениях. Представьте себе ситуацию, что разработчик решил написать простой криптографический алгоритм для аутентификации пользователя с сайта А на сайт Б автоматически. В его понимании это будет выглядеть так: если пользователь прошёл аутентификацию на сайте А, то он сгенерирует ключ используя MD5 хэш функцию которая включает в себя: Hash .
Когда пользователь переходит на сайт Б, он будет посылать ключ в строковом запросе к сайту Б в HTTP редиректе. Сайт Б независимо считает хэш и сравнивает его с хэшем, переданным в запросе. Если они совпадают, сайт Б аутентифицирует пользователя как того, за кого он себя выдаёт.
Так как схема задокументирована, любое несоответствие требованиям может быть исправлено. Но любой, кто узнает о схеме (или если ему расскажут, как это работает) сможет авторизоваться под любым пользователем. Ручной анализ, интервью или анализ исходного кода, могли бы быстро раскрыть эту проблему безопасности. Сканер веб-приложения при тестировании методом черного ящика не обнаружил бы этой уязвимости. Он бы видел только 128-битный хэш, который изменяется от пользователя к пользователю, и, по природе хэш функций, не изменяется в каком-либо предсказуемом порядке.
Немного о статических инструментах анализа исходного кода
Многие организации начали использовать статические анализаторы исходного кода. В то время как они, несомненно, имеют место в программе тестирования, необходимо отметить некоторые фундаментальные проблемы, почему этот подход неэффективен, если используется в одиночку.
Статический анализ исходного кода не может определить проблемы проектирования, т.к. он не может понять контекста, в котором написан код. Анализаторы кода полезны в определении проблем безопасности из-за ошибок в коде, однако требуется значительный ручной труд, чтобы подтвердить результаты его работы.
- akhudyshkin
- 7360 0 —>
- Web security
Оставить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Источник: defcon.ru
Сканеры исходного кода
Системы и средства анализа исходного кода для выявления проблем безопасности
Выбор средств защиты
Поиск
Мнение
Алексей Смирнов
Задать вопрос
Описание и назначение
Сканеры исходного кода выявляют ошибки в исходном коде, допущенные при разработке программ, которые могут использоваться злоумышленниками в качестве уязвимостей и взлома информационной системы.
Анализ исходного кода необходим, чтобы выявить возможные уязвимости в программном обеспечении, проверить код приложения на наличие бэкдоров и программных закладок, которые могут в дальнейшем использоваться злоумышленниками для получения несанкционированного доступа в систему. Еще одной причиной анализа исходного кода является необходимость его проверки на наличие ошибок, которые могут привести к сбоям в работе, потере критичных данных или нарушению существующих в организации бизнес-процессов.
Существуют несколько типов сканеров исходного кода, которые делятся в зависимости от того, какие приложения и программы необходимо подвергать анализу:
- Веб-приложения и веб-сервисы. В данном случае анализаторы кода необходимо использовать для снижения рисков эксплуатации уязвимостей на сайтах.
- Встраиваемые модули приложений. Анализаторы кода этого типа предназначены для проверки исходного кода компонентов, встраиваемых в основное программное обеспечение. Это актуально в случае, когда организация заказывает разработку дополнительной функциональности уже используемого приложения, например CRM-систем или SAP.
- Приложений, которые не связаны с бизнес-приложениями и сайтами. Здесь подразумеваются отдельные программные продукты. Такой тип анализаторов подходит для защищенной разработки программ.
Несмотря на подобное разделение, большинство анализаторов относится к смешанному типу, которые могут применяться в различных сферах и предоставляют широкий спектр возможностей.
Сканеры исходного кода кода могут применять два основных механизма, которые могут предоставляться совместно:
- Статический анализ, или SAST (Static Application Security Testing), когда анализ выполняется без запуска программного обеспечения.
- Динамический анализ, или DAST (Dynamic Application Security Testing), когда анализ кода выполняется в процессе его выполнения.
На вход анализатора кода поступает массив данных (исходный код и все зависимые модули), а после проверки средства анализа кода предоставляют подробный отчет о найденных ошибках и уязвимостях. Некоторые анализаторы кода способны самостоятельно исправлять ошибки, но стоит учитывать, что данная функция может работать не совсем корректно. В связи с этим опытным разработчикам необходимо контролировать данный процесс.
Принцип работы любых анализаторов кода связан с базами данных, которые они используют в процессе анализа. Это может быть база уязвимостей, поставляемая разработчиками средств для анализа кода. У них также могут быть собственные базы ошибок, допускаемых при программировании. В различных странах существуют государственные базы данных, которые используют анализаторы кода.
Они могут применяться как встроенные средства анализа либо в качестве отдельных механизмов. Наравне с указанными базами существует и третий тип, подразумевающий проверку требований стандартов, рекомендаций и лучших практик.
Источник: www.anti-malware.ru
Аудит исходного кода с помощью GREP
Мануал
Автор cryptoparty На чтение 9 мин Опубликовано 18.05.2022
Сегодня в этом руководстве мы поговорим о статическом тестировании безопасности приложений (SAST), его методологии, типах, методах, инструментах и т.д.
В этой статье мы дадим вам краткий обзор SAST, а затем покажем, как мы можем найти уязвимости в исходном коде любого веб-приложения на базе языка PHP с помощью утилиты kali linux под названием “grep”.
Что такое анализ исходного кода или аудит исходного кода?
Согласно OWASP: Анализ или аудит исходного кода, также известный как инструменты статического тестирования безопасности приложений (SAST), может помочь проанализировать исходный код или скомпилированные версии кода, чтобы помочь найти недостатки безопасности.
SAST очень важен как для организации, так и для нас, поскольку он помогает анализировать исходный код для обнаружения уязвимостей безопасности, которые делают приложения нашей организации восприимчивыми к атакам, поэтому мы должны знать обо всем этом с точки зрения потенциала безопасности.
Давайте покажем вам небольшую разницу между SAST и DAST:
Что такое тестирование “черного ящика” и “белого ящика”?
Методы SAST и DAST также известны как тестирование “белого ящика” и тестирование “черного ящика”.
Тестирование “черного ящика” относится к любому типу тестирования программного обеспечения, которое исследует приложение без знания внутреннего дизайна, структуры или реализации программного проекта.
Тестирование “белого ящика” – это тип тестирования, при котором тестировщик может видеть код.
Перейдем к части установки уязвимого приложения
Установка веб-приложения с уязвимостью bWAAP
bWAPP, или buggy web application – это бесплатное заведомо небезопасное веб-приложение с открытым исходным кодом.
bWAPP – это PHP-приложение, использующее базу данных MySQL.
Оно может быть размещено на Linux/Windows с Apache/IIS и MySQL
Настроить это уязвимое приложение в любой операционной системе довольно просто, для этого достаточно скачать приложение по ссылке, приведенной ниже, разархивировать его и переместить все файлы в каталог apache и все.
https://sourceforge.net/projects/bwapp/ unzip -d /var/www/html/bwaap/ bWAAP_latest.zip
Теперь вы можете проверить, все ли файлы распакованы или нет, перейдя в каталог apache с помощью следующей команды.
cd /var/www/html/bWAPP/ ls -l 
Что такое утилита Grep?
Grep – это утилита командной строки для поиска в наборах данных обычного текста, соответствующих регулярному выражению.
Ее название происходит от команды ed g/re/p (globally search for a regular expression and print matching lines), которая имеет тот же эффект.