Всем привет! Сейчас за окном осенние деньки 2024 года. Вещает Пройдаков Евгений. Сейчас я руковожу группой разработки среды исполнения языка eXtraction and Processing в R&D департаменте Positive Technologies.

Доменно специфичный язык eXtraction and Processing является важной частью движка поведенческого анализа, используемого в таких продуктах Positive Technologies, как MaxPatrol SIEM и PT ISIM. Сегодня хотелось представить вашему вниманию выжимку нашего R&D процесса в экспериментах с WebAssembly. Узнаем, что такое WebAssembly. Поймём, как его можно встроить в программный продукт. Коснёмся инструментов разработки и сред исполнения WebAssembly. А также в рамках одной статьи пройдём путь от постановки задачи до результатов по разработке среды исполнения для доменно специфичного языка программирования. Кроме того, мы разберем некоторые проблемы, которые могут появиться у вас при попытке собрать и отладить большой С++ проект под WebAssembly. Материал может быть особенно полезен тем, кто хочет использовать WebAssembly за пределами веб‑браузера.

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

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

Привет, меня зовут Олег Уланов (aka brain). Я занимаюсь пентестами веб-приложений и активно участвую в багбаунти, зарабатывая на чужих ошибках. Свой путь в наступательной безопасности я начал совсем недавно, но, несмотря на это, меньше чем за год мне удалось ворваться в топ-10 исследователей на Standoff Bug Bounty (сейчас я на 5-м месте — можете проверить 😉).

В своем дебютном посте кратко расскажу об уязвимости с подделкой запросов на стороне сервера (SSRF) и ее видах, покажу, как обнаруживать этот баг и почему его стоит искать даже на статических сайтах, а заодно подсвечу особенности работы с Burp Suite, Collaborator Everywhere и Wappalyzer. Статья будет полезна для прокачки скилов и поможет легче и быстрее обнаруживать SSRF в сервисах, размещенных на площадках багбаунти.

Мы живем в мире, где системы распознавания лиц (далее — CРЛ) используются практически везде: от валидации возраста и биометрической идентификации в режиме онлайн до наблюдения и проведения оплаты в реальном мире. Технологические аспекты таких алгоритмов развиваются на наших глазах: начиная с простых систем, основанных на базовых алгоритмах, мы перешли к системам, использующим алгоритмы машинного обучения, однако и их развитие еще далеко от завершения.

В предыдущих исследованиях мы затронули биометрическую идентификацию, и эта работа является логичным продолжением погружения в системы распознавания лиц и эксплуатацию их недостатков.

Привет, Хабр! Меня зовут Сергей, я техлид в команде PT BlackBox. Мы с коллегами разрабатываем продукт, который позволяет обнаруживать уязвимости в приложениях методом черного ящика. Фактически мы сами и пишем веб-приложения, и именно о них пойдет речь в статье.

Я бы хотел с вами поделиться своими наработками по теме бэкенд-приложений и предоставить вам шаблон-прототип, который, как мне кажется, может закрыть подавляющее большинство потребностей при их разработке.

Для написания прототипа я буду использовать Litestar, FastStream и dishka. Эта статья будет особенно полезна тем, кто пишет на Tornado, Django, Flask или AIOHTTP и хочет перейти на более актуальные технологии для дальнейшего развития своих проектов на современных рельсах.

Привет, Хабр. На пороге Новый год. Как всегда в конце года хочется понять, а чем же был для нас, компании Smart Engines, год уходящий? Продуктивным - да, и бизнес-результаты, и научные достижения, и технологии - как игрушки на елке - радуют. А где же игрушки - спросите вы и будете правы. Ведь один их сверкающий вид открывает двери празднику. А ниже они обязательно будут. Сегодня мы поделимся с вами нашим взглядом на 12 месяцев, а поможет в этом наш STE. Тот самый продукт для томографической реконструкции, над которым мы не устаем трудиться, дополняя, стабилизируя и запуская, как проходческий щит, в неосвоенные туннели условий томографической съемки.

Результат наших трудов покажем на томографии 12 объектов, каждый из которых символизирует один из 12 месяцев года. Да-да, интересная задача перед нами стояла в декабре - собрать 12 объектов, сфотографировать, сделать томографию и соорудить календарь из них. Кстати, и ты, дорогой читатель, можешь стать обладателем календаря от Smart Engines, но обо всем по порядку!

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

В нашем проекте PT Application Inspector реализовано несколько подходов к анализу исходного кода на различных языках программирования:

• поиск по сигнатурам;
• исследование свойств математических моделей, полученных в результате статической абстрактной интерпретации кода;
• динамический анализ развернутого приложения и верификация на нем результатов статического анализа.

Наш цикл статей посвящен структуре и принципам работы модуля сигнатурного поиска (PM, pattern matching). Преимущества такого анализатора — скорость работы, простота описания шаблонов и масштабируемость на другие языки. Среди недостатков можно выделить то, что модуль не в состоянии анализировать сложные уязвимости, требующие построения высокоуровневых моделей выполнения кода.

К разрабатываемому модулю были, в числе прочих, сформулированы следующие требования:

• поддержка нескольких языков программирования и простое добавление новых;
• поддержка анализа кода, содержащего синтаксические и семантические ошибки;
• возможность описания шаблонов на универсальном языке (DSL, domain specific language).

В нашем случае все шаблоны описывают какие-либо уязвимости или недостатки в исходном коде.

Весь процесс анализа кода может быть разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат;
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена первому этапу, а именно: парсингу, сравнению функциональных возможностей и особенностей различных парсеров, применению теории на практике на примере грамматик Java, PHP, PLSQL, TSQL и даже C#. Остальные этапы будут рассмотрены в следующих публикациях.