Тестирование безопасности приложения

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Содержание

• Что подразумевается под “безопасностью” ПО?
• Тестирование безопасности десктопных и веб-приложений
• Что нужно протестировать с точки зрения безопасности
  1. Доступ к приложению
  2. Защита данных
  3. Брутфорс-атака
  4. SQL-инъекции и XSS (межсайтовый скриптинг)
  5. Точки доступа к сервисам
  6. Управление сессиями
  7. Обработка ошибок
  8. Функционал с большим риском

Что подразумевается под “безопасностью” ПО?

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

Это означает, что online-приложения завоевали доверие клиентов и пользователей благодаря своей жизненно важной характеристике – БЕЗОПАСНОСТИ.

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

Но что мы вообще подразумеваем под словом “безопасность” в контексте ПО?

“Безопасность” означает, что к защищенным данным доступ предоставляется только с авторизацией, а доступ без авторизации ограничен.

Таким образом, безопасность ПО имеет два основных аспекта: первый – это защита данных, а второй – доступ к ним. Не важно, говорим мы о десктопном или веб-приложении: все равно вся безопасность основывается на двух вышеупомянутых аспектах.

Примеры недостатков безопасности в приложении

• Система управления студентами в образовательном учреждении небезопасна, если через раздел “Прием” можно редактировать данные раздела “Экзамены”.
• Приложение для онлайн-торговли не может считаться безопасным, если данные кредитной карты клиента не зашифрованы.
• Пользовательское ПО не обладает достаточной безопасностью, если при помощи злонамеренного ввода SQL-запроса можно получить реальные пароли пользователей.

Тестирование безопасности десктопных и веб-приложений

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

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

Также следует помнить, что брутфорс-атака может применяться не только к веб-приложениям, но и к десктопному ПО.

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

Что нужно протестировать с точки зрения безопасности

1. Доступ к приложению

Будь то десктопное приложение или веб-сайт, безопасность доступа реализуется с помощью управления ролями и правами. Часто это делается неявно.

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

Как протестировать доступ к приложению

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

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

Этот вид тестирования также можно считать тестированием аутентификации и авторизации. Если коротко, аутентификация – проверка того, кто вы такой, а авторизация – проверка того, что вы можете делать.

Итак, по сути, вам нужно проверить аспекты “кто вы” и “что вы можете делать” для отдельных пользователей.

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

Аналогично, некоторые из видов тестирования авторизации включают в себя тесты на уязвимость Path Traversal, на отсутствие авторизации, на проблемы горизонтального управления доступом и т.д.

2. Защита данных

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

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

Второй аспект защиты данных связан с тем, как данные хранятся в БД.

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

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

Как протестировать защиту данных

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

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

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

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

Также стоит проверить, не подвержено ли приложение такой уязвимости, как небезопасная рандомность (Insecure Randomness), и не используются ли слабые алгоритмы.

Например, HTTP является протоколом открытой передачи данных. Если конфиденциальные данные, такие как учетные данные пользователя, передаются через HTTP, то это представляет угрозу для безопасности приложения. Вместо HTTP конфиденциальные данные должны передаваться по протоколу HTTPS, защищенному с помощью туннелей SSL и TLS. Однако HTTPS увеличивает возможности атаки, поэтому необходимо проверить правильность конфигурации сервера и достоверность сертификата.

3. Брутфорс-атака

Атака “грубой силы” в основном осуществляется при помощи программных инструментов. Суть ее в том, что программа использует действующий идентификатор пользователя и старается угадать связанный с ним пароль. Для этого она снова и снова пытается войти в систему.

Простым примером защиты от такой атаки является приостановка учетной записи на короткий период времени. Так делают все почтовые приложения, такие как Yahoo, Gmail и Hotmail. Если определенное количество последовательных попыток (чаще всего 3) не приводит к успешному входу в систему, то учетная запись блокируется на некоторое время (от 30 минут до 24 часов).

Как протестировать приложение на устойчивость к брутфорс-атаке

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

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

Тестирование на устойчивость к брутфорс-атаке можно проводить методом черного или серого ящика.

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

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

4. SQL-инъекции и XSS (межсайтовый скриптинг)

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

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

Например, для поля “Фамилия” длина поля должна быть 30, а не 255. Для полей, где может возникнуть необходимость ввода большого объема данных, нужно реализовать надлежащую валидацию ввода перед сохранением данных.

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

Как протестировать приложение на устойчивость к SQL-инъекциям и XSS-атакам

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

Например, если 20 – максимальная длина ввода, указанная для поля ‘Name’, то строка ввода “<p>thequickbrownfoxjumpsoverthelazydog” может проверить оба эти ограничения.

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

5. Точки доступа к сервисам (закрытые и защищенные открытые)

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

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

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

Как тестировать точки доступа к сервисам

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

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

Также следует учесть, что большое количество пользователей будет взаимодействовать с приложением одновременно. Поэтому приложение должно обеспечивать достаточное количество точек доступа, чтобы обслужить запросы всех пользователей.

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

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

Тестировщик должен проверить, что весь межсетевой и внутрисетевой доступ к приложению осуществляется через доверенные приложения, машины и пользователей.

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

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

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

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

Именно так QA может проверить безопасность приложения в отношении точек доступа.

6. Управление сессиями

Веб-сессия – это последовательность HTTP-запросов и ответных транзакций, связанных с одним и тем же пользователем. Тестирование позволяет проверить, как в веб-приложении осуществляется управление сессиями.

Вы можете протестировать истечение сессии после определенного времени простоя, завершение сессии после максимального времени жизни, завершение сессии после выхода из системы. Также можно проверить, может ли один пользователь иметь несколько одновременных сессий, и т.д.

7. Обработка ошибок

Тестирование обработки ошибок включает в себя проверку наличия кодов ошибок и наличие трассировки стека.

Проверка наличия кодов ошибок

Например, проверка HTTP-статусов 408 (request timeout), 400 (bad requests), 404 (not found) и т.д. Чтобы их протестировать, необходимо выполнить определенные запросы на странице таким образом, чтобы были возвращены эти коды ошибок.

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

Проверка наличия трассировки стека

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

8. Функционал с большим риском

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

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

Перевод статьи “Security Testing (A Complete Guide)” .