После компиляции кода в байт-код или его перевода в динамически работающую часть программного обеспечения можно тестировать приложение. Инструменты и тестировщики могут взаимодействовать с ПО, чтобы узнать его положительные или негативные реакции на какие-либо действия и события, тем самым проверяя, насколько оно безопасно. Обычно такие проверки называются динамическим тестированием безопасности приложений (DAST).
При тестировании приложения необходимо искать как дефекты безопасности (ошибки реализации), так и ошибки самого приложения (ошибки проектирования). Необходимо проверять приложение относительно соблюдения конфиденциальности, целостности и доступности (триады CIA), включая данные и другие системы, к которым оно подключается и от которых зависит. Приложение должно соответствовать всем применимым политикам, стандартам, юридическим требованиям и передовому опыту, а также в нем должны отсутствовать часто встречающиеся проблемы, связанные с безопасностью. Необходимо тщательно изучить каждую функцию, касающуюся обеспечения безопасности, и каждую точку интеграции на предмет возможной уязвимости, неправильной конфигурации или ошибки. И, наконец, следует убедиться, что система всегда правильно завершает свою работу, независимо от того, насколько ужасно с ней обращаются.
При проведении тестирования важно сделать все возможное, чтобы избежать «беспорядка». Будьте осторожны, ничего не ломайте, не уничтожайте данные и не выводите системы из строя. Даже если есть возможность использовать уязвимость или взять трофей, не всегда в этом есть необходимость, ведь тестировщика нанимают для того, чтобы проверить безопасность приложения, а не для того, чтобы он продемонстрировал свои навыки. Всегда следует оставаться в рамках соглашения о тестировании и не поддаваться соблазну. По мере приобретения опыта вам будет легче контролировать свое рвение и быть более точным в действиях.
Перед началом тестирования необходимо сделать резервную копию данных и самого приложения, если отсутствует автоматическая система развертывания. Если проверка проводится для третьего лица, необходимо иметь письменное разрешение на тестирование приложений, выданное человеком, имеющим на это полномочия. Редко бывает так, что у человека в соседнем кабинете действительно есть право «принимать риск» при тестировании безопасности, поэтому перед любой подобной проверкой следует убедиться, что вы защищены с юридической точки зрения.
СОВЕТ. Как правило, определение объема и утверждение тестирования документируются в рамках формального процесса во время консультирования или проведения тестирования в качестве третьей стороны. В интернете можно найти несколько книг и статей, объясняющих, как задокументировать этот процесс для юридической защиты.
По возможности следует тестировать приложение в специальной тестовой среде, а не когда оно работает в режиме реального времени. Использование выделенной тестовой среды позволит проводить тестирование без риска для эксплуатационных систем и данных.
СОВЕТ. Составьте официальное заявление о масштабах тестирования, в котором будет указано, какие IP- и URL-адреса будут тестироваться, а также то, будете ли вы тестировать API, сеть, WAF и т. д. Определите в нем используемые инструменты, способы проведения проверки, точки начала, откуда команды безопасности и сети могут ожидать вашего прихода (чтобы они смогли узнать вас), как долго и когда именно будет проходить тестирование, и все остальное, что можно придумать и что может потребоваться. Данный документ, который обычно называется «Правилами взаимодействия» или документом об объеме тестирования, должен быть подписан уполномоченным лицом и храниться в надежном месте.
Хотя в IТ-отрасли много внимания уделяется автоматизации, ручное тестирование по сей день остается самым точным видом проверки безопасности (если его выполняет специалист). Автоматизированные инструменты способны найти большинство проблем значительно быстрее, тем не менее существует множество типов ошибок и дефектов безопасности, которые может обнаружить только квалифицированный человек. Для достижения наилучших результатов используется сочетание ручного и автоматизированного видов тестирования.
Современный веб-браузер – это лучший инструмент тестирования безопасности веб-приложения, так как через него мы общаемся с веб-приложениями. Подготовленный злоумышленник может использовать его, чтобы найти всевозможные проблемы в приложении или даже в самой сети. Большинство проблем с бизнес-логикой, которые чаще всего являются ошибками проектирования, можно найти только с помощью браузера. Автоматизированные инструменты, как правило, не способны выявить такие проблемы. Браузер является самым прямым способом общения с веб-приложениями, и он должен быть первым в арсенале инструментов для тестирования.
Браузеры обычно используются для проверки наличия проблем с бизнес-логикой. Делает ли приложение то, что не должно делать (в ущерб себе)? Можно ли заставить его выполнять действия, которые оно не должно выполнять? Может ли пользователь увидеть информацию, которую он не должен видеть? Браузер можно использовать для входа в систему от имени различных типов пользователей, чтобы убедиться, что никто из них не видит ничего выходящего за рамки его роли в системе (например, может ли обычный пользователь просматривать страницу администратора)?
Тестирование с помощью браузера дает возможность изучить URL-параметры и любые другие места для ввода пользовательских данных (например, поля ввода).
СОВЕТ. Необходимо иметь в своем арсенале несколько (два или три) популярных современных браузеров, потому что проблема может проявляться только в одном конкретном браузере. К тому же различные браузеры имеют различные реализации функций безопасности, конфигурации и собственные уязвимости. Одного браузера недостаточно.