Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

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

Всем привет! На связи Юрий Шабалин, генеральный директор «Стингрей Технолоджиз». Вообще я сторонник технических материалов, статей с примерами кода или разбором технологий, но сегодня речь пойдет о другом. Меня всегда интересовало, почему в требованиях регуляторов в области ИБ не указываются проверки мобильных приложений на соответствие государственным стандартам или федеральным законам. И вот недавно, изучая материалы документа по сертификации процесса безопасной разработки, я наткнулся на упоминание мобильной составляющей, что, конечно, вызвало у меня интерес и желание разобраться. Если вы тоже хотите понять, каким образом приложения упоминаются в Профиле защиты Банка России, и какие проверки необходимо осуществлять, чтобы ему соответствовать, приглашаю погрузиться со мной в этот увлекательный мир.

Оригинальная публикация
Автор: Алексей Соловьев, Старший специалист группы анализа защищенности веб-приложений компании Positive Technologies

Компании могут проверять свои продукты, сервисы или инфраструктуру на реальность взлома разными способами: это и пентест (тестирование на проникновение), и редтиминг (Red Team, проверка возможностей компании по выявлению и предотвращению вторжения), и bug bounty (набор условий, в соответствии с которыми белые хакеры получают от организаций вознаграждение за уязвимости, найденные в их IT-сетях, системах и приложениях). Дыры в программном обеспечении могут обернуться убытками для компаний и компрометацией персональных данных (а иногда и финансовыми потерями) для пользователей.

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

Автор: компания Simbirsoft

Для любого сервиса главное — это клиент. Когда он уходит, становится очень больно. Вдвойне больнее, если сервисом пользуются боты вместо реальных людей. Но понять это бывает не так просто, особенно если боты — нейросети.

Хотим поделиться кейсом по обеспечению двух важных условий на проекте — качества и безопасности. Мы подключились к проекту крупного сервиса, внутри которого команда разрабатывала модуль авторизации и личный кабинет пользователей. От наших специалистов требовалось помочь с разбором бэклога и сокращением техдолга. Эта задача превратилась в увлекательное расследование — в итоге нам удалось распутать большой узел связанных проблем, которые начинались с несоответствий в логах. Забегая вперед — это были и разлогины пользователей, и запросы на восстановление доступа, брутфорс паролей, а главное — ботовая активность. А все вместе это влияло на общую доступность сервиса, и, соответственно, экономическую эффективность проекта. Поэтому было важно обнаружить и устранить корень проблемы, а не только последствия.  

Материал будет полезен QA-специалистам, аналитикам, лидам и project-менеджерам.

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Подход фаззинг-тестирования родился еще в 80-х годах прошлого века. В некоторых языках он используется давно и плодотворно — соответственно, уже успел занять свою нишу. Сторонние фаззеры для Go были доступны и ранее, но в Go 1.18 появился стандартный. Мы в «Лаборатории Касперского» уже успели его пощупать и тестируем с его помощью довольно большой самостоятельный сервис.

Меня зовут Владимир Романько, я — Development Team Lead, и именно моя команда фаззит баги на Go. В этой статье я расскажу про историю фаззинга, про то, где и как искать баги, а также как помочь фаззинг-тестам эффективнее находить их в самых неожиданных местах. И покажу этот подход на примере обнаружения SQL-инъекций.

Оригинальная публикация

Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. При создании списка проверок мы попросили помощи у команды информационной безопасности, отдельная благодарность Дмитрию Терёшину за проведённую встречу с подробным разбором всех кейсов. Его интересную статью по работе утилиты CheckKarlMarx можно увидеть здесь.

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

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

Автор: Ольга Назина (Киселёва)

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

Насколько безопасно ваше ПО? Легко ли его взломать? Это очень важный вопрос, если приложение работает с персональными данными или деньгами.

Периодически всплывают сайты из серии «введи свой емейл и мы скажем твой пароль, ведь мы взломали большую базу, аха-ха». Если ваш пароль и правда взломали — значит, злоумышленник обнаружил дыру в безопасности.

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

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

Автор: Хан Тоан Лим (Han Toan Lim)
Оригинал статьи
Перевод: Ольга Алифанова

Допустим, я отправляю своего ребенка в магазин со списком покупок. Затем я забираю все купленное и сдачу. Как мне узнать, что все прошло как следует?

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

Наилучшим способом будет посмотреть на чек, на деньги и на купленные предметы. В этом вся суть аудита.