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

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

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

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

В тестировании безопасности соотношение между ручным и автоматизированным тестированием является чрезвычайно важным.

Ручное тестирование безопасности. XSS и SQL-инъекции

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

• Пользователь не может непреднамеренно нарушить работу системы.
• Хакер, не использующий никаких дополнительных инструментов, не может вызвать серьезных проблем.

Существует два основных типа атак, которые могут быть осуществлены вручную: XSS (Cross-Site Scripting) и SQL-инъекции. Обе эти атаки требуют более точного описания.

XSS-инъекции

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

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

http:\/\/test-site.com\/search.php?q=<script>document.cookie<\/script>.<\/p>

Скрипт похищает файлы cookie вошедшего в систему пользователя. .

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

Рассмотрим пример SQL-инъекции:

SELECT * FROM Users; DROP TABLE Customers

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

<\/p>

Как предотвратить SQL-инъекцию?

На самом деле уязвимости SQL-инъекции достаточно легко избежать. Для этого достаточно выполнить следующие действия:

• Использовать параметризованные запросы к базе данных. Это позволяет базе данных отличить код от данных и не пропустить SQL-инъекцию.
• Использовать хранимые процедуры для обработки данных.
• Использовать белый список проверки ввода. Такой подход не позволит пользователю ввести данные в формате, отличном от ожидаемого.

Если ни один из перечисленных вариантов не реализуем, то следует исключить ввод данных пользователем. Однако этот прием не является "серебряной пулей" для защиты веб-приложения от любых SQL-инъекций.

Другие уязвимости, которые можно обнаружить при ручном тестировании

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

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

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

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

Автоматизированное тестирование безопасности

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

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

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

Заключение

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