Perché usare NotHoly per la sicurezza di web e API

Testare web e API è leggere: una richiesta, una risposta, un bundle JavaScript, una spec OpenAPI, e poi scrivere la richiesta successiva che prova il bug. Un modello generico tentenna nel momento in cui chiedi la stringa di injection o il bypass dell'auth, e uno scanner trova il superficiale e si ferma. NotHoly legge ciò che incolli, scrive il test, e lascia l'invio al tuo proxy. Tieni Burp, Caido, ZAP o i tuoi script; il modello è il lettore e lo scrittore nel loop. Il caso d'uso di pentest ha la metodologia; qui si parla del perché il modello si adatta al lavoro su web e API.

#Incolla la richiesta, la risposta o la spec

Dai al modello l'HTTP grezzo, una risposta che sembra sbagliata, un pezzo di un bundle o un documento OpenAPI, e nomina cosa manca: un riferimento a oggetto senza controllo di proprietà, un endpoint che si fida di un ruolo lato client, un parametro che arriva a una query senza escape, un token che non è validato. Spiega perché, e segna la richiesta da mandare dopo. Incolla una risposta con un header strano o una fuga nell'errore, e ti dice cosa rivela e come insistere. Visto che il modello non rifiuta il compito, un percorso IDOR, una sonda di SQL injection o un test di confusione JWT si scrive come qualsiasi altro codice, finché il bersaglio è nel tuo scope. Il reasoning passa, così un flusso di auth a più passi si risolve prima di scrivere il payload.

#Payload e controlli per il tuo proxy

Chiedi l'artefatto che il tuo strumento usa, e il modello lo scrive: una Bambda o un BCheck di Burp, un workflow di Caido, un tamper script di sqlmap, la logica per un giro di ffuf, un piccolo script requests. La base di conoscenza è parte del modello, quindi tira OWASP WSTG, l'API Security Top 10, la Cheat Sheet Series e la documentazione degli strumenti di Caido e Burp con una fonte e licenza su ogni passaggio. Una versione di framework che trovi va a un lookup CVE con CVSS, EPSS e KEV, e una dipendenza va a una query advisory, nessuno dei due costa token. Il risultato è un payload con un motivo e un riferimento, non un'ipotesi. Puoi anche tenere l'intero flusso in una conversazione, dalla prima risposta strana al test finito, così il contesto che spiega perché un payload funziona non si perde tra le schede.

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

#Il traffico resta tuo

I server di NotHoly non scansionano, sondano né mandano un payload a un bersaglio. Le richieste che testano l'applicazione vengono dal tuo proxy e dai tuoi script, sulla tua macchina, dal tuo indirizzo. Quando lo guidi dal terminale, notholy engage registra lo scope che puoi toccare e controlla ogni comando contro di esso, e il lettore di pagine apre solo pagine pubbliche attraverso un'uscita che rifiuta indirizzi privati e interni. I risultati di strumento che restituisci sono trattati come dato, così un payload riflesso in una risposta non diventa un'istruzione per il modello. Il modello legge; i tuoi strumenti mandano.

notholy kb "jwt none algorithm" --json

#Dove non si adatta

Non è uno scanner né un sostituto di DAST o SAST. Non scansionerà l'applicazione né sparerà le richieste, e un payload suggerito può essere una pista falsa, quindi confermalo contro il bersaglio in esecuzione prima che finisca in un reperto. Il lettore di pagine apre solo pagine pubbliche, non un endpoint autenticato né un host interno. Il modello può sbagliare su un controllo o inventare un parametro, quindi leggi la richiesta che scrive prima di mandarla. Una lettura pulita non è prova che l'applicazione sia sicura, e l'account ha bisogno di una e-mail.

Lascia che il tuo proxy mandi il traffico e il modello legga le risposte. Installa la CLI, aggiungi un saldo piccolo su prezzi, e incolla la prima richiesta.