Исследование SpecterOps "Certified Pre-Owned", посвященное злоупотреблению службами сертификатов Active Directory (AD CS), еще больше облегчило белым хакерам получение привилегий администратора домена во время проведения внутренних пентестов.
Независимо от того, какой это проект, организация или подход, всегда найдется место для документации. Хорошая документация — это находка, предоставляющая полезную информацию о подходах, масштабах, планах, конструкциях и результатах анализа, разработки и тестирования.
Этот парень открыл все турникеты на станции. Вы до сих пор считаете, что все хакеры вредны?
Начну с простого вопроса: кто из вас пользуется общественным транспортом? А кому нравится за него платить? Если такие все же найдутся, то могут смело переставать читать статью. Для остальных у меня есть рассказ о том, как четверо старшеклассников из Массачусетса взломали местную транспортную систему.
Жителям Бостона статья поможет получить бесплатные поездки, а для всех остальных этот материал будет неплохим уроком по реверс-инжинирингу. Ну или, по крайней мере, вы узнаете любопытную историю.
Для реверсера, пывнера и бинари ресерчера очень важно уметь фаззить, поэтому данные статьи посвященны новичкам, которые только начинают фаззить и знакомятся со зверьком - AFL++.
Фаззинг (fuzzing) — техника тестирования программного обеспечения, часто автоматическая или полуавтоматическая, заключающаяся в передаче приложению на вход неправильных, неожиданных или случайных данных. Предметом интереса являются падения и зависания, нарушения внутренней логики и проверок в коде приложения, утечки памяти, вызванные такими данными на входе. Фаззинг является разновидностью выборочного тестирования, часто используемого для проверки проблем безопасности в программном обеспечении и компьютерных системах. (Wikipedia)
Упражнение 1 - Xpdf
В этом упражнении мы проведем фаззинг просмотрщика Xpdf PDF. Цель - найти сбой для CVE-2019-13288 в XPDF 3.02.
Чему вы научитесь
После выполнения этого упражнения вы будете знать основы фаззинга с помощью AFL
О чем вы думаете, когда слышите слово «фаззинг»? Одни вспоминают о приказе ФСТЭК России № 239, другие — об утилитах с пугающими отчетами, а кто-то и вовсе озадаченно пожимает плечами. Рассказываем, для чего нужен фаззинг, зачем его применять и каким он бывает.
Навигация по статье:
• Ввод понятия
• Подходы к тестированию (White/Black/Grey Box)
• Необходимость проведения
• Ограничения в выборе
• Международные практики
• Вместо заключения
• Для статистики
Ввод понятия
В ГОСТ 58142 «Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Часть 2. Тестирование проникновения» есть следующее определение: «фаззинг — это тестирование, использующее как корректные, так и случайные (включая некорректные) входные данные для проверки, устанавливающей, обрабатываются ли должным образом интерфейсом случайные входные данные или возникает ошибочная ситуация (ошибочное условие), указывающая (указывающее) на наличие недостатков при разработке (ошибки исходного кода) или при эксплуатации».
Если проще, то фаззинг — это проверка на то, могут ли при обработке случайных, в том числе некорректных, входных данных некоторыми частями софта возникнуть «странности» в поведении ПО, которые разработчики не закладывали в его функционал.
Из определений ясно, что фаззинг позволяет обнаружить ошибки сразу на нескольких стадиях жизненного цикла программного средства: разработки и применения. Неужели этот метод настолько универсален?
Раз в месяц я и команда QA Studio вручную собираем статистику по вакансиям и резюме тестировщиков с нескольких ресурсов. Сегодня — статистика за октябрь. Мы не делаем выводы, а оставляем сухие цифры. Много или мало открытых вакансий и что с рынком — каждый может интерпретировать по-своему.
Предупреждаем о возможных подводных камнях, с которыми рискует столкнуться начинающий тестировщик на разных этапах.
Меня зовут Александр, я - QA-специалист в TELE2. Эту статью я начал писать, когда проходил стажировку в компании, а когда заканчивал, меня приняли в штат. Моя история уникальна, как и история любого другого человека, и я решил поделиться своим опытом прежде всего с ребятами, которые тоже задумываются о переходе в ИТ из других сфер или находятся в поиске стажировки. На каждом этапе своего пути я рефлексировал и задавал себе кучу вопросов. Возможно, кто-то сможет применить мои чек-листы для того, чтобы лучше понять себя и свои потребности при переходе в ИТ-сферу.
Сегодня расскажу, как можно протестировать свою ИТ-инфраструктуру или приложение на предмет устойчивости к DDoS-атакам на уровнях L4 и L7. Сразу скажу, что это нельзя назвать серьезным нагрузочным тестированием, это простой и бесплатный метод теста. У него две задачи:
1. Узнать, какой минимальной мощности достаточно, чтобы инфраструктура начала испытывать проблемы или легла вовсе. Это то, что тестировали мы.
2. Эту же методику можно использовать, чтобы оценить скорость реакции используемого сервиса защиты от DDoS-атак. Мы конечно же не будем пытаться заддосить с одной машины мощные узлы фильтрации anti-ddos-сервисов. Но посмотрим, как быстро срабатывает защита и начинает блокировать зловредный трафик, для всех ли типов атак это происходит одинаково быстро и происходит ли вообще?
Привет-привет!
Рад видеть тебя здесь!
Если ты, как начинающий IT специалист, интересуешься тем, как курсы по тестированию могут помочь получить новые знания, то держись крепче. Мы разберем, почему сейчас бум курсов, разберем с какой проблемой вы можете столкнуться, рассмотрим их решения.
Так что, пристегни ремни безопасности, потому что мы отправляемся в захватывающее путешествие по миру IT-образования и тестирования!
В чем ценность QA-метрик? Есть ли смысл тратить усилия на измерение, анализ, проверку, а затем на принятие действий в соответствии с полученными результатами? Тип и необходимость QA-метрик изменились с популярностью и широким распространением методологии разработки программного обеспечения Agile.
Лучшие QA-метрики обеспечивают реальную ценность для бизнеса и стимулируют изменения, которые улучшают качество обслуживания клиентов за счет повышения качества выпускаемых приложений.
Привет! Меня зовут Сергей, я технический эксперт в компании Bercut. Когда-то увлекался Delphi и J2ME, издал несколько книг на эти темы, а сейчас создаю высоконагруженные приложения для баз данных.
Первой СУБД, с которой я познакомился — случилось это в далеком 2002 году, — была PostgreSQL. Тогда я, студент 4-го курса ТИУ, должен был разработать систему электронного документооборота для университета. Система представляла собой WEB-приложение, написанное на языке C, работающее на сервере под ОС UNIX и хранящее информацию в PostgreSQL. С тех пор мое основное поле деятельности - базы данных. А PostgreSQL стала одной из самых популярных СУБД в мире.
В Bercut мы занимаемся разработкой и развитием IT-продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24x7x365 в режиме онлайн сотни миллионов абонентов по всему миру.
Сегодня мы обсудим, как создавать максимально качественное ПО, содержащее в себе минимальное количество ошибок. Такое ПО, что ошибки никак не проявляются и потому можно считать, что их нет совсем.
Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.
Сегодня хотим рассказать о том, как нам в YouTravel.me удалось снизить количество дефектов в 30 раз — с 400 до 13 — менее чем за полгода. Для наглядности — вот как выглядит это на графике:
То, что всё это мы упоминали на нашем ежегодном митапе для QA-специалистов — Bugs Busters. 😉 Было много интересного:
• Мы искали злодея, из-за которого произошла деградация времени обработки очереди — после того, как переключили режим работы пула.
• Разбирались с создателем Allure Reports, чем покрытие требований лучше покрытия кода и как визуализировать автотесты.
• Выясняли, сколько нужно автотестов и почему 100-процентное покрытие — это не всегда хорошо.
Скорее под кат, чтобы посмотреть доклады и пополнить копилку знаний обо всех видах тестовых покрытий. 😎
В этой статье я попытался придать систематический вид основным видам тестирования, которые я нашел в различных источниках. Идея для этой статьи зародилась у меня, когда я обнаружил, что в интернете существует множество разнообразных классификаций, и многие отличаются друг от друга. Вначале я начал это исследование для себя, но затем решил поделиться результатами со всеми, надеясь, что оно пригодится другим, как и мне.
Уже два года я работаю специалистом по тестированию, и многие коллеги меня поймут — одна из самых ненавистных и рутинных задач — это написание тестовой документации. И конечно я цепляюсь за каждую, даже самую маленькую возможность автоматизировать этот процесс. И в этой статье я хотел бы рассказать вам о том, как я автоматизировал написание отчета по релизу используя версионность гита и интеграцию с Jira. Очень надеюсь что моя задумка сможет помочь вам в работе, а более опытные коллеги смогу предложить дополнительные доработки и оптимизации моего решения.
И так. Началось все с достаточно невинной просьбы архитектора моего проекта — «Денчик, смотри, нужно взять все задачи, сделанные в этом спринте — то есть с версии 0.0.1.01 до версии 0.0.2.01 и выписать в статью».
Приветствую вас, кулхацкеры. Сегодняшний райт будет посвящен прохождению машины с HackTheBox под названием Authority.
Год назад мы выпустили «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя их качество и смысл. То есть гендерный баланс; социально‑демографическую структуру; родственные связи; страну и оператора в телефоне; валидность паспортов, ИНН, СНИЛС. В общем, «Маскировщик» делает так, чтобы вы тестировали продукты и обучали ML‑модели будто бы на «живых» ПД.
В этой статье пролью свет на методы изменения состава и семантики, которые использует продукт. Для простоты буду называть их «алгоритмами маскирования». Расскажу, по какой логике меняем одни данные другими, какие ограничения и как учитываем.
POV: Вы только что начали работать над новым проектом и встретились с небольшой проблемой — в бэклоге багов обнаружилось 300+ открытых тасок. Первая реакция — недоумение, отчаяние и боль от увиденного. «Ну ничего, – думаете вы, – это же как раз то, зачем я нужен этой компании, сейчас я им всё пофикшу!».
Моя статья как раз об этом — как разобраться в баговой каше и преобразить её в автоматизированный и легко понимаемый бэклог, куда девать древние баги, что делать с приоритетами, и как держать в курсе всех заинтересованных.
