Как сканировать API с аутентификацией по JWT? При наличии OpenAPI спецификации на сайте можно так:

docker run --rm -v $(pwd):/zap/wrk/:rw -m 4g -e ZAP_AUTH_HEADER=Authorization -e ZAP_AUTH_HEADER_VALUE="Bearer jwt_токен" -t zaproxy/zap-stable zap-api-scan.py -t https://rest.vulnweb.com/files/openapi-swagger_jwt.yaml -f openapi -g gen.conf

Значение JWT для rest.vulnweb.com вместе с тестом других методов аутентификации можно найти тут:

https://rest.vulnweb.com/docs/

GraphQL и SOAP также поддерживаются, передаются в значении параметра -f

https://www.zaproxy.org/docs/docker/api-scan/

Если есть желание сканировать код с PT AI, но нет возможности его купить, можно поставить бесплатное расширение для VS Code:

https://marketplace.visualstudio.com/items?itemName=POSIdev-community.application-inspector

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

Кстати, в начале года сравнивали полную версию PT AI с набором open source аналогов (Semgrep, Bandit, FindSecBugs, Security Code Scan и т.д.) под общим названием ScanSuite.

Сравнение субъективное, на полноту не претендует, результат тогда был в пользу open source.

На днях прошел SafeCode Meetup №2. Понравился доклад по безопасной настройке GitLab:

https://www.youtube.com/live/Hg5X5LIZP6E

Отличный курс по безопасности приложений и окружения:

https://www.youtube.com/playlist?list=PLQC2_0cDcSKD_JHWtEJGIFQUVh7Z5JM8E

Как просканировать сайт на CMS Bitrix на уязвимости?

Качаем шаблоны для Nuclei:

git clone https://github.com/jhonnybonny/nuclei-templates-bitrix.git

Сканируем:

docker run --rm -v $(pwd):/tmp -v $(pwd)/nuclei-templates-bitrix:/nuclei-templates projectdiscovery/nuclei -t /nuclei-templates -u https://example.com

вместо -u https://example.com можно указать файл с со списком сайтов через -l TARGETS.txt

В качестве бонуса, репа с эксплоитами: https://github.com/JackPot777/bitrix

Сканируем python код на уязвимости сканером Bandit. Из папки с исходниками запускаем:

docker run --rm -v "${PWD}:/src" ghcr.io/pycqa/bandit/bandit -r /src -f json -o /src/bandit.json

Есть ещё Semgrep, можно любой код сканировать, сам определяет языки и применяет правила:

docker run --rm -v "${PWD}:/src" returntocorp/semgrep semgrep --json -o semgrep.json

Вопрос что делать с json. Можно выгружать в Defect Dojo, ставится легко:

git clone https://github.com/DefectDojo/django-DefectDojo
cd django-DefectDojo && ./dc-up-d.sh postgres-redis

После установки получаем админский пароль:

docker compose logs initializer | grep "Admin password:"

Логинимся в веб консоль, создаем новый Product, в нем новый Engagement и далее выгружаем json, указав соответствующий тип теста.

Modsecurity WAF можно поднять быстро и бесплатно с неплохим набором правил, поддерживаемых owasp (https://owasp.org/www-project-modsecurity-core-rule-set/)

Например, есть уязвимый фронт на докере с именем flask, который слушает на порту 5000. Перед ним поднимаем modsecurity-crs:

docker run -dti --name modsecurity -p 80:80 -e PARANOIA=1 -e PROXY=1 -e BACKEND=https://flask:5000 owasp/modsecurity-crs:3.3.4-nginx-alpine-202304160904

Само собой можно настроить TLS с правильными сертификатами и другими плюшками.

Проверяем удаленный Linux сервер на соответствие лучшим практикам харденинга:

docker run --rm -v ~/.ssh:/root/.ssh -v $(pwd):/share hysnsec/inspec exec https://github.com/dev-sec/linux-baseline.git -t ssh://имя_sudo_юзера@удаленный_сервер -i ~/.ssh/id_rsa --chef-license accept --reporter json:/share/inspec-output.json

Предполагается, что id_rsa ключ лежит в ~/.ssh и уже добавлен в разрешенные на удаленном сервере.

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

Ссылки на учебные видео по вебу, если есть пробелы в понимании чек листа.

Позитивы выкатили свою версию методологии внедрения безопасной разработки AppSec Table Top. Документ объемный, включает многие аспекты DevSecOps, подробно описаны подходы и ключевые этапы.

Это далеко не первая попытка систематизировать процесс внедрения безопасной разработки, AppSec велосипеды изобретают в OWASP с их SAMM и BSIMM, есть хорошие их адаптации к российским реалиям в виде ГОСТа 56939 или фреймворка DAF от Джета.

В целом материала для внедрения достаточно, осталось выделить приоритетные направления и вкладываться в безопасность.

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

Рассказал про типы анализа, какие тулы использовать и что делать с результатами. Поговорили и про кастомизацию сканеров и написание своих Semgrep / Nuclei правил.

Где веб приложения хранят секреты пользователя после аутентификации? Куки это хорошо, но если надо больше?

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

В IndexedDB браузера. И что такого? Как выяснилось, браузеры Chrome, Edge и т.п. не шифруют свои хранилища, кроме Cookies. То есть ключи они просто там, в файлах.

В случае с IndexedDB на винде они лежат в %LocalAppData%\Google\Chrome\User Data\Default\IndexedDB.

Есть другие варианты хранилищ - Local Storage, Session Storage, там та же история.

Чем это грозит? Секреты можно выкачать малварью, эдакий макрос, который при открытии ворда отправит нужные файлы из известной папки на нужный сервер.

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

И вот ты уже участник секретного p2p сообщества. Или крипто кошеля.

Когда тестируете веб, смотрите где приложение хранит секреты, может быть интересно.

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

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

Защититься от таких атак очень сложно, почти все решения, что я видел можно обойти, зная как они работают. Чаще всего это комбинация из капч (тоже небесплатные), замедлений и блокировок. Последние часто приводят в блокировке реальных пользователей.

Эффективные решения по защите есть, но проще отказаться от СМС в пользу мейлов, OTP и т.п.

https://www.guardsquare.com/blog/how-android-malware-works

Всем привет и с Новым Годом!

Интересный вебинар по возможностям малвари для Android и методам защиты. Помогает для аргументации найденных уязвимостей мобильных приложений и в целом для понимания угроз.

Смотрим, ужасаемся, бежим отключать Accessibility в телефонах.

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

Это вызывает дискуссии между безопасниками и разработчиками, последние часто используют сторонние решения для хранения файлов, которые передают идентификаторы только через GET/URL, прикрутить к ним аутентификацию запросов сложно или невозможно. Например, почти все S3 хранилища такие, включая AWS, MinIO и т.д.

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

Но немногие знают про функцию проверки URLов, которая есть и включена по умолчанию во многих браузерах. В Chrome она называется Safe Browsing, в Edge Safesearch и т.п. По некоторой логике "подозрительные" ссылки автоматически направляются браузерами в Google, Microsoft, Яндекс и другим корпорациям добра для анализа ссылки на "вредоносность".

И да, часто это обычные ссылки на скачивание файлов, с секретными небрутабельными идентификаторами.

Проблема это или нет зависит от модели угроз, но как минимум это ещё один вектор утечки идентификаторов и аргумент в пользу аутентификации таких запросов.