Security testing что это
Тестирование
Раздел: Тестирование > Виды Тестирования > Тестирование безопасности
Тестирование безопасности или Security and Access Control Testing
Принципы безопасности программного обеспечения
Общая стратегия безопасности основывается на трех основных принципах:
Конфиденциальность
Целостность
Существует два основных критерия при определении понятия целостности:
Доступность
Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс тем выше уровень доступности должен быть.
Виды уязвимостей
В настоящее время наиболее распространенными видами уязвимости в безопасности программного обеспечения являются:
Как тестировать ПО на безопасность?
Приведем примеры тестирования ПО на предмет уязвимости в системе безопасности. Для этого Вам необходимо проверить Ваше программное обеспечение на наличия известных видов уязвимостей:
XSS (Cross-Site Scripting)
Сами по себе XSS атаки могут быть очень разнообразными. Злоумышленники могут попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего навсего разместив вредоносный скрипт у вас на сайте. Как пример, можно рассмотреть следующий скрипт, выводящий на экран ваши куки:
либо скрипт делающий редирект на зараженную страницу:
либо создающий вредоносный объект с вирусом и т.п.:
Для просмотра большего количества примеров рекомендуем посетить страничку: XSS (Cross Site Scripting).
XSRF / CSRF (Request Forgery)
Наиболее частыми CSRF атаками являются атаки использующие HTML тэг или Javascript объект image. Чаще всего атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код. Примеры:
Code injections (SQL, PHP, ASP и т.д.)
Вставки исполняемого кода рассмотрим на примере кода SQL.
Вводим корректное имя ’tester’, а в поле пароль вводим строку:
В итоге, Если поле не имеет соответствующих валидаций или обработчиков данных, может вскрыться уязвимость, позволяющая зайти в защищенную паролем систему, т.к.SQL запрос примет следующий вид:
Условие ‘1’=’1′ всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений.
Server-Side Includes (SSI) Injection
В зависимости от типа операционной системы команды могут быть разными, как пример рассмотрим команду, которая выводит на экран список файлов в OS Linux:
Authorization Bypass
Пользователь А может получить доступ к документам пользователя Б. Допустим, есть реализация, где при просмотре своего профиля, содержащего конфеденциальную информацию, в URL страницы передается userID, а данном случае есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если вы увидите его данные, значит вы нашли дефект.
Вывод
Примеров уязвимостей и атак существует огромное количество. Даже проведя полный цикл тестирования безопасности, нельзя быть на 100% уверенным, что система по-настоящему обезопасена. Но можно быть уверенным в том, что процент несанкционированных проникновений, краж информации и потерь данных будет в разы меньше, чем у тех кто не проводил тестирования безопасности.
Тестирование безопасности
Введение в тестирование безопасности
Типы тестирования безопасности
Руководство по методологии тестирования безопасности с открытым исходным кодом имеет семь основных типов тестов безопасности. Описано следующее:
1. Сканирование уязвимостей
Это выполняется с помощью автоматизированного программного обеспечения для сканирования системы на наличие известных признаков уязвимости.
2. Сканирование безопасности
Он включает в себя выявление слабых мест в сети и системе и предлагает альтернативы для снижения таких опасностей. Для ручного и автоматического сканирования это сканирование может быть сделано.
3. Тест на проникновение
Этот тест имитирует злонамеренную хакерскую атаку. Это исследование включает анализ конкретной системы для выявления возможных уязвимостей для внутреннего взлома.
4. Оценка риска
Этот тест включает в себя анализ угроз безопасности, наблюдаемых в компании. Риски имеют низкую, среднюю и высокую классификацию. Этот тест предлагает меры по снижению риска и действия.
5. Аудит безопасности
Аудит также может проводиться в режиме онлайн по линии, проверок кода и операционных систем на наличие ошибок безопасности.
6.Этический взлом
Этический взлом не то же самое, что злонамеренный взлом. Этический взлом направлен на выявление недостатков безопасности в организационной структуре.
7. Оценка осанки
Это объединяет сканирование безопасности, оценки рисков и этический взлом, чтобы показать общую позицию безопасности организации.
Методологии тестирования безопасности
Существуют разные методики тестирования безопасности
1. Тигровая шкатулка
2. Черный ящик
3. Серая коробка
Tiger Box:
Этот взлом обычно выполняется на ноутбуке с операционной системой и набором инструментов взлома. Этот тест позволяет операторам тестирования на проникновение и операторам тестирования безопасности оценивать и атаковать уязвимости.
Черный ящик:
Серая коробка:
Как мы можем провести тестирование безопасности?
Всегда считалось, что если мы отложим тестирование безопасности после внедрения или развертывания программного обеспечения, эта стоимость будет увеличена. На более ранних этапах тесты безопасности должны выполняться в жизненном цикле SDLC. Давайте посмотрим на соответствующие процедуры безопасности для каждого этапа SDLC. Для областей ввода тестер может проверить максимальную длину. Это ограничение может не позволять хакеру включать такие вредоносные скрипты.
• Оценка безопасности требований и проверка злоупотреблений / злоупотреблений.
• Анализ угроз безопасности для проектирования. Разработка плана испытаний, включая тестирование безопасности.
10 лучших инструментов тестирования безопасности с открытым исходным кодом
Ниже приведен список лучших инструментов тестирования безопасности вместе с их функциями. Вы можете выбрать любой инструмент в зависимости от ваших потребностей.
1. вапити
Особенности Wapiti
• XSS инъекция
• Внедрение базы данных
• Обнаружение выполнения команды.
• впрыск CRLF
2. Zed Attack Proxy
Zed Attack Proxy, обычно известный как ZAP, ZAP был создан OWASP и с этим ZAP является открытым исходным кодом. Zed Attack Proxy При поддержке Unix / Linux, Windows и Mac OS Zed Attack Proxy позволяет выявлять ряд уязвимостей даже на стадии разработки и тестирования в веб-приложениях. Этот инструмент тестирования прост в использовании, даже если вы начинающий тест на проникновение.
Особенности Zed Attack
• Zed Attack Proxy поддерживает сканер автоматизации и поддержку аутентификации.
• Zed Attack Proxy также имеет динамический сертификат SSL и поддержку веб-сокетов.
3. Вега
Особенности Vega
• Вега имеет межсайтовый скриптинг.
• Проверка SQL-инъекций
4. W3af
Особенности W3af
• Несколько дефектных настроек CORS
• CSRF и многое другое уязвимость
5. Skipfish
6. SQLMap
7. Wfuzz
Особенности Wfuzz
• Wifuzz поддерживает несколько точек впрыска.
• Выход Wfuzz в HTML
• Он также имеет многопоточность
• Также имеется поддержка нескольких прокси
8. Metasploit
Особенности Metasploit
• Структура намного лучше, чем у конкурентов.
• Множество сценариев для инфильтрационных макетов
9. Acunetix
Полный инструмент оценки проникновения автоматизации для сканирования ваших сайтов на наличие 4500+ уязвимостей. Самая поразительная особенность Acunetix в том, что он может перебирать тысячи страниц без перерыва.
Особенность Acunetix
10. Граббер
Особенности Grabber
• Резервное копирование файлов
• Проверка Ajax
Вывод
В этой статье мы увидели, что такое тестирование безопасности, зачем оно нам, наряду с различными типами тестирования безопасности, инструментами, используемыми для тестирования, и функциями. Надеюсь, что эта статья поможет вам выбрать инструменты тестирования на основе ваших требований и функций, указанных выше.
Рекомендуемые статьи
«Осторожно, печеньки!»: советы начинающим тестировщикам в сфере безопасности
Привет, меня зовут Вика Бегенчева, я QA-инженер в Redmadrobot. Я расскажу, как злоумышленники крадут наши данные, и что можно сделать, чтобы от этого защититься.
Термин «тестирование безопасности» звучит довольно серьёзно. Многие боятся погружаться в эту тему, думая, что их ждут непроходимые дебри из непонятных слов, сложной литературы и загадочных аббревиатур. Я разберу основы тестирования безопасности и вы убедитесь, что на самом деле это просто и интересно.
Статья написана для начинающих тестировщиков безопасности и тех, кому непонятно, что за «фрукты» эти хакеры и чем они там занимаются. Мы рассмотрим примеры самых частых уязвимостей и постараемся разобраться, как грамотно проверить проект на слабые места и сформировать у себя образ мышления, который в дальнейшем станет вашим верным помощником в тестировании.
Допустим, мы зашли на сайт интернет-магазина ошейников для собак и выбрали французский язык (почему бы и нет). Добавили в корзину пару шлеек и поводок. Что будет, если мы закроем вкладку и зайдём на сайт снова? Всё останется прежним: интерфейс на французском и три товара в корзине. Магия? Нет, cookie.
Cookie — один из инструментов, который формирует так называемый фингерпринт каждого пользователя в сети. Его можно сравнить с «отпечатком пальца», по которому можно узнать, что за человек покупает ошейник для собаки.
На вашем устройстве есть текстовый файл, в котором содержится различная информация о пользователе для каждого сайта — cookie. Она хранится для разных целей, в том числе и для удобства пользования сайтом. Cookie бывают временные (cookie-сессии) и постоянные. Давайте взглянем на них поближе.
Открываем панель разработчика в Chrome и переходим на рандомную статью на «Хабре». Во вкладке Network находим первый запрос, и в хедерах видим как проставляются cookie:
Cookie типа audio_player_volume=0.75 (из скриншота выше — параметр, вероятно, отвечающий за громкость плеера на сайте) или те, которые хранят товары в корзине — постоянные cookie. Они не меняются, если пользователь их не трогает. Нас же интересуют временные или сессионные cookie. Они хранят информацию, которая помогает сайту понять, что это всё тот же пользователь в текущей сессии.
Например, при авторизации на сайте, в файл cookie проставляется условный session_id — уникальный идентификатор сессии на данный момент времени, к которому привязаны текущий браузер и пользователь.
Когда мы совершаем действия, доступные только этому пользователю, мы отправляем в хедер запроса (заголовок запроса, в него передаётся способ общения с сервером) и данные, которые локально сохранили в cookie, чтоб подтвердить, что это мы, а не условный программист из Финляндии. Временные cookie имеют срок годности и стираются в конце сессии, или становятся неактуальными с течением времени.
Если хакеру удастся угнать cookie пользователя, то он сможет действовать от его лица или же просто получит конфиденциальную информацию юзера. Как узнать, всё ли впорядке?
Во-первых, нужно проверить, не хранятся ли пароли от сайтов в cookie. Удивительно, но в 2021 году до сих пор существуют сайты, которые это делают. Информация о сессиях должна иметь ограничения — быть временной или заменяться с каждой новой сессией.
Во-вторых, нужно проверить, чтобы все конфиденциальные cookie были с флагом httpOnly и secure.
Cookie с флагом “secure” передаются на сервер только по протоколу HTTPS. Как правило, в этом случае есть сертификат SSL или TLS. Cookie с флагом “httpOnly” защищены от манипуляции JavaScript через документ, где хранятся cookie.
Открываем в Chrome «инструменты разработчика» и переходим во вкладку Application.
Проверяем, не хранятся ли пароли в LocalStorage в этом же разделе «инструментов разработчика».
Теперь рассмотрим сценарии кражи пользовательских данных и как от них защититься.
Гуляя по сайтам мы до сих пор встречаем предупреждения браузеров о «незащищённом соединении». Иногда строгий браузер вообще не пускает нас на сайт, потому что не хочет нести за него ответственность. А чего он боится?
А боится он протокола HTTP — он древний и небезопасный. Все современные сайты общаются по протоколу HTTPS и вот их браузер любит. Разница между HTTP и HTTPS всего в одной букве, но эта буква означает много — «Secure». Безопасность передачи данных — главный приоритет современных браузеров.
Сайты, которые общаются с сервером по протоколу HTTPS, используют сертификат TLS (его предшественник — SSL). Такой сертификат может защищать как один домен, так и группу поддоменов.
Вернёмся в магазин — мы решили всё-таки купить ошейник своей собаке. Переходим в корзину, вводим данные банковской карты для оплаты, нажимаем на большую кнопку «Оплатить» и наши данные улетают на сервер для обработки запроса. Допустим, злоумышленники решили перехватить данные нашей банковской карты в момент отправки запроса.
Если сайт общается по протоколу HTTPS, то между магазином и сервером построен безопасный «мост». SSL-сертификат позволяет шифровать данные нашей карты и преобразует их в нечитаемый набор символов.
На этом моменте все хакеры мира грустят, потому что они знают, что расшифровать данные может только сервер. На нём есть ключ дешифратор, который поможет понять, какие данные мы ввели на сайте и правильно их обработать.
Чтобы защититься от кражи данных, убедитесь:
Допустим, в нашем любимом магазине ошейников для питомцев есть админка. Владелец сайта решил оставить ссылку админки по адресу “https:// […].com/admin”. Злоумышленник переходит по этому адресу и его ждёт страница входа в панель администратора. Допустим, наш хакер вводит логин «admin», а пароль подбирает с помощью скрипта, который сам будет перебирать пароли.
Если логин верный, то узнать пароль дело нескольких часов. Запустил скрипт на ночь, лёг спать, а утром уже есть доступ к панели администратора. Такой перебор и есть brute force атака.
Защититься от взлома можно несколькими способами (про авторизацию/аутентификацию и oauth2 мы поговорим ниже). Но, если речь идёт о brute force атаке, то простейшая защита тут — установка лимита на попытки ввода пароля.
Лимиты устанавливают в зависимости от специфики продукта и решения проектной команды:
Естественно, это не избавит от всех проблем, но сильно усложнит жизнь злоумышленнику.
Давайте представим, что мы захотели вступить в тайный клуб любителей настольных игр. Туда просто так не попасть. Сначала нужно доказать, что мы подходим на роль члена клуба — любим настолки.
Итак, в клубе знают наше имя и фамилию, мы доказали, что любим игры, и теперь нам выдадут специальный пропуск, по которому мы сможем проходить в здание закрытого клуба. Теперь не нужно каждый раз доказывать, что мы — это мы. У нас есть волшебный ключ-пропуск, который открывает двери тайного клуба.
А что будет, если наш пропуск-ключ украдут? По нему просто войдут в здание и узнают все секреты закрытого клуба. Токены сессии — это ключи к ресурсам нашего сайта. Когда мы логинимся на сайте, мы отправляем запрос на авторизацию/аутентификацию пользователя. На сервере проверяются его права и генерируется токен.
Access-token определяет права пользователя и доступность ресурсов для него. Выглядит он как длинный набор символов. Можно сказать, что токен — тот самый пропуск, который нам выдали в нашем тайном клубе.
При каждом следующем обращении к ресурсам теперь нам не нужно вводить логин и пароль, чтоб доказать, что мы имеем право на доступ. Просто в каждым запросе на ограниченный ресурс отправляем наш пропуск — access-token.
Хорошей и частой практикой является использование время жизни токена. После логина и формирования access-токена, фиксируется время жизни – дата, до которой токен считается действительным. Это как абонемент на месяц в тайный клуб.
На разных ресурсах, требования ко времени жизни токена разные. На одном сайте токен живёт год, а на другом — всего лишь час. После того как срок действия токена истечёт, система попросит пользователя снова авторизоваться. Чтобы не вводить всё время логин и пароль после истечения access-токена, придумали refresh-токен.
У refresh-токена только одна цель — обновлять access-токен. Это работает так:
отправляем запрос на закрытый ресурс с истекшим аксесс-токеном;
Готово! А пользователи сайта даже ничего не увидели и не поняли. Как этим пользуются хакеры?
Access- и refresh-токены – это токены сессии. Если злоумышленнику удастся перехватить их, то он докажет, что он — это мы, просто подставив в запрос. Он получит доступ к нашим ресурсам и сможет совершать действия от нашего имени.
Чтобы защититься, нужно:
Чтобы обеспечить безопасность системе и разрешить взаимодействовать с ней разным ролям пользователей (админы, модераторы и т.д.), важно понимать различия между авторизацией и аутентификацией.
Аутентификация — это проверка на соответствие заявленного имени пользователя (паспорта) с идентификатором в системе (Лаврентий Куашников). Авторизация — это предоставление нам прав в соответствии с нашей ролью в системе (отдельная комната для спикера).
Вернёмся к примеру с админкой нашего магазина ошейников. Снова переходим по адресу админки и нас ждёт страница с вводом логина и пароля. Логин — это идентификатор пользователя в системе. Пароль — это доказательство пользователя, что он — это он (ведь только он может знать пароль).
Когда в запросе мы отправляем эти данные, сервер проверяет их на соответствие — это аутентификация. Если аутентификация прошла успешно, то сервер смотрит в базе данных на нашу роль в системе и какие возможности у нас есть — это авторизация.
В разных сервисах авторизация и аутентификация могут проходить как одновременно, так и по отдельности. В первом случае при входе в админку у нас проверяется сразу как пароль, так и разрешение на переход в панель управления сайтом. Во втором случае авторизация проходит тогда, когда уже аутентифицированный пользователь пытается что-то изменить в системе.
А ещё наш сервер умный, и он знает, как реагировать на ошибки авторизации/аутентификации. У него есть два кода ошибок:
Если хакер доказал, что он — это мы, то система примет его с распростертыми объятиями. Злоумышленник получит доступ к информации и действиям, доступным только нам.
Самый простой способ помочь хакеру пройти авторизацию в системе — передать логин и пароль в запросе в незашифрованном виде. Ну и хранить информацию в cookie, конечно. Но мы не хотим помогать хакерам. Так что делать?
Есть ряд проверок, которые снижают вероятность взлома:
Также проверьте пользовательский доступ к ресурсам с кэшем страницы:
Доступ должен быть запрещён. То же самое проделайте при условии, что вы не просто вышли во второй вкладке, а зашли под другой учётной записью.
Проверьте также время жизни токенов в системе. Можно попросить разработчика поменять время жизни на 3 минуты, вместо 7 дней. Также можно попросить поменять время сервера. Но время жизни токена в любом случае должно быть ограничено.
Так же в некоторых системах с повышенными требованиями к безопасности можно применять дополнительные опциональные проверки. Первое, что мы можем сделать, так этоможно проверить авторизацию при смене пароля:
Тут мы проверяем, достаточно ли системе только сохранённых данных в cookie. При смене пароля все токены должны быть недействительными.
Второе: можно проверить наличие и работоспособность функции «Выход со всех устройств». При этом запросе мы говорим серверу, что аннулируем все действительные токены, кроме текущего.
Третье: проверьте наличие постоянного тайм-аута сессии (Session-Timeout), они бывают нескольких видов. Наличие постоянного тайм-аута запрещает доступ к ресурсу через n минут после авторизации. Наличие динамического тайм-аута запрещает доступ к ресурсу через n минут после последнего запроса. Другими словами, динамический тайм-аут закрывает доступ из-за вашего бездействия в системе.
И напоследок, не забудьте проверить, доступна ли двухфакторная аутентификация на сайте.
Если в вашей входной двери есть замок только одного типа, то грабителю нужна только одна отмычка (отмычка одного типа). Если же у вас есть ещё и дополнительная защита (цепочка, навесной замок, собака), то грабителю будет сложнее вас ограбить. Скорее всего он передумает.
Так работает и двухфакторная аутентификация. У нас есть основной замок — логин и пароль. И у нас есть второй тип защиты — чаще всего это код, приходящий по SMS, электронной почте или отображаемый в программе двухфакторной аутентификации (например, в Google Authenticator).
Ещё неплохой практикой является использование на сайте протокола oAuth2. Простыми словами, oAuth2 — это когда мы авторизуемся в одном сервисе с помощью другого. Например, когда регистрируемся/логинимся на сайте с помощью Gmail.
Схема примера работы oAuth2
Давайте немного углубимся через ещё одну аналогию. Допустим, мы работаем официантом в элитном ресторане. Гости периодически просят изменить состав блюд. Официант отмечает, какие изменения внести в меню.
Недобросовестный официант анализирует и понимает, что на кухне не раздумывая выполняют любой запрос. Поэтому можно внести свои собственные изменения в заказ и повара безоговорочно приготовят блюдо. И он пишет на очередном рецепте:
«ДОБАВИТЬ перец И УБРАТЬ сахар».
Вот и всё. Пранк удался. Но мы на стороне добра, так что вместо того, чтобы заменять заказ, мы проверим, как на кухне умеют фильтровать изменения. Как этим пользуются хакеры? SQL injection — это намеренное внесение в базу данных извне. В нашем примере, кухня — это база данных. SQL-запросы — заказы от официантов.
Если у базы данных нет фильтрации запросов, то злоумышленник может манипулировать данными: получать данные пользователей (в том числе логин и пароль), размещать файлы, заменять значения. Как же злоумышленник может отправлять такие запросы? Это можно сделать через параметры HTTP, добавив в адресной строке параметры:
Не углубляясь в то, как мы можем сами попробовать хакнуть свою базу данных, разберёмся в причинах уязвимости и посмотрим, как можно защититься.
Во-первых, в запросе должно быть экранирование спецсимволов — игнорирование исполняемым кодом спецсимволов, которые используются в синтаксисе языка программирования. Если один из спецсимволов пропал, то сервер воспринимает его, как часть команды — уязвимость есть.
Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка “Unknown column ‘4’ in ‘order clause’” говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.
Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций. Например, библиотека node-mysql для node.js.
XSS расшифровывается как “Cross-Site Scripting”. Эта уязвимость входит в список OWASP TOP-10. Её смысл в том, что злоумышленник принудительно внедряет JavaScript-код через инпут на сайте: в поле ввода «пушит» код, который сохраняется на странице. Впредь он будет исполняться каждый раз при вызове страницы. Это происходит потому, что на сайте отсутствует экранирование спец символов.
У хакера много вариантов воспользоваться этой уязвимостью: от отображения алерта (всплывающего окна) с рекламой до кражи cookie и редиректа на сайт-зеркало.
Не забывайте, что проверять наличие уязвимостей на чужом сайте по законодательству РФ (и многих других стран) запрещено. Это воспринимается, как попытка намеренного причинение вреда сайту. И что тогда делать?
После этого вводим в инпуты строку: “\\ “test” 😀 /?.&&*@#$%^*;
` 你好你怎 фыва.&%\ ’t_e_st’:sunglasses: “ — это универсальная проверка сразу на несколько кейсов. Если часть символов исчезла (например, в поле поиска) или не записалась в БД (если это поле имени пользователя при регистрации, например), то уязвимость есть. Все символы не должны восприниматься, как часть исполняемого поля.
В конце вводим скрипт или спецсимволы в окно фронтенда — вставляем прям в код сайта через dev tools в браузере.
Мы рассмотрели лишь несколько уязвимостей из множества существующих. Но это поможет войти в прекрасный мир тестирования безопасности. Чтобы ничего не забыть, мы с железными тестировщиками подготовили чеклист.
Думай, как хакер! Пытайся получить выгоду или навредить. Но только на своём проекте. Следи за новостями безопасности. Смотри реестр уязвимостей, читай статьи, которые пишут фирмы по обеспечению безопасности и мониторь новости про утечки данных. Обязательно пытайся разобраться в сути. И будь на стороне добра! 🙂