Un'app creata interamente dall'IA ha esposto 1,5 milioni di record in 3 giorni: 5 cose a cui prestare attenzione per evitarlo

Ecco la traduzione in italiano del testo fornito, seguendo tutte le linee guida specificate.

A gennaio di quest'anno è stato lanciato un social network chiamato "Moltbook".

Era un social network insolito, dove potevano pubblicare solo agenti AI, ed era stato costruito quasi interamente dall'AI. Questo è ciò che si potrebbe chiamare vibe coding.

Entro tre giorni dal suo lancio, un ricercatore di sicurezza ha notato una cosa:

"Chiunque può leggere e riscrivere il contenuto del database di questa app."

Quello che è trapelato sono stati circa 1,5 milioni di token di autenticazione, circa 35.000 indirizzi email e migliaia di messaggi privati.

La direzione ha risolto immediatamente, ma fino a quel momento, per diversi giorni, chiunque avrebbe potuto prendere tutto ciò che voleva.

Il mio lavoro consiste nel supportare lo sviluppo interno di strumenti AI e nel condurre controlli di sicurezza.

Questo incidente presentava in realtà la stessa identica vulnerabilità che vedo più spesso nelle aziende che hanno costruito strumenti interni usando l'AI.

Ecco cosa è successo e cinque cose a cui prestare attenzione per evitare che accada anche a te.

====

Cosa è successo

Le cause erano solo due.

Primo. Il database non aveva una regola che dicesse "puoi vedere solo i tuoi dati".

Secondo. La chiave usata per connettersi al database era scritta direttamente nel codice lato browser.

Chiunque può vedere una chiave scritta nel browser semplicemente aprendo gli strumenti di sviluppo.

Se ti connetti al database con quella chiave, vengono restituiti tutti i dati perché non ci sono regole che li limitano.

In altre parole, tutto era visibile attraverso la porta sul retro, senza nemmeno passare dall'interfaccia dell'app.

L'AI ha costruito con successo un'"app funzionante".

Tuttavia, non ha costruito la parte "nascondila agli altri" perché non le era stato chiesto.

Questa è la trappola più grande quando si costruisce con l'AI.

====

1. "Potersi Collegare" e "Non Vedere i Dati degli Altri" Sono Due Cose Diverse

Quando si sviluppa un'app, una funzione di login è quasi sempre inclusa.

Le persone tendono a pensare: "Ho aggiunto una funzione di login per ora, quindi va bene", ma non è corretto.

Il login è una funzione per verificare "chi" è una persona.

Cosa "quella persona è autorizzata a vedere" deve essere costruito separatamente.

Anche Moltbook aveva un sistema di login.

Tuttavia, dopo il login, gli utenti potevano raggiungere i dati di altre persone.

Il controllo è semplice.

Crea due account di test, accedi con l'Account A e prova ad aprire direttamente l'URL dei dati dell'Account B.

Se riesci a vederli, sei esposto.

Ecco il prompt per l'AI:

"Assicurati che gli utenti possano accedere solo ai propri dati. Assicurati che, anche se aprono l'URL dei dati di qualcun altro, non possano vederli."

====

2. Metti una Regola "Vedi Solo la Tua Parte" Anche sul Lato Database

Il primo punto riguardava il lato app.

Tuttavia, come Moltbook, qualcuno potrebbe connettersi direttamente al database attraverso la porta sul retro senza passare dall'app.

Pertanto, dovresti mettere una regola nel database stesso che dica "questa persona può vedere solo questa riga".

Con questo in atto, anche se la chiave dovesse trapelare, i dati delle altre persone non potrebbero essere recuperati.

I servizi di database usati frequentemente nel recente sviluppo AI hanno questa funzione.

Tuttavia, è spesso disattivata per impostazione predefinita. L'AI non la attiverà a meno che non glielo si chieda.

Ecco il prompt:

"Abilita una regola su tutte le tabelle del database in modo che gli utenti possano leggere solo le proprie righe."

====

3. Non Inserire Chiavi sul Lato Browser

L'altra causa per Moltbook era che la chiave era scritta nel browser.

Un'app ha "codice che viene eseguito lato server" e "codice che viene eseguito lato browser".

Il lato browser viene inviato interamente al PC dell'utente. In altre parole, scrivere una chiave lì è come distribuirla a tutti.

Come controllare: apri gli strumenti di sviluppo e cerca "key", "token" o "secret".

Se appare una lunga stringa che assomiglia a una di queste, devi stare attento.

Ecco il prompt:

"Tieni le chiavi e le password rigorosamente lato server. Non includerle mai nel codice lato browser."

====

4. Fai Interpretare la Parte del "Cattivo" a un'AI Diversa Prima del Rilascio

Se chiedi all'AI che l'ha costruita: "È sicura?", risponderà "Sì". Perché l'ha costruita lei stessa.

Pertanto, dovresti far revisionare l'app da un'AI diversa da quella usata per lo sviluppo, dal punto di vista di un attaccante.

Chiedile: "Se dovessi introdurti in questa app, da dove entreresti?"

Quando faccio questo con gli strumenti dei clienti, saltano fuori vulnerabilità che non avevano notato a bizzeffe.

Le due vulnerabilità in Moltbook sono a un livello che normalmente verrebbe trovato con questa domanda.

Ecco il prompt:

"Sei un attaccante. Elenca tutti i modi per visualizzare i dati di altre persone in questa app. Se ne trovi, fornisci anche le correzioni."

====

5. Una Volta Rilasciato, Registra "Chi Ha Visto Cosa" e Controllalo Ogni Giorno per la Prima Settimana

Moltbook è stato risolto perché un ricercatore esterno lo ha trovato e ha contattato gli sviluppatori.

Non se n'erano accorti da soli.

Con gli strumenti interni, nessuno ti contatterà.

Pertanto, tieni un registro di "chi ha effettuato l'accesso quando e quali dati ha visualizzato".

Poi, controlla quel registro ogni giorno per la prima settimana dopo il rilascio.

Una fonte di accesso sconosciuta, un accesso massiccio nel cuore della notte, o una persona che apre i dati di tutti.

Puoi capire queste cose immediatamente guardando i registri.

Ecco il prompt:

"Tieni un registro di chi ha avuto accesso a quali dati e quando. Tuttavia, non scrivere password o informazioni personali nei registri."

====

Riepilogo

Per riassumere l'incidente di Moltbook in una frase:

"L'AI costruisce ciò che le viene chiesto di costruire, ma non costruisce ciò che non le viene chiesto di costruire."

Quando creiamo strumenti interni, comunichiamo "Voglio questo tipo di funzionalità".

Ma non diciamo "Non mostrarlo agli altri" o "Non mettere la chiave nel browser".

Poiché non lo diciamo, non viene incluso.

Al contrario, tutte e cinque queste cose possono essere incluse semplicemente aggiungendo una singola frase all'AI.

Per prima cosa, prova a creare due account di test con uno strumento che hai attualmente in esecuzione e apri l'URL dei dati di qualcun altro.

Solo facendo questo capirai se hai la stessa vulnerabilità di Moltbook.

====

Infine, un annuncio.

La nostra azienda offre un servizio per sviluppare da zero agenti AI specifici per le attività della tua azienda.

Invece di formazione o introduzione di strumenti, ti intervistiamo sul tuo flusso di lavoro aziendale reale e forniamo qualcosa di "utilizzabile a partire da domani" così com'è. Forniamo supporto costante fino al miglioramento post-introduzione e allo sviluppo interno.

Offriamo anche un servizio in cui gli ingegneri ti accompagnano per controllare la sicurezza e il funzionamento degli strumenti AI interni, oltre a gestire la successiva manutenzione e le modifiche. Una caratteristica fondamentale è che non finiamo solo dopo aver costruito, ma stabiliamo un "sistema di protezione continua" dal punto di vista dei cinque punti di questo articolo.

Se sei un imprenditore o un manager che pensa: "Il nostro strumento potrebbe mostrare i dati se qualcuno apre l'URL di un'altra persona", per favore, parliamone.

La consulenza iniziale è gratuita e possiamo mostrarti una demo del controllo dal punto di vista dell'attaccante introdotto in questo articolo sul momento. Dato che possiamo iniziare organizzando insieme dove il tuo sistema è vulnerabile, sentiti libero di contattarci via DM o LINE.

Dire semplicemente "AI" va benissimo↓

LINE: https://line-harness.r-yagi.workers.dev/r/x