Библиотека тестировщика

Пентест по PTES: руководство по Metasploit от создателей индустрии


Пентестерам посвящается. Вы запустили готовый модуль, получили доступ к системе — и на этом все остановилось. Как понять, что вообще дает этот доступ? Через неделю выясняется, что ваш пэйлоад ловит антивирус заказчика, и вы не понимаете почему. А когда проект наконец доходит до облака, выясняется, что про побег из контейнера и атаки в AD вы знаете только обрывками из случайных статей или ответов нейросети. Узнаете свою работу? Читать далее

https://habr.com/ru/articles/1100698/?utm_campaign=1100698&utm_source=habrahabr&utm_medium=rss

Ваш recover() эту ошибку не поймает


В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes. При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map. Разобрать проблему

https://habr.com/ru/companies/otus/articles/1099260/?utm_campaign=1099260&utm_source=habrahabr&utm_medium=rss

Что происходит с сервисом, когда пользователей становится в 10 раз больше: реальные кейсы нагрузочного тестирования


Представим обычный интернет‑банк: пользователь открывает выписку, смотрит историю операций, переводит деньги, проверяет статус платежа. Всё работает корректно. Но если таких пользователей вдруг станет в десять раз больше, то нагрузка на CPU увеличится, база станет отвечать медленнее, а внешние зависимости могут не справиться с возросшим потоком трафика. Заранее предвидеть такие ситуации помогает нагрузочное тестирование. В статье расскажу про реальные случаи из практики, когда нагрузочные тесты помогли найти и устранить неочевидные проблемы. Читать далее

https://habr.com/ru/companies/tochka/articles/1101232/?utm_campaign=1101232&utm_source=habrahabr&utm_medium=rss

Что происходит с сервисом, когда пользователей становится в 10 раз больше: реальные кейсы нагрузочного тестирования


Представим обычный интернет‑банк: пользователь открывает выписку, смотрит историю операций, переводит деньги, проверяет статус платежа. Всё работает корректно. Но если таких пользователей вдруг станет в десять раз больше, то нагрузка на CPU увеличится, база станет отвечать медленнее, а внешние зависимости могут не справиться с возросшим потоком трафика. Заранее предвидеть такие ситуации помогает нагрузочное тестирование. В статье расскажу про реальные случаи из практики, когда нагрузочные тесты помогли найти и устранить неочевидные проблемы. Читать далее

https://habr.com/ru/companies/tochka/articles/1101232/?utm_campaign=1101232&utm_source=habrahabr&utm_medium=rss

Данные без противоречий: генерация через RegExp


Идея не новая. Генерировать строки по регулярке умеют randexp в JavaScript, Xeger в Java, exrex и Hypothesis в Python. В TDCV2 я добавил это тоже, и первая половина статьи будет знакома тем, кто ими пользовался. Своё начинается дальше: уникальность, которая заранее знает, хватит ли места; точные доли прямо внутри выражения; условие, при котором одна часть строки следует из другой. Последние две вещи живут в расширенном генераторе advanced_regex, и в таком виде я их больше нигде не встречал.И про слова. RegExp здесь - это синтаксис регулярных выражений, который TDCV2 использует как язык описания строки: конечное подмножество привычного синтаксиса плюс несколько своих конструкций. В конфиге генераторы называются regex и advanced_regex. Читать далее

https://habr.com/ru/articles/1101688/?utm_campaign=1101688&utm_source=habrahabr&utm_medium=rss

Chaos Engineering для тех, кто в гробу его видал


Всем привет! Я Лев Алимов, техлид платформы хаос-тестирования Storm. Моя работа считается хорошо выполненной, если где-то с моей помощью чей-то production прилег. Эта статья о том, как мы в T-Банке развивали Chaos Engineering, когда в него особо никто не верил.Расскажу про Chaos Engineering как практику, зачем она нужна, из каких шагов состоит. Приложу ее к разным уровням зрелости команд и компаний, покажу, на каких этапах она действительно нужна. В конце расскажу, как практика Chaos Engineering зарождалась в Т-Банке, что мы делали, чтобы этот маховик раскрутился, какую пользу от этого получаем и какие метрики считаем. Читать далее

https://habr.com/ru/companies/tbank/articles/1101626/?utm_campaign=1101626&utm_source=habrahabr&utm_medium=rss

Компьютер из пластмассы и пружинок: оцифровал руководство к «Детской логической машине» 1987 года и нашёл в нём ошибки


В феврале 1988 года мне, десятилетнему, купили «Детскую логическую машину». Хотя на коробке указан возраст: от 13 до 15 лет. В ней нет ни транзисторов, ни реле, ни микросхем, а только пластмассовые планки, штеккеры, пружинные контакты и четыре лампочки. И конечно батарейки.При этом её можно программировать. Времена были такие, и мы кодили на чём могли.Машина до нашего времени не дожила, поскольку в те годы я не только программировал, но и тестировал. Причём тестировал не всегда именно код. Да все так делали. А вот брошюра сохранилась в пыльных закромах антресолей, как напоминание о моих первых экспериментах в машинную логику.Полного текста этого руководства на просторах интернета (где по определению есть вообще всё) не обнаружилось ни мною, ни помощниками, ни шибко умными нейросетями. Видимо, день такой. Ищутся фото коробок, пара страниц инструкции в разных статьях, но не сам документ. Возможно, ДЛМ не снискала популярности или мало кто успел подержать её в руках и поклацать переключателями, любуясь на лампочки за цветными стёклышками, или это какой-то неизвестный мне заговор?В общем, дело было вечером, делать было нечего. Так что коробку вытащил, пыль сдул, поднял старенький сканер обрядом некромантии, да и занялся оцифровкой. Это было долго, но вайбово. Не рекомендую. Текст набрал заново, а по рисункам программ сделал эмулятор в браузере и проверил все программы перебором. Ну а что? Эмуляторы японских консолей в ассортименте, а вот чтобы наше советское, из пластика и лампочек - нету. Непорадок! Читать далее

https://habr.com/ru/articles/1101092/?utm_campaign=1101092&utm_source=habrahabr&utm_medium=rss

Каждый таксист теперь может попробовать поуправлять крупной корпорацией


Каждый таксист знает, как управлять страной, а заодно и “Роснефтью”: кого снять в правлении и что делать с ценой на нефть, он объяснит за одну поездку от аэропорта до центра. Проверить эти знания на деле ему было негде. Теперь и государство, и крупную корпорацию можно собрать из ИИ-агентов, и мы это сделали! Нет, не перешли работать в такси, а собрали Корпорацию Всевластия. А я таки сел за руль :) Читать далее

https://habr.com/ru/articles/1100858/?utm_campaign=1100858&utm_source=habrahabr&utm_medium=rss

KassiOS: слой в стиле Kaspresso поверх XCUITest, проверенный на сломанном банке


Я пришёл в нативное iOS-тестирование из Appium, и простой логин на XCUITest раз за разом обрастал waitForExistence, ретраями и самописными хелперами. Так появился KassiOS — слой в стиле Kaspresso поверх XCUITest: тап с общим бюджетом ожидания, который не повторяется после отправки, перечитывание поля после ввода, понятные сообщения о падениях, параметризованные тесты.Чтобы проверить, ловят ли тесты баги, я прогнал их против ChaosBank — приложения с включаемыми дефектами — и написал утилиту, которая включает дефекты по одному и показывает, какой из них прошёл незамеченным. Рассказываю, что из этого вышло, какие баги нашлись в самом фреймворке и кому он подойдёт, а кому нет. Читать далее

https://habr.com/ru/articles/1100796/?utm_campaign=1100796&utm_source=habrahabr&utm_medium=rss

Нагрузочное тестирование NDR: как проверить реальную производительность


Наша группа продуктовых исследований регулярно тестирует классические средства сетевой защиты информации — NGFW, IPS. Для этого существуют давно отработанные практики. Например, практически все методики проверки NGFW в зарубежных и отечественных компаниях опираются на стандарты RFC 9411 и RFC 2544 от Internet Engineering Task Force.К сожалению, с NDR всё иначе: открытых стандартов нагрузочного тестирования для этого класса СЗИ, кажется, просто не существует, а готовые сценарии от NGFW для них не совсем подходят. Поэтому мы разработали собственную методику и делимся ею с ИБ-сообществом.В этой статье мы не сравниваем конкретные NDR между собой и не доказываем, что один продукт «быстрее» другого. Цель другая: показать воспроизводимый подход к нагрузочному тестированию NDR. Материал пригодится инженерам ИБ, архитекторам SOC, специалистам по тестированию СЗИ, пресейлам и техлидам — всем, кому нужно получить реальные цифры устойчивости NDR под нагрузками, а не «маркетинговую» пропускную способность.Разберем, чем такое тестирование отличается от классических испытаний NGFW и IPS, как собрать стенд, какие метрики снимать на стороне самого NDR и почему недостаточно статистики генератора трафика. Покажем, как формулировать критерии прохождения теста и как отделять ограничения продукта от ограничений стенда. В конце покажем практический пример того, как методика помогает найти узкое место в производительности NDR.  Читать далее

https://habr.com/ru/companies/bastion/articles/1097820/?utm_campaign=1097820&utm_source=habrahabr&utm_medium=rss