Sicurezza LLM e attacchi bot: un piano di test pratico

Che tipo di attacco stai cercando di fermare?

La sicurezza LLM copre l'applicazione attorno al modello e le sue risposte. I tentativi di prompt injection fanno sì che l'input non attendibile si comporti come un'istruzione. L'abuso dei bot utilizza l'automazione per abusare di un flusso di lavoro, potenzialmente senza alcuna richiesta speciale. La stessa applicazione può riscontrare entrambi, ma un controllo che rileva linguaggio sospetto non fermerà necessariamente le ripetute richieste apparentemente legittime.

Il progetto sulle minacce automatizzate di OWASP include esplicitamente l'uso improprio di funzionalità valide dell'applicazione. La sua guida al rischio LLM descrive l’eccessiva inferenza come una via verso il degrado del servizio e la perdita economica. Utilizzare queste distinzioni durante la valutazione di un incidente: identificare la risorsa interessata e il risultato prima di decidere se il problema appartiene al comportamento del modello, all'accesso all'account, all'autorizzazione o alla gestione delle risorse.

Prova: Minacce automatizzate OWASP alle applicazioni Web [1]LLM10:2025 Consumo illimitato [2]

Scrivere il limite del test prima di scegliere uno scanner

Per il flusso di lavoro di valutazione proposto da Rubrex, indicare la versione dell'applicazione, l'ambiente, i punti di ingresso, la configurazione del modello, le fonti di recupero e gli strumenti abilitati. Identificare il proprietario di ciascuna risorsa protetta. Scrivi una frase per il risultato che non deve mai verificarsi, ad esempio un utente di supporto che vede il ticket di un altro tenant o un assistente di sola lettura che invia un messaggio.

Utilizzare un ambiente di test con account, documenti e destinazioni degli strumenti sintetici. Concordare il massimale di richiesta, il massimale di spesa, la finestra di esecuzione e le condizioni di arresto con il proprietario del sistema. Una quota configurata bassa può esercitare l'applicazione senza produrre un'ondata di traffico. Mantieni un piccolo insieme di attività ordinarie del cliente come controlli e registra lo stato iniziale dei dati in modo da poter reimpostare le prove successive. Questo è un piano di test dell'applicazione, non un'autorizzazione per eseguire la scansione di servizi non correlati.

Testare l'inserimento del prompt rispetto alle autorizzazioni effettive dello strumento

OWASP consiglia di trattare i guardrail basati su modello come uno strato accanto a strumenti vincolati, convalida e privilegi minimi. La sua guida all’eccessiva agenzia colloca l’autorizzazione nei sistemi a valle piuttosto che lasciare che sia il modello a decidere se un’azione è consentita. Un'istruzione forte è un contesto utile, ma non può sostituire un controllo dei permessi.

In un test di supporto illustrativo, una nota sintetica recuperata chiede all'assistente di modificare il titolare di un ticket anche se l'utente ha richiesto solo un riepilogo. Sostituisci lo strumento di scrittura live con un'implementazione di test strumentata. Registra se il modello ha richiesto la scrittura, se il limite dello strumento lo ha consentito e se qualche record è stato modificato. Un modello di rifiuto e una richiesta di strumento respinta sono osservazioni diverse; preservarli entrambi.

Quindi invia un aggiornamento legittimo tramite un account di prova autorizzato. Se la correzione proposta blocca ogni aggiornamento, ha modificato il contratto del prodotto anziché dimostrare una protezione utilizzabile. Per le azioni che richiedono l'approvazione, verificare che l'obiettivo e gli argomenti approvati siano quelli eseguiti e che la loro modifica richieda una nuova decisione.

Prova: Foglio informativo sulla prevenzione dell'iniezione rapida LLM [3]LLM06:2025 Agenzia eccessiva [4]

Controllare l'abuso dei bot prima che crei costi per modelli o strumenti

La guida al consumo delle risorse API di OWASP richiede limiti espliciti al carico di lavoro e alla spesa di terze parti. Per un'applicazione LLM, valutare il costo di un'attività completa, incluso il recupero, le chiamate ai modelli, le operazioni sugli strumenti e i nuovi tentativi. Limitare il numero di richieste in entrata non è sufficiente se una richiesta accettata può innescare un lavoro a valle illimitato.

Rubrex consiglia di documentare limiti di ammissione e limiti di esecuzione separati. Al momento dell'ammissione, associa la richiesta ad un conto o inquilino verificato e verifica la sua indennità. Durante l'esecuzione, dimensione di input vincolata, budget di output, lavoro simultaneo, passaggi dello strumento e tentativi. Applica una scadenza e definisci cosa significa l'annullamento per il lavoro già in coda o inviato a un fornitore. Utilizzare i controlli sulla spesa del fornitore, ove disponibili; un avviso di fatturazione da solo non ferma il consumo.

Come controllo aritmetico illustrativo, se una politica di test consente tre chiamate di modello per attività e al massimo due tentativi per chiamata, il budget deve consentire fino a nove chiamate di modello tentate. Questa non è un'impostazione di produzione consigliata o una stima dei costi. È un modo per scoprire una discrepanza tra una quota per richiesta e il lavoro che l'applicazione può effettivamente pianificare. Includere separatamente i budget per il recupero e quelli per gli strumenti esterni.

Prova: API4:2023 Consumo illimitato di risorse [5]LLM10:2025 Consumo illimitato [2]

Esempio eseguito: corsa alle quote, correzione e nuovo test

Abbiamo eseguito il dispositivo Node.js senza modello collegato il 3 ottobre 2026. Utilizza due richieste simultanee e una disponibilità di un'unità sintetica. Nello scenario vulnerabile, una barriera costringe entrambe le richieste a raggiungere la stessa pausa prima che una delle due continui. Non ci sono richieste in uscita, record di utenti reali, chiamate di modelli a pagamento o obiettivi di siti live; le chiamate del provider vengono conteggiate da uno stub in memoria.

Nella versione vulnerabile, ogni richiesta controlla l'indennità rimanente, attende la barriera, quindi decrementa. Entrambi superano il controllo: due sono ammessi, si verificano due chiamate stub e l'indennità rimanente diventa -1. Nella versione fissa, la richiesta riserva la sua unità in modo sincrono prima della prima attesa. Una sola richiesta viene accolta e l'altra viene respinta prima dello stub; l'indennità rimanente è zero.

Scarica lo script ed esegui node quota-race-demo.mjs con Node.js 22. Stampa quattro scenari; il record dei risultati contiene l'output osservato, il runtime, la data e l'hash SHA-256 dello script esatto. Il controllo a budget zero nega entrambe le richieste; il controllo del budget sufficiente ammette entrambi. Tali controlli verificano che la correzione non blocchi semplicemente ogni richiesta.

Ciò dimostra un difetto di pianificazione e una correzione a processo singolo. Non è un'implementazione di quote distribuite: JavaScript sincrono non può serializzare le richieste tra lavoratori o repliche. L'ammissione alla produzione richiede una prenotazione atomica nell'archiviazione condivisa, idempotenza per i nuovi tentativi e riconciliazione esplicita al completamento o all'annullamento. Anche le richieste di modelli a costo variabile necessitano di una prenotazione conservativa e di un adeguamento dell'utilizzo finale. Verificare tali comportamenti separatamente; questo dispositivo non testa l'isolamento degli inquilini, il pronto inserimento o l'infrastruttura di produzione Rubrex.

• Scarica il dispositivo eseguibile della corsa con quota (Node.js)
• Scarica l'esecuzione registrata e l'hash dello script (JSON)

Un piccolo set di test con condizioni di superamento osservabili

I seguenti casi sono una proposta di foglio di lavoro iniziale, non il risultato di un cliente Rubrex o una richiesta di copertura completa. Sostituisci i limiti dell’esempio con il contratto scritto del prodotto. Registrare il risultato atteso prima di affrontare ciascun caso e includere successivamente un riferimento alle prove.

Per i test delle quote, configurare una quota volutamente piccola in un ambiente isolato e mantenere basso il volume delle richieste. Per i test di autorizzazione, utilizzare due tenant sintetici e marcatori univoci non sensibili. Per un nuovo tentativo di test, simula un errore di riconoscimento dopo che uno strumento falso ha completato la sua operazione. Questi dispositivi consentono di ispezionare il confine senza fare affidamento su un'interruzione effettiva, su dati reali dei clienti o su un effetto collaterale distruttivo.

Mantenere separato l’accesso ai dati dal giudizio del modello

La guida all'autorizzazione a livello di oggetto di OWASP richiede il controllo dei record a cui accede un chiamante autenticato. Applica questo principio alle origini dati utilizzate da un assistente: un accesso valido non implica l'autorizzazione a ogni documento, risposta memorizzata nella cache o risultato dello strumento. Il recupero dovrebbe utilizzare l’ambito consentito del chiamante e le operazioni downstream dovrebbero convalidare nuovamente tale ambito quando accedono a oggetti protetti.

Per l'esempio di due inquilini, posizionare un contrassegno innocuo diverso nel materiale di prova di ciascun inquilino. Esercita i documenti supportati e i percorsi di conversazione dell'applicazione, quindi esamina il contenuto restituito e le decisioni di accesso associate. Ripetere dopo che la cache è stata popolata dall'altro tenant. Registrare quali percorsi sono stati testati; un controllo di isolamento riuscito non stabilisce che ogni percorso di recupero o archiviazione sia isolato.

Prova: API1:2023 Autorizzazione a livello di oggetto interrotto [6]

Trasforma una scoperta in una correzione che qualcuno possa verificare

Un risultato utile spiega cosa ci si aspettava, cosa è successo, perché è importante e quali prove supportano la conclusione. Mantieni insieme la versione del sistema, il test case, il ruolo dell'account, la configurazione, lo stato osservato e l'identificatore di esecuzione. Separare un sospetto generato dal modello da un fallimento del confine riprodotto. Descrivi l'impatto utilizzando i dati o l'azione raggiungibili, piuttosto che la formulazione drammatica del prompt.

Per un risultato illustrativo della quota, il risultato atteso è il rifiuto prima di una chiamata del fornitore. L'errore osservato potrebbe essere una chiamata del fornitore registrata dopo l'esaurimento della disponibilità dell'account. Un candidato può riservare l'indennità prima dell'ammissione. Il nuovo test dovrebbe includere il caso originale, una concorrenza controllata sull'indennità finale e una richiesta legittima con una quota sufficiente. Registrare se il risultato è corretto, parzialmente corretto, non riprodotto o non testato; tali etichette non sono intercambiabili.

Misurare insieme protezione e usabilità del prodotto

Per la lettura della valutazione, segnala violazioni dei limiti, richieste negate, attività incomplete, falsi blocchi su casi legittimi e utilizzo delle risorse. Indicare il numero e il tipo di casi dietro ciascuna tariffa. Conserva le differenze di configurazione tra la linea di base e il candidato. Un punteggio aggregato può nascondere l'azione non autorizzata che il test intendeva prevenire.

Per le operazioni in corso, decidere chi riceve un avviso e cosa può modificare. Una risposta utile potrebbe essere quella di sospendere uno strumento costoso, ridurre l’indennità di un inquilino o richiedere temporaneamente la revisione di un percorso delicato. Mantieni l'accesso controllato ai record delle indagini ed evita di copiare le conversazioni complete dei clienti in un canale di avviso generale. Dopo un incidente confermato, aggiungere un caso di regressione ripulito e controllare nuovamente il limite pertinente dopo le modifiche al modello, al prompt, al recupero o allo strumento.

Domande comuni