Представляю вашему вниманию продолжение перевода второй главы Owasp Testing Guide. В данной статье речь пойдет о методах тестирования.

Обзор методов тестирования.

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

• Ручной анализ и интервью
• Моделирование угроз
• Анализ исходного кода
• Тестирование на проникновение

Ручной анализ и интервью

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

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

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

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

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

В итоге, можно выделить следующие плюсы и минусы данного метода:

• плюсы:
  • не требует использования технологий
  • можно применить к разным ситуациям
  • гибкость
  • способствует командной работе
  • можно применять на ранних стадиях ЖЦ
• минусы:
  • может занять много времени
  • документация не всегда доступна
  • эффективность метода зависит от знаний и опыта проверяющего

Моделирование угроз

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

Рекомендуется разрабатывать и документировать модель угроз для всех приложений. Они должны быть созданы на ранних стадиях ЖЦ и периодически пересматриваться в процессе развития приложения.

Для разработки модели угроз рекомендуется использовать стандарт NIST 800-30 [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf] для оценки рисков. Он включает в себя:

• Декомпозицию приложения – ручной анализ для понимания того, как приложение работает: его ресурсы, функциональность и связность;
• Определение и классификацию ресурсов – разделение ресурсов на материальные/нематериальные и ранжирование их с точки зрения важности для бизнеса;
• Поиск потенциальных уязвимостей – технических, операционных или организационных;
• Поиск потенциальных угроз – взгляд сверху на возможные векторы атаки, взгляд с точки зрения атакующего, используя сценарии реализации угроз или деревья атак;
• Создание мер по снижению риска – разработка плана действий по снижению ущерба от реализации каждой из потенциальных угроз.

Результатом создания модели угроз является куча списков и диаграмм. Не существует понятия правильной или неправильной модели угроз, а также того, как именно проводить оценку рисков в приложении.

• Плюсы данного метода:
  • взгляд на систему со стороны злоумышленника;
  • гибкость;
  • можно использовать на ранних стадиях ЖЦ.
• Минусы:
  • относительно новый метод;
  • из хорошей модели угроз не следует то, что ПО качественное.

Анализ исходного кода

Анализ исходного кода — это процесс ручной проверки исходного кода веб приложения на наличие проблем безопасности. Многие серьёзные уязвимости не могут быть обнаружены другими способами анализа или тестирования. Как говорится: «если вы не понимаете, что происходит, начните разбор с источника».

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

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

Например, в ходе анализа исходного кода выявляются такие проблемы, как:

• проблемы с параллелизмом;
• проблемы с бизнес-логикой;
• проблемы с управлением доступом;
• криптографические уязвимости;
• бэкдоры;
• трояны;
• «пасхальные яйца»;
• логические бомбы;
• временные бомбы;
• и другие формы вредоносного кода.

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

• Плюсы данного метода:
  • полнота и эффективность
  • точность
  • скорость анализа (для опытных тестировщиков)
• минусы:
  • требуются высококвалифицированные специалисты по ИБ
  • можно пропустить ошибки в коде скомпилированных библиотек
  • тяжело обнаружить ошибки, которые появляются в процессе работы приложения
  • код используемого приложения может отличается от анализируемого

Больше информации по анализу исходного кода можно найти в проекте 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 может выглядеть следующим образом:

http://www.host.com/application?magic=value

Чтобы ещё больше упростить этот пример, значения могут быть только в кодировке ASCII, буквы a – z (в верхнем либо нижнем регистре) и цифры 0-9.

Проектировщики приложения создали административный бэкдор во время тестирования, но скрыли его, чтобы пользователь случайно не его нашёл. Если вставить значение sf8g7sfjdsurtsdieerwqredsgnfg8d (30 символов), то пользователь будет аутентифицирован как администратор с полным контролем за приложением. HTTP запрос получается такой:

http://www.host.com/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Если предположить, что остальные параметры были простыми двух-трёх символьными полями, невозможно начать перебор комбинаций с приблизительно 30-ю символами. Сканеру веб-приложения придётся брутфорсить (или угадать) все возможные варианты строки из 30 символов, а это 30^28, то есть триллионы HTTP запросов. Это всё равно что искать электрон в цифровом стоге сена.

Код для этого экземпляра магического параметра может выглядеть приблизительно так:

Но, посмотрев в код, уязвимость легко обнаруживается и является потенциальной проблемой.

Пример 2: плохая криптография

Криптография широко используется в веб приложениях. Представьте себе ситуацию, что разработчик решил написать простой криптографический алгоритм для аутентификации пользователя с сайта А на сайт Б автоматически. В его понимании это будет выглядеть так: если пользователь прошёл аутентификацию на сайте А, то он сгенерирует ключ используя MD5 хэш функцию которая включает в себя: Hash {логин : дата}.

Когда пользователь переходит на сайт Б, он будет посылать ключ в строковом запросе к сайту Б в HTTP редиректе. Сайт Б независимо считает хэш и сравнивает его с хэшем, переданным в запросе. Если они совпадают, сайт Б аутентифицирует пользователя как того, за кого он себя выдаёт.

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

Немного о статических инструментах анализа исходного кода

Многие организации начали использовать статические анализаторы исходного кода. В то время как они, несомненно, имеют место в программе тестирования, необходимо отметить некоторые фундаментальные проблемы, почему этот подход неэффективен, если используется в одиночку.

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