Spiegazione delle perdite di informazioni su Lead dev

Qualsiasi informazione sui componenti interni di un sistema o un'applicazione aiuta un utente malintenzionato a creare un attacco specifico. Ad esempio, quel messaggio di errore include i nomi delle tabelle, il che significa che diventa molto più facile creare un attacco SQLi.

Inoltre, con messaggi di errore dettagliati, potrei provare a innescare diversi errori per mappare la funzione del back-end e persino a trovare le vulnerabilità molto più velocemente.

In generale, i messaggi di errore dettagliati sono un no-no. Usali solo su un'istanza di QA per il debug.

Detto questo, c'è una ragione per cui "la divulgazione di informazioni" non è considerata una scoperta "alta" automatica. È possibile che anche i dettagli dell'applicazione o del sistema non aiutino un utente malintenzionato, ma questo dipende da ogni singolo sistema. Quindi, il rischio deve essere valutato in ogni istanza (che non fornisce una risposta rapida al tuo lead dev).

Come valutatore, però, quando vedo messaggi di errore dettagliati come quello che hai postato, so che gli sviluppatori non sono stati attenti, e posso presumere che l'applicazione non sia codificata correttamente, e probabilmente con un sacco di vulnerabilità. In breve, se vedo un messaggio del genere, estraggo tutte le pistole per trovare i fori che possono esserci, e ho tutti i dettagli di cui ho bisogno per sfruttarli con precisione.

Fornisce un rischio per la sicurezza, anche se potrebbe non essere enorme.

Ciò che mostra è un codice reale che rivela:

• La lingua utilizzata dal tuo backend (almeno spero che sia il tuo codice di back-end - se stai facendo una query sul database dal lato del client, potresti rivelare troppe informazioni a loro), e possibilmente alcune delle librerie che stai usando. A seconda delle specifiche, potrebbe esserci qualche vulnerabilità senza patch che un utente malintenzionato esperto può trovare per provare contro di te con quella conoscenza. Ora, per essere onesti, nascondere questa informazione è sicurezza per oscurità, ma come regola generale, non si vuole mai rivelare più del necessario.
• Dall'aspetto, parte della struttura dei tuoi database. Queste sono più informazioni che non sanno nulla di business e nulla di buono può venire da esso. Ad esempio, può aiutarli a eseguire un attacco di iniezione.

Ora, è un rischio enorme? Solo tu puoi valutare questo, in base alla tua situazione. Potrebbe essere che anche se compromettano il tuo intero sistema, non ti interessa, ma dovrebbe comunque essere affrontato. Anche se non ci sono danni reali che potrebbero farti, sembra poco professionale e ti riflette male.