Оригинальная публикация Автор: Алексей Соловьев, Старший специалист группы анализа защищенности веб-приложений компании Positive Technologies
Компании могут проверять свои продукты, сервисы или инфраструктуру на реальность взлома разными способами: это и пентест (тестирование на проникновение), и редтиминг (Red Team, проверка возможностей компании по выявлению и предотвращению вторжения), и bug bounty (набор условий, в соответствии с которыми белые хакеры получают от организаций вознаграждение за уязвимости, найденные в их IT-сетях, системах и приложениях). Дыры в программном обеспечении могут обернуться убытками для компаний и компрометацией персональных данных (а иногда и финансовыми потерями) для пользователей.
В этой и следующих статьях мы подробно пройдемся по теме bug bounty и расскажем о том, как прокачаться в багхантинге веб- и мобильных приложений.
Для любого сервиса главное — это клиент. Когда он уходит, становится очень больно. Вдвойне больнее, если сервисом пользуются боты вместо реальных людей. Но понять это бывает не так просто, особенно если боты — нейросети.
Хотим поделиться кейсом по обеспечению двух важных условий на проекте — качества и безопасности. Мы подключились к проекту крупного сервиса, внутри которого команда разрабатывала модуль авторизации и личный кабинет пользователей. От наших специалистов требовалось помочь с разбором бэклога и сокращением техдолга. Эта задача превратилась в увлекательное расследование — в итоге нам удалось распутать большой узел связанных проблем, которые начинались с несоответствий в логах. Забегая вперед — это были и разлогины пользователей, и запросы на восстановление доступа, брутфорс паролей, а главное — ботовая активность. А все вместе это влияло на общую доступность сервиса, и, соответственно, экономическую эффективность проекта. Поэтому было важно обнаружить и устранить корень проблемы, а не только последствия.
Материал будет полезен QA-специалистам, аналитикам, лидам и project-менеджерам.
Автор: Маарет Пюхяярве (Maaret Pyhäjärvi) Оригинал статьи Перевод: Ольга Алифанова
На этой неделе, когда я начинала программу чемпионов BrowserStack со встречей участников вокруг костра-чата, что-то в разговоре о рабочих делах нажало во мне невидимую кнопку. Мы говорили о тестировании безопасности так, как будто это нечто новое и отдельное. На работе за безопасность у нас отвечают специальные люди, и годы опыта показали мне, что многие ожидают и подразумевают, что тестировщики мало знают о безопасности.
Подход фаззинг-тестирования родился еще в 80-х годах прошлого века. В некоторых языках он используется давно и плодотворно — соответственно, уже успел занять свою нишу. Сторонние фаззеры для Go были доступны и ранее, но в Go 1.18 появился стандартный. Мы в «Лаборатории Касперского» уже успели его пощупать и тестируем с его помощью довольно большой самостоятельный сервис.
Меня зовут Владимир Романько, я — Development Team Lead, и именно моя команда фаззит баги на Go. В этой статье я расскажу про историю фаззинга, про то, где и как искать баги, а также как помочь фаззинг-тестам эффективнее находить их в самых неожиданных местах. И покажу этот подход на примере обнаружения SQL-инъекций.
Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. При создании списка проверок мы попросили помощи у команды информационной безопасности, отдельная благодарность Дмитрию Терёшину за проведённую встречу с подробным разбором всех кейсов. Его интересную статью по работе утилиты CheckKarlMarx можно увидеть здесь.
В конце концов получили из кейсов самые опасные области атак на приложение с точки зрения безопасности, взяли high-сценарии и добавили их к себе в список чек-листов для регрессионного тестирования. Так родилась идея рассказать в статье, что популярного и интересного можно добавить в список кейсов для регресса в любой компании.
Речь пойдет о том, какие проверки безопасности и какие кейсы мы советуем добавить при регрессионном тестировании. Проверки, описанные в этой статье, — это не все проверки, которые проводятся у нас, их, конечно же, больше, но рассказывать обо всех проверках небезопасно, поэтому тут всего лишь небольшая их часть, которую следует учитывать при тестировании безопасности приложения. Также не забываем о документах о неразглашении определенных данных.
Тестирование безопасности — это отдельная область тестирования. О которой я почти ничего не знаю =)) Потому что область сложная. И если юзабилити, в принципе, может проверить даже джуниор, то в тестирование безопасности ему лучше не лезть. Потому что когда безопасность важна — то пропущенный баг стоит миллионы.
Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.
Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.
Если он найдет дыру в работе банкомата, то сможет снять оттуда все деньги при нулевом или минимальном балансе на карточке.
Если он найдет дыру в веб-приложении, то сможет войти под вашим логином-паролем. И если вы сохранили данные карточки, злоумышленник может их считать, купить что-то, или просто вывести деньги. Поэтому банки сейчас ограждаются от покупок добавлением двухфакторной авторизации — вы делаете покупку на сайте и подтверждаете ее кодом из смс.
Даже далекие от тестирования безопасности тестировщики иногда сталкиваются с необходимостью проверить сайт на уязвимость к атакам типа Cross-Site Scripting, или XSS. Во время такой атаки на атакуемом сайте воспроизводится скрипт, который передает важные данные злоумышленнику или изменяет какие-то параметры на сайте. Теоретические основы работы с XSS уже рассматривались в одном из видео, а в этом ролике тренер Арсений Батыров на наглядном примере показывает, как выглядит XSS и как ее найти. Для наглядности был создан отдельный общедоступный сайт-песочница, и вы можете сами попробовать найти на нем подобные уязвимости.
А если вы хотите более подробно узнать про XSS и другие уязвимости — приходите на курс Тестирование безопасности, а кроме того у тренера этого курса Арсения Батырова намечаются акции в честь дня знаний.
Що вищий ваш персональний кредитний рейтинг, то більше шансів отримати кредит на вигідних умовах - на більший термін, на більшу суму, за нижчою ставкою. сумлінно їх гасив, показник його кредитного навантаження і деякі інші параметри.
Кожному позичальнику присвоюється свій "колір" рейтингу залежно від рівня кредитоспроможності. ПКР - від 1 до 596 балів червоний колір і найнижчі шанси отримати кредит онлайн на карту. Жовтий колір показує середню якість кредитоспроможності позичальників - їхній рейтинг від 597 до 824 балів. Світло-зелений колір позначає високу якість позичальників з персональним кредитним рейтингом 825 - 941 бала. І, нарешті, дуже висока якість кредитоспроможності позичальника позначається яскраво-зеленим кольором і відповідає рейтингу 942 - 999 балів.
По моему наблюдению довольно много тестировщиков когда-либо слышали такое понятие, как XSS-уязвимость. Но мало кто может просто и на пальцах рассказать на собеседовании про нее. Или эффективно проверить веб-сайт на наличие этой уязвимости. Давайте вместе разберемся со всем этим подробнее и попробуем сами найти XSS-уязвимость на демо-странице, которую я специально подготовил к этой статье. :)
