Зачем использовать NotHoly для безопасности web и API

Тестирование web и API это чтение: запрос, ответ, bundle JavaScript, spec OpenAPI, а затем написание следующего запроса, который доказывает баг. Обычная модель мнётся в тот миг, когда вы просите строку инъекции или bypass auth, а scanner находит поверхностное и останавливается. NotHoly читает то, что вы вставляете, пишет тест и оставляет отправку вашему proxy. Вы оставляете Burp, Caido, ZAP или свои скрипты; модель это читатель и писатель в цикле. Сценарий pentest содержит методологию; здесь о том, почему модель подходит работе с web и API.

#Вставьте запрос, ответ или spec

Дайте модели сырой HTTP, ответ, который выглядит неправильно, кусок bundle или документ OpenAPI, и она называет, чего не хватает: ссылку на объект без проверки владельца, endpoint, доверяющий роли со стороны клиента, параметр, доходящий до query без экранирования, token, который не валидируется. Она объясняет почему и отмечает запрос, который слать следующим. Вставьте ответ со странным header или утечкой в ошибке, и она скажет, что это раскрывает и как на это надавить. Раз модель не отказывает в задаче, обход IDOR, проба SQL injection или тест на путаницу JWT пишутся как любой другой код, пока цель в вашем scope. Reasoning проходит, так что многошаговый поток auth решается до того, как написан payload.

#Payload и проверки для вашего proxy

Попросите артефакт, который использует ваш инструмент, и модель его пишет: Bambda или BCheck для Burp, workflow для Caido, tamper-скрипт sqlmap, логику для прогона ffuf, маленький скрипт requests. База знаний это часть модели, так что она подтягивает OWASP WSTG, API Security Top 10, Cheat Sheet Series и документацию инструментов Caido и Burp с источником и лицензией на каждом фрагменте. Версия framework, которую вы находите, идёт в lookup CVE с CVSS, EPSS и KEV, а зависимость в запрос advisory, ни то, ни другое не стоит токенов. Результат это payload с причиной и ссылкой, а не догадка. Вы также держите весь поток в одной беседе, от первого странного ответа до готового теста, так что контекст, объясняющий, почему payload работает, не теряется между вкладками.

cat request.http | notholy "what auth checks is this endpoint missing, and write a Caido test for the IDOR"

#Трафик остаётся вашим

Серверы NotHoly никогда не сканируют, не зондируют и не шлют payload к цели. Запросы, которые тестируют приложение, идут от вашего proxy и ваших скриптов, с вашей машины, с вашего адреса. Когда вы ведёте из терминала, notholy engage записывает scope, которого вам можно касаться, и проверяет каждую команду против него, а чтение страниц открывает только публичные страницы через выход, который отказывает приватным и внутренним адресам. Результаты инструментов, которые вы возвращаете, считаются данными, так что отражённый payload в ответе не становится инструкцией модели. Модель читает; ваши инструменты шлют.

notholy kb "jwt none algorithm" --json

#Где не подходит

Это не scanner и не замена DAST или SAST. Она не будет обходить приложение и не выстрелит запросы, а предложенный payload может быть ложной зацепкой, так что подтвердите его против работающей цели до того, как он попадёт в находку. Чтение страниц открывает только публичные страницы, не аутентифицированный endpoint и не внутренний host. Модель может ошибиться насчёт проверки или выдумать параметр, так что читайте запрос, который она пишет, до отправки. Чистое чтение не доказывает, что приложение безопасно, а аккаунту нужен e-mail.

Пусть ваш proxy шлёт трафик, а модель читает ответы. Поставьте CLI, добавьте небольшой баланс на тарифы и вставьте первый запрос.