¿Cómo puede la liberación del texto de una consulta SQL comprometer la seguridad?

6

Le pedí a una agencia gubernamental, en virtud de la legislación de Libertad de Información, que libere dos consultas SQL que realizaron para producir una tabla que publicaron en un informe.

Es decir, la agencia publicó estas dos tablas de cifras que muestran, para cada año, el número de casos completados en varias categorías y algunas estadísticas agregadas para cada categoría. Quiero ver la consulta utilizada para generar cada tabla, para ver cómo se filtraron los datos y exactamente cómo la agencia definió cada categoría.

La agencia ha rechazado mi solicitud sobre la base de que liberar cualquier consulta SQL perjudicará su seguridad de la información.

Bajo la legislación pertinente, ahora tengo la oportunidad de solicitar una revisión de esta decisión, en la cual tendría que explicar por qué el razonamiento de la agencia es erróneo.

En mi opinión, la única forma en que esto podría ser un riesgo de seguridad es cuando un atacante usa la información sobre los nombres de tablas y columnas para lanzar un ataque de inyección de SQL. Sin embargo, la base de datos en cuestión es un almacén de datos interno sin aplicaciones web de acceso público y, en cualquier caso, la agencia cuenta con estrictos estándares de codificación y pruebas de penetración, etc., para prevenir vulnerabilidades de inyección de SQL.

También puedo imaginar que si la agencia fuera, por ejemplo, la Agencia de Seguridad Nacional de los EE. UU., y la base de datos se llamara 'overseas_phone_taps_by_country', los nombres de la tabla / columna serían información confidencial. En este caso, sin embargo, estamos hablando de una base de datos contable mantenida por una agencia reguladora bastante aburrida.

Nuevamente, si la consulta se utilizaba para generar listas de casos, podría ver el problema, ya que la consulta contendría cosas como el umbral en el que se considerará un caso para una acción de cumplimiento, etc. Sin embargo, eso no es El caso aquí.

¿Cómo podría suponer un riesgo para la seguridad la publicación del texto de una consulta SQL?

EDITAR: La agencia proporcionó la siguiente explicación en su carta de rechazo:

  

Las consultas SQL contienen información sobre los sistemas de información de la agencia   (información relacionada con el contenido, la ubicación y el almacenamiento de información confidencial).   información), que, de ser divulgada, podría esperarse razonablemente que   aumentar el riesgo de compromiso con los sistemas de información de la agencia.

     

Como tal, considero que la divulgación de las consultas SQL representa un   Riesgo de seguridad potencial para la agencia.

El consejo del experto en seguridad de la agencia dice:

  

Soy de la opinión de que el lanzamiento de las consultas SQL, incluso en un   Formulario redactado, proporcionaría información sobre los programas   Las interfaces y la lógica fluyen dentro de nuestros sistemas, y dan información.   sobre identificadores, indicadores y referencias que comprometerían la   Seguridad y protección de los sistemas de la agencia.

    
pregunta Patrick Conheady 24.04.2016 - 09:30
fuente

4 respuestas

3

Probablemente tienen un DBA a quien se le ha dicho que no debe informar a la gente sobre la estructura de la base de datos debido a los riesgos de inyección de SQL. Como mencionó, eso no tiene mucho sentido para una base de datos interna.

No hay riesgos obvios al liberar una consulta desde un punto de vista de seguridad. ¿Cuál fue su redacción exacta de la razón por la que lo rechazaron?

    
respondido por el Daisetsu 25.04.2016 - 03:06
fuente
1

Por lo general, cuando intenta proteger una aplicación, debe asegurarse de no revelar ninguna información que pueda ser utilizada como parte de un ataque. Esta es la misma razón por la que es más seguro mostrar una página de error genérico en lugar de una traza de pila. Aunque ver el seguimiento de la pila probablemente no sea una vulnerabilidad en sí misma, hace la vida más fácil para un atacante que recopila información sobre el sistema.

Esto no debe confundirse con "seguridad a través de la oscuridad" en la que confías en que algo sea secreto para mantener la seguridad. El supuesto es que se han hecho todos los esfuerzos para asegurar la aplicación en cuestión.

En realidad no importa si la aplicación es interna o no en mi opinión. Rutinariamente escuchas historias sobre piratas informáticos que violan las redes gubernamentales (a veces se esconden allí durante años), por lo que el hecho de que esté en una red interna no significa que esté a salvo de amenazas externas.

Además, tener estrictas normas de seguridad y realizar pruebas de penetración tampoco garantiza un 100% de seguridad. Si hablas con alguien que se dedica a hacer pentestes para vivir, no te garantizarán que encuentren el 100% de los problemas de seguridad (y si lo hacen, probablemente estén echando humo).

    
respondido por el Abe Miessler 14.06.2016 - 22:49
fuente
0

Tal vez sería mejor simplemente preguntarle a la agencia "¿Cómo se filtraron los datos y exactamente cómo la agencia definió cada categoría?"

Si bien estoy de acuerdo en que ocultar SQL para agregar seguridad es solo "seguridad por oscuridad", también no veo por qué proporcionar las consultas SQL es la mejor manera de proporcionar la información que necesita o reclama que necesite.

    
respondido por el CristianTM 14.06.2016 - 21:48
fuente
0

Podrían sustituir fácilmente los nombres de columnas y tablas reales con alias. Sin embargo, desde una perspectiva de seguridad, es improbable que incluso una consulta SQL completamente no redactada libere información que pueda ser útil para un atacante. Una vez que un atacante obtiene acceso de nivel dba a la base de datos, la consulta del esquema es trivial. Lo contrario no es cierto.

    
respondido por el Byron Jones 14.06.2016 - 23:00
fuente

Lea otras preguntas en las etiquetas