Come può rilasciare il testo di una query SQL compromettere la sicurezza?

5

Ho chiesto a un'agenzia governativa, in base alla legislazione sulla libertà di informazione, di rilasciare due query SQL che hanno pubblicato per produrre una tabella che hanno pubblicato in un rapporto.

Cioè, l'agenzia ha pubblicato queste due tabelle di cifre che mostrano, per ciascun anno, il numero di casi completati in varie categorie e alcune statistiche aggregate per ogni categoria. Voglio vedere la query utilizzata per generare ogni tabella, per vedere come sono stati filtrati i dati e precisamente come l'agenzia ha definito ogni categoria.

L'agenzia ha rifiutato la mia richiesta sulla base del fatto che il rilascio di query SQL pregiudica la sicurezza delle informazioni.

In base alla legislazione pertinente, ora ho l'opportunità di chiedere una revisione di questa decisione, in cui dovrei spiegare perché il ragionamento dell'agenzia è difettoso.

A mio parere, l'unico modo in cui questo può rappresentare un rischio per la sicurezza è quando un utente malintenzionato utilizza le informazioni sui nomi di tabelle e colonne per avviare un attacco SQL injection. Tuttavia, il database in questione è un data warehouse interno privo di applicazioni Web accessibili pubblicamente che lo accedono e, in ogni caso, l'agenzia ha rigorosi standard di codifica e test di penetrazione, ecc., Per prevenire cose come le vulnerabilità di SQL injection.

Posso anche immaginare che se l'agenzia fosse, per esempio, la National Security Agency degli Stati Uniti e il database fosse chiamato "overseas_phone_taps_by_country", allora i nomi di tabella / colonna sarebbero essi stessi informazioni sensibili. In questo caso, tuttavia, stiamo parlando di un database contabile tenuto da un'agenzia di regolamentazione piuttosto noiosa.

Anche in questo caso se la query è stata utilizzata per generare elenchi di casi, allora potrei vedere il problema, dal momento che la query conterrebbe cose come il caso in cui un caso verrà preso in considerazione per un'azione di enforcement, ecc. Tuttavia, questo non è il caso qui.

Come potrebbe liberare il testo di una query SQL come un rischio per la sicurezza?

EDIT: l'agenzia ha fornito la seguente spiegazione nella sua lettera di rifiuto:

SQL queries contain information about the agency's information systems (information related to the content, location and storage of sensitive information), which, if released, could reasonably be expected to increase the risk of compromise to the agency's information systems.

As such, I consider that disclosure of the SQL queries represents a potential security risk to the agency.

Il parere dell'esperto di sicurezza dell'agenzia è:

I am of the opinion that the release of the SQL queries, even in a redacted form, would provide information about the programmable interfaces and logic flow within our systems, and give information about identifiers, pointers and references that would compromise the security and safety of the agency's systems.

    
posta Patrick Conheady 24.04.2016 - 09:30
fonte

4 risposte

3

Probabilmente hanno un DBA a cui è stato detto che non si dovrebbe permettere alle persone di conoscere la struttura del database a causa dei rischi di SQL injection. Come hai detto, non ha senso per un database interno.

Non ci sono rischi evidenti per rilasciare una query dal punto di vista della sicurezza. Qual era la loro esatta formulazione della ragione per cui l'hanno rifiutata?

    
risposta data 25.04.2016 - 03:06
fonte
1

Generalmente quando si tenta di proteggere un'applicazione si desidera assicurarsi di non divulgare alcuna informazione potenzialmente utilizzabile come parte di un attacco. Questa è la stessa ragione per cui è più sicuro visualizzare una pagina di errore generica anziché una traccia dello stack. Anche se visualizzare la traccia dello stack probabilmente non è una vulnerabilità in sé, rende più facile la vita a un utente malintenzionato che raccoglie informazioni sul sistema.

Questo non deve essere confuso con la "sicurezza attraverso l'oscurità" in cui ti affidi a qualcosa che è segreto per mantenere la sicurezza. L'assunto è che ogni sforzo è stato fatto per proteggere l'applicazione in questione.

Non importa se l'applicazione è interna o meno secondo me. Ascolti di routine storie su hacker che violano le reti governative (a volte ti nascondi da anni), quindi il fatto che si trovi su una rete interna non significa che sia al riparo da minacce esterne.

Anche avere rigide linee guida sulla sicurezza e eseguire test di penetrazione non garantisce il 100% di sicurezza. Se parli con qualcuno che fa pentecoste per vivere, non garantiranno che trovano il 100% dei problemi di sicurezza (e se lo fanno probabilmente stanno soffiando fumo).

    
risposta data 14.06.2016 - 22:49
fonte
0

Forse sarebbe meglio chiedere all'agenzia "Come sono stati filtrati i dati e precisamente come l'agenzia ha definito ogni categoria?"

Anche se sono d'accordo sul fatto che nascondere SQL per aggiungere sicurezza è solo "sicurezza per oscurità", non riesco nemmeno a capire perché fornire le query SQL sia il modo migliore per fornire le informazioni di cui hai bisogno o di cui hai bisogno.

    
risposta data 14.06.2016 - 21:48
fonte
0

Potrebbero facilmente sostituire i nomi effettivi di tabelle e colonne con alias. Tuttavia, dal punto di vista della sicurezza, è improbabile che anche una query SQL completamente non stampata rilasci qualsiasi informazione che sarebbe utile per un utente malintenzionato. Una volta che un utente malintenzionato ottiene l'accesso a livello dba al database, l'esecuzione di query sullo schema è banale. Il contrario non è vero.

    
risposta data 14.06.2016 - 23:00
fonte

Leggi altre domande sui tag