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% уверенным, что система по-настоящему обезопасена. Но можно быть уверенным в том, что процент несанкционированных проникновений, краж информации и потерь данных будет в разы меньше, чем у тех кто не проводил тестирования безопасности.
Тестирование безопасности
Что такое тестирование безопасности?
SECURITY TESTING — это тип тестирования программного обеспечения, который выявляет уязвимости, угрозы, риски в программном приложении и предотвращает злоумышленные атаки от злоумышленников. Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в программной системе, которые могут привести к потере информации, доходов, репутации со стороны сотрудников или посторонних лиц Организации.
Целью тестирования безопасности является выявление угроз в системе и оценка ее потенциальных уязвимостей, чтобы система не перестала функционировать или использовалась. Это также помогает в обнаружении всех возможных угроз безопасности в системе и помогает разработчикам в устранении этих проблем посредством кодирования.
В этом уроке вы узнаете
Типы тестирования безопасности:
Существует семь основных типов тестирования безопасности согласно руководству по методологии Open Source Security Testing. Они объясняются следующим образом:
Как сделать тестирование безопасности
Всегда соглашаются, что стоимость будет больше, если мы отложим тестирование безопасности после фазы внедрения программного обеспечения или после развертывания. Таким образом, необходимо задействовать тестирование безопасности в жизненном цикле SDLC на более ранних этапах.
Давайте посмотрим на соответствующие процессы безопасности, которые будут приняты для каждой фазы в SDLC
План испытаний должен включать
Примеры тестовых сценариев для тестирования безопасности:
Примеры тестовых сценариев, чтобы дать вам представление о тестах безопасности —
Security testing
По статистике, за последнюю пару лет число киберпреступлений, связанных с утечками информации и взломом различных приложений, как веб, так и мобильных, увеличилось на 27% и, примерно, треть организаций по всему миру столкнулась с кибератаками. Глядя на эту статистику, невольно задумываешься о тестировании безопасности, или же Security Testing. Security testing — это, фактически, отдельный мир внутри области тестирования программного обеспечения и на его изучение может потребоваться немалое количество времени. Цель этой статьи — познакомить Вас с наиболее популярными подходами к тестированию безопасности и дать общее представление о направлении, в котором нужно смотреть.
Если рассматривать по определению, то Security testing или тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным (звучит нагромождённо, не так ли?).
Если сказать простыми словами, то тестирование безопасности — это проверка программного продукта на наличие уязвимостей, которыми могут воспользоваться злоумышленники, чтобы получить доступ к закрытой информации или навредить продукту и его пользователям.
В наше время, деятельность практически любого предприятия так или иначе связана с применением ПО, требующего подключения к интернету, что позволяет существенно упростить и ускорить выполнение требуемой работы. Однако, именно всемирная сеть открывает путь злоумышленникам, которые хотят получить доступ к конфиденциальным данным пользователей и компании.
Программисты, естественно, готовят оборонительные рубежи и преграды, которые нужно преодолеть. Нам же, как тестировщикам, требуется поставить себя на место «плохих парней» и попытаться найти неплотно закрытую дверь. Это можно делать несколькими способами:
Для каждого из приведенных выше способов есть соответствующий вид атаки.
Далее, каждый вид будет рассмотрен немного подробнее.
Authorization Bypass
Самая маловероятная из уязвимостей, зачастую отсекаемая еще на стадии разработки. Но несмотря на это проверять такую возможность все же стоит, ведь иногда самые очевидные варианты проверок и оказываются верными.
Итак, какая же структура у подобных ошибок в безопасности? Все сводится к тому, что пользователь А может получить доступ к документам и данным пользователя Б. Допустим, есть реализация, где при просмотре своего профиля, содержащего конфиденциальную информацию, в URL страницы передается userID. В данном случае есть смысл попробовать подставить вместо своего userID номер другого пользователя. И если вы увидите его данные, значит вы нашли дефект.
Другими словами, например, есть некоторый сайт:
и ссылка на личный кабинет пользователя6
Если при подстановке другого номера id, например:
происходит вход в другую учетную запись, значит уязвимость обнаружена.
SQL and Code injection
Пожалуй, сейчас это самый распространенный способ взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.
Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.
В общих чертах поиск уязвимости с помощью SQL инъекций будет выглядеть следующим образом:
Форма входа в систему имеет 2 поля — имя и пароль. Обработка происходит в базе данных через выполнение SQL запроса:
WHERE Name = ‘tester’
AND Password = ‘testpass’;
Следует ввести корректное имя ’tester’, а в поле пароль ввести строку:
В итоге, если поле не имеет соответствующих валидаций или обработчиков данных, может вскрыться уязвимость, позволяющая войти в защищенную паролем систему, т.к. SQL запрос примет следующий вид:
WHERE Name = ‘tester’
AND Password = ‘testpass’ OR ‘1’ = ‘1’;
Условие ‘1’ = ‘1’ всегда будет истинным и поэтому SQL запрос всегда будет возвращать много значений.
Как было сказано ранее, SQL Injection — один из самых популярных подходов, как раз благодаря ему в 2019 году в украинской платформе по управлению IPTV/OTT-проектами Ministra TV обнаружена критическая уязвимость. Эксперты из CheckPoint нашли логическую уязвимость в функции авторизации платформы Ministra, которая выражается в неспособности подтверждения запроса, что позволяет удаленному злоумышленнику обойти авторизацию и выполнить SQL-инъекцию через отдельную уязвимость, которую в противном случае мог бы использовать лишь злоумышленник, прошедший авторизацию (полную версию можно посмотреть https://www.youtube.com/watch?v=jqXPePSefss).
XSS (Cross-Site Scripting)
Вкратце, XSS или CSS (Cross-site Scripting, аббревиатура, которая также означает Cascading Style Sheets — таблицы каскадных стилей) является довольно распространенной уязвимостью среди Web-приложений. XSS позволяет атакующему внедрить вредоносный код на страницу и отправить его обратно в браузер пользователя, где этот код будет выполнен. Причиной этому являются доверительные отношения разработчика приложения к входным данным или некорректная фильтрация входных данных.
Существует два типа XSS уязвимостей — пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости выглядит следующим образом:
Зачастую, в этом моменте вступает социальная инженерия, например, ссылка маскируется под важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме.
В этом году компания по информационной безопасности Sucuri сообщила, что обнаружила новый способ кражи денег с банковских карт, при котором пользователям в браузере загружают фейковую форму для ввода карточных данных притом, что ничего не подозревающий покупатель в адресной строке видит реальный адрес интернет-магазина. По их словам “Злоумышленники нашли в системе управления интернет-магазинами CMS Magento уязвимость, возникшую из-за некорректной фильтрации кода, которая позволяет провести атаку типа XSS.” При условии что CMS Magento пользуется чуть меньше 20% интернет-магазинов в мире, то уязвимость достаточно критичная.
XSRF / CSRF (Request Forgery)
Согласно Википедии XSRF / CSRF (Request Forgery) — это вид атак на посетителей веб-сайтов, использующий недостатки протокола HTTP. Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), осуществляющий некую вредоносную операцию (например, перевод денег на счёт злоумышленника).
Наиболее частыми CSRF атаками являются атаки использующие HTML тэг или Javascript объект image. Чаще всего атакующий добавляет необходимый код в электронное письмо или выкладывает на веб-сайт, таким образом, что при загрузке страницы осуществляется запрос, выполняющий вредоносный код.
Javascript объект Image
В 2017 году была обнаружена критическая уязвимость обхода аутентификации в одной из крупнейших платформ идентификации с сервисом Auth0, которая могла позволить злоумышленнику получить доступ к любому порталу или приложению, которые используют сервис Auth0 для аутентификации.
При тестировании приложения еще в сентябре 2017 года исследователи из охранной фирмы Cinta Infinita обнаружили недостаток ( CVE-2018–6873 ) в Auth0 Legacy Lock API, который связан с неправильной проверкой параметра аудитории JSON Web Tokens (JWT).
Исследователи успешно воспользовались этой проблемой, чтобы обойти аутентификацию при входе в систему с помощью простой подделки межсайтовых запросов (CSRF / XSRF) на приложения, работающие с аутентификацией Auth0. (саму атаку можно увидеть здесь: https://www.youtube.com/watch?v=9E7kfdGN1eY)
Распределенные сетевые атаки часто называются распределенными атаками типа «отказ в обслуживании» (Distributed Denial of Service, DDoS). Что же данная атака из себя представляет?
Представьте себе небольшой магазинчик с одеждой, который вмещает максимум 10–15 человек, в котором работает всего один продавец и охранник. Злоумышленники захотели ограбить этот магазин, подали объявление на популярном ресурсе, что у данного магазина будет распродажа со скидками в 99%, после чего в данный магазин приходит больше тысячи покупателей, среди которых есть и злоумышленники. Пока продавец и охранник не справляются с нагрузкой и не могут уследить за всеми покупателями разом, злоумышленники спокойно проходят под видом обычных покупателей и крадут одежду. Бизнес заходит в тупик.
Это и есть DDoS, или «распределенный отказ в обслуживании», который представляет собой злонамеренную сетевую атаку, в которой хакеры заставляют многочисленные устройства, подключенные к Интернету, отправлять запросы на сетевое соединение одному конкретному сервису или веб-сайту с целью подавления ложного трафика или запросов. Это приводит к тому, что все доступные ресурсы связываются с этими запросами, и происходит сбой веб-сервера или его отвлечение настолько, что обычные пользователи не могут создать соединение между своими системами и сервером.
Для проверки устойчивости на DDoS атаки можно воспользоваться The Low Orbit Ion Cannon (LOIC) или «Низкоорбитальная ионная пушка» Возможно самая популярная DDOS программа. Она может рассылать массовые запросы по протоколам ICMP, UDP тем самым забивая канал к серверу жертвы. Самая известная атака с помощью LOIC была совершена группой Anonymous в 2009 году и направлена против PayPal, Visa, MasterCard в отместку за отключение WikiLeaks от системы сбора пожертвований.
Атаки, организованные с помощью LOIC могут утилизироваться с помощью блокировки UDP и ICMP пакетов на сетевом оборудовании интернет провайдеров. Вы можете скачать саму программу LOIC бесплатно на сайте SourceForge. Этот инструмент на базе Windows и работа с ним очень проста, указываете сайты жертвы и нажимаете всего одну кнопку (не рекомендуется использовать дома).
Mobile and Client–server Security testing
Тестирование безопасности мобильных и клиент-серверных приложений стоит немного особняком, поскольку отличается подходом и инструментами от тестирования безопасности веб-приложений. В 2016 году OWASP (Open Web Application Security Project) составили финальную версию категорий уязвимостей для проверки подобных приложений. Список выглядит следующим образом:
Для проверки на уязвимости мобильных и клиент-серверных приложений зачастую используются сторонние программы, такие как Apktool (программа для распаковки apk-файлов, которая используется для локализации программного обеспечения, анализа структуры приложения), Drozer (фреймворк, который содержит инструменты, позволяющие искать уязвимости мобильных устройств и программ.) и т.д.
Заключение: Все вышеупомянутое является только верхушкой айсберга под названием Security testing. Углубляясь в данную область можно перечислить еще много видов атак и уязвимостей, на которые стоит обратить внимание. Но проверив хотя бы самые простые и часто встречающиеся виды атак можно добиться того, что злоумышленнику будет намного сложнее проникнуть в конфиденциальные данные проекта.
Security testing что это
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Тестирование безопасности — это отдельная область тестирования. О которой я почти ничего не знаю =)) Потому что область сложная. И если юзабилити, в принципе, может проверить даже джуниор, то в тестирование безопасности ему лучше не лезть. Потому что когда безопасность важна — то пропущенный баг стоит миллионы.
Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.
Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.
Если он найдет дыру в работе банкомата, то сможет снять оттуда все деньги при нулевом или минимальном балансе на карточке.
Если он найдет дыру в веб-приложении, то сможет войти под вашим логином-паролем. И если вы сохранили данные карточки, злоумышленник может их считать, купить что-то, или просто вывести деньги. Поэтому банки сейчас ограждаются от покупок добавлением двухфакторной авторизации — вы делаете покупку на сайте и подтверждаете ее кодом из смс.
Способы взлома
Полный перебор (или метод «грубой силы», англ. brute force) — это когда мы пытаемся подобрать данные, перебрав все возможные варианты.
Не секрет, что админский логин в линукс-системе часто идет с логином root. Это по умолчанию, а изменять так лень. Так что логин злоумышленнику известен. Остается подобрать пароль. Метод брутфорсинга — это тупо перепробовать все возможные комбинации. И чем умнее и быстрее становятся компьютеры, тем быстрее они перебирают варианты.
Думаете, что это все фигня и от этого давно есть защита? Пожалуйста, недавняя статья.
В результате выявления уязвимости веб-ресурса ликвидированного Бинбанка персональные данные граждан, направляемые кредитной организации при запросе на выдачу кредита или карты, оказались в открытом доступе, сообщает «Коммерсант».
В понедельник компания DeviceLock сообщила о выявленной утечке данных клиентов-физлиц, подававших заявки на получение кредитной карты Бинбанка «Эlixir», которые не находятся в открытом доступе, однако извлечь их можно методом подбора буквенно-цифровых сочетаний, поясняется в сообщении компании.
По словам основателя DeviceLock Ашота Оганесяна, в настоящее время известно, что уже найдено более 1 тыс. анкет, однако при помощи автоматизированного перебора возможно получить все заявки, а их могут быть десятки или даже сотни тысяч. Также велика вероятность подобных проблем и в других банках, использовавших то же решение для системы безопасности.
Как напомнил вице-президент группы компаний InfoWatch Рустем Хайретдинов, схожая публичная история была в 2015 году с банком «Санкт-Петербург», когда злоумышленники также получили доступ к данным клиентов, после чего банк пересмотрел свой взгляд на безопасность. Руководитель группы исследований безопасности банковских систем Positive Technologies Ярослав Бабин сообщил, что очевидно также отсутствие защиты от атаки перебором.
Ну а что, вполне может сработать, если админ не удосужился поставить нормальный пароль.
Когда я делала обучающие видосики и статьи по линуксу, то нашла облачный сервис, где можно взять в аренду линукс-сервер за 150р в месяц. И решила я для своей странички Test it купить такую машинку. Недорого же, почему бы и нет?
Оплатила сразу на несколько месяцев, создала тестового пользователя и радостно выставила в общий доступ. Потом, как ни зайду под рутом, вижу такого плана сообщения:
Last failed login: Mon Jul 16 04:24:25 MSK 2018 from 198.98.48.103 on ssh:notty
There were 120 failed login attempts since the last successful login.
Last login: Sun Jul 15 11:33:27 2018 from 37.187.143.213
120 попыток взлома. Вот, казалось бы, зачем? А чтобы навредить. Потому что даже из-под открытого пользователя навредить умудрялись. Поработает сервер пару дней и мне приходит письма от админов «От вас идут попытки взлома, мы погасили машину».
Переустановим с нуля, вроде пытаюсь огородиться, запреты ставлю на потенциально опасные команды (ssh например, чтобы не пытались взломать другие машины), но я ведь не тестировщик безопасности — они все равно путь найдут. И снова мою машину гасят.
Там админы какие-то вялые были, я им объясняю «это для открытого доступа, я сделала то и то, скажите как еще можно защититься», ноль эмоций. Сама думай. В итоге надоело и я перестала оплачивать сервер. Не знаю, может, снова подниму, но уже на другой платформе, где админы помогают, а не все на тебя перевешивают.
В любом случае, если вы где-то засветили IP-адрес, намеренно или нет, ждите атаки на рута, перебирать пароли для него в любом случае будут.
Вы отправляете какую-то информацию. Например, вводите в формочку входа свой логин и пароль. Эти данные клиент (браузер) передает серверу. Злоумышленник влезает на пути передачи данных и перехватывает сообщение. Так он получает данные для входа.
И всё, если у вас привязана карточка в приложении, злоумышленник получает к ней доступ. А если приложение открыто отправляет «денежные» данные, то это совсем фейл. Ведь сейчас есть куча платежных систем, которые обеспечивают безопасность. Если вы делаете свой сайт, подключите готовую систему, не делайте самописную на коленке — ее будет слишком легко взломать.
Это когда вы передаете вместо нормального параметра SQL-запрос. Если приложение уязвимо, можно сделать много плохого.
Самая типичная инъекция — ввести в поле одинарную кавычку и за ней какой-то запрос. Вот как на рисунке, только с паролем. Логин админа то обычно стандартный — admin или administrator, а в пароле пишем любой пароль, а потом «ИЛИ 1=1». Пароль не подошел, но 1 = 1, возвращается true → и вот мы уже вошли в систему!
Или вот знаменитая картинка-мем про инъекции:
Межсайтовый скриптинг — это когда вы внедряете в код страницы вредоносный код.
Например, у вас есть поле ввода — имя в профиле. Разработчик не защитил это поле и позволил вводить все, что угодно.
И вот я могу туда ввести:
Что в итоге? Как только я сохраню изменения, то увижу поп-ап с текстом «Я ТЕБЯ СЛОМАЛ АХАХА»
Если мы увидели поп-ап → поле не защищено. И вместо безвредного поп-апа можно внедрить правда плохой скрипт. Который утащит информацию, перенаправит реального пользователя на другой опасный сайт или что-то еще.
Поэтому можете использовать лайт проверку из примера выше с алертом. Если алерт вызвался — бейте тревогу. Ну а как можно навредить такими атаками — изучите в гугле =)
Так как я не умею взламывать, то и научить этому не могу. Про простые атаки знаю, но наверняка есть что-то более сложное и изощренное. Если интересует эта область — идите в тестирование безопасности, копайте и развивайтесь.
Хороший тестировщик безопасности и получает много. Рынок, правда, невелик. По крайней мере, требуются такие люди реже, чем простые тестировщики или автоматизаторы. Но хорошего с руками оторвут.
Истории взлома
Все ваши анализы в открытом доступе
Автор статьи рассказывает, как нашел логи с результатами анализов. Их можно прочитать в машинном виде, а можно получить PNG-файлы в удобном для чтения виде:
Этот автор не в первый раз пишет про уязвимость медицинских данных. Другие его статьи на эту тему:
Операции проводили с 15 по 19 мая 2018 года в банкоматах на железнодорожных вокзалах в Москве. Участники схемы выбирали опцию перевода денег с карт «Сбербанка» на карты «Тинькофф банка», но в последний момент отменяли операцию.
Мошенники выбирали опцию перевода, после чего направлялись запросы в банк отправителя и банк получателя для разрешения на списание и зачисление средств, объясняет эксперт по информационной безопасности банков Николай Пятиизбянцев, изучивший решение суда. Затем на экране банкомата появлялась информация о комиссии и предложение подтвердить перевод.
Ошибка в настройках заключалась в том, что банк — владелец банкомата считал, что операцию все ещё можно отменить, а банк получателя — что перевод уже отозвать нельзя. Мошенники отменяли операцию: сумма восстанавливалась на карте отправителя и одновременно проходил перевод. По правилам Mastercard для операций MoneySend банк получателя может не согласиться с отменой операции.