Подход фаззинг-тестирования родился еще в 80-х годах прошлого века. В некоторых языках он используется давно и плодотворно — соответственно, уже успел занять свою нишу. Сторонние фаззеры для Go были доступны и ранее, но в Go 1.18 появился стандартный. Мы в «Лаборатории Касперского» уже успели его пощупать и тестируем с его помощью довольно большой самостоятельный сервис.
Меня зовут Владимир Романько, я — Development Team Lead, и именно моя команда фаззит баги на Go. В этой статье я расскажу про историю фаззинга, про то, где и как искать баги, а также как помочь фаззинг-тестам эффективнее находить их в самых неожиданных местах. И покажу этот подход на примере обнаружения SQL-инъекций.
Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. При создании списка проверок мы попросили помощи у команды информационной безопасности, отдельная благодарность Дмитрию Терёшину за проведённую встречу с подробным разбором всех кейсов. Его интересную статью по работе утилиты CheckKarlMarx можно увидеть здесь.
В конце концов получили из кейсов самые опасные области атак на приложение с точки зрения безопасности, взяли high-сценарии и добавили их к себе в список чек-листов для регрессионного тестирования. Так родилась идея рассказать в статье, что популярного и интересного можно добавить в список кейсов для регресса в любой компании.
Речь пойдет о том, какие проверки безопасности и какие кейсы мы советуем добавить при регрессионном тестировании. Проверки, описанные в этой статье, — это не все проверки, которые проводятся у нас, их, конечно же, больше, но рассказывать обо всех проверках небезопасно, поэтому тут всего лишь небольшая их часть, которую следует учитывать при тестировании безопасности приложения. Также не забываем о документах о неразглашении определенных данных.
Тестирование безопасности — это отдельная область тестирования. О которой я почти ничего не знаю =)) Потому что область сложная. И если юзабилити, в принципе, может проверить даже джуниор, то в тестирование безопасности ему лучше не лезть. Потому что когда безопасность важна — то пропущенный баг стоит миллионы.
Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.
Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.
Если он найдет дыру в работе банкомата, то сможет снять оттуда все деньги при нулевом или минимальном балансе на карточке.
Если он найдет дыру в веб-приложении, то сможет войти под вашим логином-паролем. И если вы сохранили данные карточки, злоумышленник может их считать, купить что-то, или просто вывести деньги. Поэтому банки сейчас ограждаются от покупок добавлением двухфакторной авторизации — вы делаете покупку на сайте и подтверждаете ее кодом из смс.
Даже далекие от тестирования безопасности тестировщики иногда сталкиваются с необходимостью проверить сайт на уязвимость к атакам типа Cross-Site Scripting, или XSS. Во время такой атаки на атакуемом сайте воспроизводится скрипт, который передает важные данные злоумышленнику или изменяет какие-то параметры на сайте. Теоретические основы работы с XSS уже рассматривались в одном из видео, а в этом ролике тренер Арсений Батыров на наглядном примере показывает, как выглядит XSS и как ее найти. Для наглядности был создан отдельный общедоступный сайт-песочница, и вы можете сами попробовать найти на нем подобные уязвимости.
А если вы хотите более подробно узнать про XSS и другие уязвимости — приходите на курс Тестирование безопасности, а кроме того у тренера этого курса Арсения Батырова намечаются акции в честь дня знаний.
По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье. :)
Недостаток защиты от XSS путем использования только безопасного обращения со вводом в том, что даже единичный отказ безопасности может скомпрометировать ваш сайт. Недавно созданный стандарт под названием "Политика защиты содержимого" позволяет снизить этот риск.
CSP используется для ограничения возможностей браузера по просмотру вашей страницы: он может пользоваться только полученными из безопасных источников ресурсами. Ресурс – это скрипт, таблица стилей, изображение, или любой иной тип файла, на который ссылается страница. Это означает, что даже если злоумышленник преуспеет во внедрении вредоносного кода в ваш сайт, CSP не даст этому коду выполниться.
Автор: Амит Кулкарни (Amit Kulkarni) Оригинал статьи Перевод: Ольга Алифанова
Автоматизированное тестирование безопасности с ZAP API может помочь найти уязвимости на ранних стадиях. Инструмент безопасности и API, который тут используется – это OWASP ZAP. OWASP ZAP поможет автоматизировать тесты безопасности для включения их в непрерывную интеграцию/непрерывную поставку (CI/CD) для вашего приложения с использованием существующих функциональных регресс-наборов и ZAP Python API.
Ознакомьтесь с секцией "ссылки", чтобы узнать больше.
Тестирование безопасности — одна из наиболее популярных тем для изучения тестировщиками. Чаще всего на собеседованиях задают вопросы про XSS и SQL-инъекции. Многие профессионалы слышали об этих терминах, но считают тестирование безопасности (и поиск инъекций в частности) слишком сложным навыком.
В этом видео Арсений Батыров рассказывает, что такое XSS-инъекция, как она работает, причем тут cookie и как ее применить на примере работы с сайтом-песочницей:
Это фрагмент нового курса Арсения Батырова “Тестирование безопасности”, в котором разбираются различные уязвимости в клиент-серверных приложениях, методы их поиска и защиты.
Записывайтесь на курс, обычно первый поток самый массовый и интересный, на нем больше общения между участниками!!!
Другие видео тренера вы можете увидеть на youtube-канале.
