Por que usar a NotHoly para segurança de web e API

Testar web e API é leitura: uma requisição, uma resposta, um bundle de JavaScript, uma spec OpenAPI, e então escrever a próxima requisição que prova o bug. Um modelo genérico hesita no instante em que você pede a string de injeção ou o bypass de auth, e um scanner acha o superficial e para. A NotHoly lê o que você cola, escreve o teste e deixa o envio para o seu proxy. Você mantém Burp, Caido, ZAP ou os seus scripts; o modelo é o leitor e o escritor no loop. O caso de uso de pentest tem a metodologia; aqui é sobre por que o modelo encaixa em trabalho de web e API.

#Cole a requisição, a resposta ou a spec

Dê ao modelo o HTTP cru, uma resposta que parece errada, um pedaço de um bundle ou um documento OpenAPI, e ele nomeia o que falta: uma referência de objeto sem checagem de dono, um endpoint que confia num papel do lado do cliente, um parâmetro que chega a uma query sem escapar, um token que não é validado. Ele explica por quê, e marca a requisição a mandar em seguida. Cole uma resposta com um cabeçalho estranho ou um vazamento de erro, e ele diz o que isso revela e como pressionar. Como o modelo não recusa a tarefa, uma caminhada de IDOR, uma sonda de SQL injection ou um teste de confusão de JWT é escrito como qualquer outro código, desde que o alvo esteja no seu escopo. O reasoning segue, então um fluxo de auth em várias etapas é resolvido antes de o payload ser escrito.

#Payloads e checagens para o seu proxy

Peça o artefato que a sua ferramenta usa, e o modelo o escreve: uma Bambda ou um BCheck do Burp, um workflow do Caido, um tamper script de sqlmap, a lógica para uma rodada de ffuf, um script pequeno de requests. A base de conhecimento é parte do modelo, então ele puxa OWASP WSTG, o API Security Top 10, a Cheat Sheet Series e a documentação de ferramenta do Caido e do Burp com uma fonte e licença em cada trecho. Uma versão de framework que você acha vai para um lookup de CVE com CVSS, EPSS e KEV, e uma dependência vai para uma consulta de advisory, nenhum dos dois custa tokens. O resultado é um payload com um motivo e uma referência, não um chute. Você também mantém o fluxo inteiro numa conversa, da primeira resposta estranha até o teste pronto, então o contexto que explica por que um payload funciona não se perde entre abas.

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

#O tráfego continua seu

Os servidores da NotHoly nunca escaneiam, sondam nem mandam um payload a um alvo. As requisições que testam a aplicação vêm do seu proxy e dos seus scripts, na sua máquina, do seu endereço. Quando você dirige do terminal, o notholy engage registra o escopo que você pode tocar e checa cada comando contra ele, e o leitor de páginas abre só páginas públicas por uma saída que recusa endereços privados e internos. Resultados de ferramenta que você devolve são tratados como dado, então um payload refletido numa resposta não vira instrução ao modelo. O modelo lê; as suas ferramentas mandam.

notholy kb "jwt none algorithm" --json

#Onde não encaixa

Não é um scanner nem um substituto de DAST ou SAST. Ele não vai varrer a aplicação nem disparar as requisições, e um payload sugerido pode ser uma pista falsa, então confirme contra o alvo em execução antes de ir para um achado. O leitor de páginas abre só páginas públicas, não um endpoint autenticado nem um host interno. O modelo pode errar sobre uma checagem ou inventar um parâmetro, então leia a requisição que ele escreve antes de mandar. Uma leitura limpa não é prova de que a aplicação está segura, e a conta precisa de um e-mail.

Deixe o seu proxy mandar o tráfego e o modelo ler as respostas. Instale a CLI, ponha um saldo pequeno em preços, e cole a primeira requisição.