Quanto è pericoloso divulgare la struttura di una tabella agli utenti?

Ciò a cui si fa riferimento è potenzialmente una vulnerabilità SQLi basata su errori, che rientra in una categoria più ampia nota come In-Band / Classic SQL injection. In sostanza, queste vulnerabilità consentono a un utente malintenzionato di avviare un attacco e di raccogliere informazioni sul database dallo stesso canale di comunicazione. Dico che è solo una potenziale vulnerabilità perché non siamo sicuri se hai effettivamente provato SQLi, piuttosto hai appena scoperto un errore. Questo può essere confermato tramite test, assumendo il permesso.

La vulnerabilità SQLi basata sugli errori che stai vedendo potenzialmente fornisce informazioni sulla struttura del database (come hai sottolineato) che aiuta l'enumerazione del database (potenzialmente l'intero database) per l'autore dell'attacco.

Si sta dicendo, "Ciao utente internet amichevole che non ho motivo di diffidare, la query che stai cercando di eseguire (ovviamente senza intenti maliziosi) è sfortunatamente errata, quindi ecco la struttura esatta del mio database in modo che il tuo prossimo la query può essere scritta in modo più appropriato per raggiungere il successo! "

Tale messaggio di errore dettagliato dovrebbe essere disabilitato su un sito live o registrato su un file con accesso limitato. Una pratica migliore sarebbe, a seconda della situazione, fornire all'utente un errore di 400 o 500 pur essendo consapevole di non fornire più informazioni di quanto sia assolutamente necessario.

La divulgazione delle strutture della tabella non è intrinsecamente pericolosa e non apre nuovi problemi di sicurezza che non esistevano già nell'applicazione. può aiutare un utente malintenzionato a trovare un exploit esistente nella propria applicazione, ma molto probabilmente sarà comunque in grado di elaborare la struttura della tabella.

Quasi tutti i siti web in cui ho visto il codice hanno i nomi di input del modulo HTML esattamente identici a quelli delle colonne db in quanto non c'è davvero bisogno di tradurli. Di solito le sole altre colonne che non puoi vedere mentre invii sono cose come id, created_at, deleted_at, author_id e altre cose ovvie. Anche considerando che ci sono numerosi siti web open source in cui è possibile leggere l'intero schema ma quei siti sono ancora sicuri.

Il problema principale con questo esempio in particolare è che sembra essere uno strumento di debug di sviluppo che non era destinato a essere lasciato in produzione. Le informazioni contenute in questo esempio a mio parere non sono sensibili, ma spesso gli strumenti di debug danno altre informazioni che possono essere molto pericolose per distribuire come ENV vars che può contenere password.

Se ti interessa la sicurezza dovresti filtrare i parametri che l'utente può inviare in modo che l'utente non sia in grado di aggiornare cose come la colonna del ruolo sul proprio account. L'utente che conosce il fatto che esiste una colonna di ruolo non sarà di aiuto se il server rifiuta quel parametro.