https://stadium.unad.edu.co/preview/UNAD.php?url=/bitstream/10596/21429/4/52488191.

pdf}

https://www.researchgate.net/figure/Security-vulnerabilities-in-NoSQL-
databases_tbl1_323611630

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/mongodb-security-
weaknesses-in-a-typical-nosql-database/

https://repository.ucatolica.edu.co/bitstream/10983/1305/1/RIESGOS%20AMENAZAS%20Y
%20VULNERABILIDADES%20DE%20LOS%20SISTEMAS%20DE%20INFORMACION%20GEOGRAFICA
%20GPS.pdf

https://www.academia.edu/38501209/Amenazas_de_relacionales_sql_y_no_relacionales_nosql

Las formas más comunes en que la seguridad de la base de datos relacional puede verse
comprometida es a través del abuso de privilegios del usuario, autenticación débil, auditoría débil
y estrategias de respaldo débiles. Algunas consideraciones clave para abordar estos potenciales de
compromiso son las siguientes.

Abuso de privilegios de usuario

Los privilegios del usuario controlan a qué recursos (p. Ej., Activos, aplicaciones, datos,
dispositivos, archivos, redes, sistemas) puede acceder un usuario y qué acciones puede realizar un
usuario en esos recursos.

Con demasiada frecuencia, los privilegios de usuario sin restricciones o excesivos se asignan
ampliamente a grupos, roles e individuos para simplificar el proceso de administración de usuarios
y garantizar que los usuarios puedan hacer su trabajo sin activar alertas de seguridad o ser
bloqueados de los activos necesarios.

Como resultado, la seguridad de la base de datos puede verse comprometida si un usuario con
privilegios excesivos o sin restricciones:

Realiza cambios no autorizados en la base de datos, como agregar, modificar o eliminar datos.

Visualiza datos confidenciales o confidenciales, incluida la propiedad intelectual, el código, los

datos legales y la información personal de los empleados y clientes, aunque no es necesario para
su trabajo.

Falsifica las investigaciones de alertas al ver, modificar o eliminar registros de auditoría.

Abordar el potencial de abuso de privilegios del usuario implica estrategias de prevención y

detección. Las estrategias sugeridas incluyen lo siguiente.
Prevención

Implemente una sólida gestión de derechos de usuario.

Hacer cumplir la separación de funciones .

Considere restringir el acceso a datos confidenciales colocando la base de datos en un servidor

ubicado en una red privada, con controles de acceso multinivel implementados a nivel de sistema
operativo, red, servidor, base de datos, tabla y / o fila.

Nota: La implementación de controles de acceso multinivel requiere descubrir dónde se encuentra

su base de datos, qué datos se almacenan dentro de la base de datos y luego clasificar esos datos
por tipo, sensibilidad y valor / nivel de riesgo. También requerirá crear perfiles de privilegio de
usuario granulares, en lugar de de trazo amplio.

Detección

Realice un monitoreo frecuente de usuarios privilegiados , incluidas auditorías de todos los

comandos ingresados por un DBA u otro usuario privilegiado.

Ejecute auditorías frecuentes de acceso a datos confidenciales.

Vea cómo Imperva Data Protection puede ayudarlo con la seguridad de la base de datos relacional.

u obtenga más información

Autenticación débil

La seguridad de la base de datos puede verse comprometida por políticas de contraseña débiles o
ineficaces, cuentas de usuario compartidas, cifrado deficiente y / o robo de credenciales de inicio
de sesión del usuario, y eludir los controles de acceso al permitir el acceso directo al DBMS /
RDMS.

Abordar problemas de autenticación débiles implica estrategias de prevención y detección. Las

estrategias sugeridas incluyen lo siguiente.

Prevención

Vuelva a configurar los sistemas de la aplicación (por ejemplo, PeopleSoft y SAP) para que no
puedan conectarse directamente a la base de datos, ya que la autenticación se basa en las
credenciales de la aplicación en lugar de las credenciales del usuario. Como resultado, tanto el
sistema operativo como la base de datos desconocen la identidad del usuario y no pueden
imponer controles de acceso o rastrear acciones a un usuario específico.
Deshabilite las cuentas de usuario genéricas de un sistema de aplicación y las contraseñas en
blanco predeterminadas. En su lugar, cree nuevos perfiles / cuentas de usuario con un nombre
diferente.

Desactiva las contraseñas caducadas y las contraseñas recicladas.

Implemente características de complejidad y antigüedad de contraseña en el DBMS / RDMS.

Enmascarar contraseñas.

Autentique tanto el usuario como el dispositivo utilizado para acceder a la base de datos
(especialmente los dispositivos que trae consigo).

Cree un perfil de referencia de comportamiento o una 'lista blanca' de patrones típicos de acceso a
las bases de datos, en función de la unidad funcional y el rol, y luego destaque a los usuarios, hosts
de clientes y servidores más riesgosos para que los equipos de seguridad puedan priorizar la
investigación de cualquier anomalía.

Detección

Cree alertas y luego investigue intentos fallidos de inicio de sesión y bloqueos de cuenta.

Auditar objetos de datos cada vez que se accede a un objeto.

Audite todos los comandos escritos por los usuarios con acceso directo a los datos.

Auditoría débil

Con demasiada frecuencia, las auditorías se consideran complejas y requieren mucho tiempo.
Como resultado, las organizaciones pueden no implementar un plan de auditoría sólido. Pero los
mandatos regulatorios y específicos de la industria requieren auditorías para determinar el
cumplimiento. Y las auditorías ayudan a garantizar la investigación oportuna y la respuesta a las
anomalías.

Las estrategias sugeridas para mejorar la auditoría incluyen las siguientes.

Prevención

Defina qué transacciones deben auditarse, como inicios de sesión fallidos, cuentas compartidas e
intentos de inicio de sesión con nombres de usuario inexistentes, en horas inusuales o con
nombres de usuario diferentes pero con el mismo dispositivo.

Realice un monitoreo frecuente de usuarios privilegiados, incluidas auditorías de todos los

comandos ingresados por un DBA u otro usuario privilegiado.

Ejecute auditorías frecuentes de acceso a datos confidenciales

Exigir la separación de tareas para que los usuarios con privilegios de usuario sin restricciones no
puedan modificar o eliminar registros de auditoría.
Asegúrese de que DBA no tenga privilegios de superusuario / sin restricciones.

Detección

Cree alertas de anomalías en los registros de auditoría, pero tenga en cuenta la fatiga de las
alertas .

Estrategias de respaldo débiles

La seguridad de la base de datos puede verse comprometida por copias de seguridad incompletas
o fallidas, robo o almacenamiento incorrecto de medios de copia de seguridad sin cifrar.

Además, las transacciones de la base de datos se registran en un registro de transacciones escrito

en la base de datos y en un archivo separado. Si la base de datos está dañada, el registro de
transacciones también está dañado. Eso crea problemas de integridad y recuperación de datos.

Algunas estrategias para fortalecer las copias de seguridad incluyen las siguientes.

Prevención

Defina una estrategia de respaldo y recuperación adecuada para su organización.

Actualice el registro de transacciones dentro del intervalo mínimo de recuperación.

Haga una copia de seguridad del registro de transacciones antes de truncarlo.

Cifre el archivo de registro de respaldo.

Copie las copias de seguridad en un servidor separado, casi en tiempo real.

Garantice fuertes controles de acceso (tanto físicos como virtuales) para la ubicación donde se
almacenan los medios de respaldo.

Detección

Realice comprobaciones de estado, como BACKUP VALIDATE y RESTORE VALIDATE, para verificar
posibles corrupciones.

Obtenga más información sobre cómo BCS utiliza cookies para mejorar su experiencia de
navegación.

Cerrar aviso de cookies

saltar al contenido
Buscar BCS

Buscar en el sitio web de BCS

Buscar

Cerca

Logotipo de BCS, The Chartered Institute for IT

Afiliación

Obtener calificado

Eventos

Política e influencia

Desarrolla a tu gente

Entregar y enseñar calificaciones

Más

Icono de búsqueda

Iniciar sesión icono

Ícono de inicio

Centro de contenido

Artículo

Los 10 principales ataques a la base de datos

Las bases de datos empresariales y las infraestructuras de almacenamiento de información, que

poseen las joyas de la corona de una organización, están sujetas a una amplia gama de abusos y
ataques, particularmente cuando quedan vulnerables por un diseño o configuración deficiente del
sistema. Martin Pill CITP, consultor principal y arquitecto de seguridad de BSI Cybersecurity and
Information Resilience, describe el más crítico de estos, seguido de recomendaciones para mitigar
el riesgo de cada uno.

1. Errores de configuración de la base de datos en la nube

Apenas pasa una semana sin una nueva violación de datos causada por bases de datos en la nube
o servicios de almacenamiento configurados de forma insegura. Los datos expuestos incluyen;
información sobre el 90% de los ciudadanos de Panamá, 20.8 millones de ciudadanos
ecuatorianos, 48 millones de registros en redes sociales, 142 GB de documentos; La lista sigue y
sigue.
Las direcciones IP del servicio de nube pública no son secretas y las personas malintencionadas y
los investigadores de seguridad analizan continuamente las vulnerabilidades.

Evite que encuentren sus joyas de la corona:

a. Saber qué datos tiene, dónde se encuentran e implementar una configuración de

infraestructura efectiva y procedimientos de gestión de cambios. Se han producido muchas
infracciones de los almacenes de datos que las organizaciones desconocían, o que se habían
creado de forma insegura sobre una base ad hoc e incontrolada.

si. Teniendo en cuenta que las bases de datos en la nube y otros almacenes de datos pueden estar
abiertos a Internet de forma predeterminada en la creación y depender del usuario del servicio
para bloquearlos adecuadamente, como mediante el uso del firewall de la base de datos.
Implemente procedimientos para garantizar que esto suceda.

C. Asegurarse de que todas las bases de datos y almacenes de datos estén configuradas con
autenticación segura de forma predeterminada. Muchas infracciones se lograron fácilmente
debido a la falta de autenticación.

re. Implementación de procedimientos para monitorear el perímetro de la nube en busca de

servicios de datos inseguros. Incluso si está completamente seguro ahora, solo está a un clic
accidental del mouse lejos de la exposición.

2. inyección SQL

Las vulnerabilidades de inyección SQL se producen cuando el código de la aplicación contiene

consultas dinámicas de bases de datos que incluyen directamente la entrada proporcionada por el
usuario. Esta es una forma devastadora de ataque y los probadores de penetración BSI encuentran
regularmente aplicaciones vulnerables que permiten la omisión de la autenticación completa y la
extracción de toda la base de datos.

Prevenir la inyección de SQL es relativamente sencillo:

a. Evite el uso de consultas dinámicas dentro de las aplicaciones. El uso de declaraciones

preparadas con consultas parametrizadas detendrá la inyección de SQL.
si. Implemente la validación de entrada del usuario antes de que esa entrada se pase a la
aplicación. Esta es una defensa adicional muy valiosa que también ayuda a frustrar muchos otros
ataques.

Para una ventaja adicional, incluya monitoreo / alerta en el nivel de datos para cualquier uso de
consultas dinámicas. Esto detectará a un atacante que, por ejemplo, logró omitir la aplicación y
consultar la base de datos directamente.

C. También tenga en cuenta que las bases de datos NoSQL también están sujetas a ataques de
inyección; Se necesitan controles como la validación de entrada estricta para reducir la
probabilidad de estos.

3. Autenticación débil

La autenticación débil tiene muchas facetas, que van desde la fuerza bruta de la interfaz de
usuario hasta el almacenamiento inseguro de las credenciales de la base de datos utilizadas por
una aplicación.

a. Implemente controles de fuerza bruta como el bloqueo de cuenta después de un número

determinado de intentos no válidos. Use la lista negra de contraseñas para evitar que los usuarios
elijan contraseñas comunes.

si. No requiera que los usuarios cambien regularmente sus contraseñas, ya que esto fomenta las
contraseñas fáciles de recordar (y, por lo tanto, adivinar).

C. Considere implementar la autenticación multifactor para que un atacante necesite más que el
conocimiento de un nombre de usuario y contraseña para acceder ilegalmente a los datos.

re. No almacene las contraseñas de los usuarios en claro (sí, Pen Tests todavía encuentra esto).
Use un algoritmo de hashing de contraseña fuerte, como bcrypt y salt cada contraseña con una
cadena larga, aleatoria y única.

mi. Proteja firmemente las credenciales de la base de datos de la aplicación y asegúrese de que no
sean cuestionables. El almacenamiento de credenciales en claro en un archivo de configuración no
es seguro (pero a menudo se hace). Use una bóveda de llaves u otro medio seguro de
almacenamiento.
4. Abuso de privilegios

Los usuarios pueden abusar de los privilegios legítimos de acceso a datos para fines no
autorizados. Por ejemplo, un usuario en ventas con privilegios para ver registros de clientes
individuales puede abusar de ese privilegio para recuperar todos los registros de clientes para
pasar a un competidor.

Las buenas políticas de contratación reducirán la probabilidad de que esto ocurra, pero deben
aplicarse mediante medidas técnicas y un registro y monitoreo efectivos para detectar el abuso.

a. El acceso del usuario a los datos debe tener una tasa limitada. En el ejemplo anterior, un usuario
malintencionado podría lograr una exportación masiva al acceder a muchos registros individuales.
Limitar el número accesible en un día a un máximo razonable, restricciones de ubicación de acceso
y, cuando sea factible, las restricciones de hora del día mitigarán esto.

si. Idealmente, la aplicación y sus bases de datos no expondrían interfaces que permitan consultas
arbitrarias y la exportación masiva de datos.

C. Si existe una necesidad comercial de, por ejemplo, los analistas de datos para poder realizar
consultas arbitrarias sobre los datos, el acceso y el uso de esta interfaz deben registrarse,
auditarse regularmente y limitarse a la menor cantidad de personas posible.

5. Privilegios excesivos.

Si los usuarios tienen privilegios que exceden los requisitos de su función laboral, estos privilegios
pueden ser abusados por el individuo o un atacante que compromete su cuenta. Cuando las
personas mueven roles, se les puede dar los nuevos privilegios que necesitan sin aquellos que ya
no requieren que se eliminen.

Este problema puede abordarse efectivamente mediante una combinación de medios técnicos y
de procedimiento:

a. Controles de acceso basados en roles dentro de la aplicación que mapean con precisión los
permisos de acceso necesarios para la función de trabajo
si. Procedimientos que aseguran que cuando el personal cambia de roles, sus permisos se
actualizan para reflejar esto, con aquellos que ya no se requieren que se eliminen.

C. ¡Revisiones regulares, pero no necesariamente frecuentes, de quién tiene qué roles para
confirmar que los procedimientos están funcionando, y que el contratista que se fue hace seis
meses todavía no tiene una cuenta activa!

6. Registro inadecuado y auditoría débil.

El registro y la auditoría son clave para disuadir y detectar el mal uso y permitir una investigación
adecuada de la sospecha de compromiso de datos. En este contexto, el registro es la recopilación
de datos, y la auditoría es alguien que realmente lo está mirando.

Al considerar sus requisitos de registro y auditoría:

a. Piense qué información necesita recopilar en la capa de consulta de la aplicación y la base de

datos. Habrás pensado en casos de uso para el sistema, pero también piensa en casos de mal uso y
los datos necesarios para detectarlos. Si puede incorporar reglas de alerta automáticas, mucho
mejor.

si. Considere cómo se protegerán sus datos de registro. Si todo está en la base de datos de la
aplicación y eso está comprometido, un atacante podría borrar o falsificar los datos de registro.
Los registros pueden contener información confidencial, por lo tanto, trate de minimizar esto y
proteger sus almacenes de datos de registro.

C. Implemente procedimientos para auditar los datos recopilados para que sepa cuándo algo está
mal. Asegúrese de que la información registrada se pueda mostrar de manera significativa.

re. Considere si podría justificar la implementación de dispositivos de auditoría basados en red que
supervisen todas las solicitudes de bases de datos a nivel granular y sean independientes de todos
los usuarios.

7. Denegación de servicio.

Los ataques de denegación de servicio (DoS) a nivel de red desde Internet pueden abrumar su
sistema independientemente de la capacidad de su conexión a Internet. Los servicios de
protección DoS basados en la nube son la defensa habitual contra esto y muchos ofrecen un nivel
de protección gratuito.

Los ataques basados en el consumo de recursos, como el envío repetido de consultas de búsqueda
complejas para agotar los recursos del servidor, requieren un enfoque diferente, como la
limitación de la tasa de solicitud.

Si su aplicación es un servicio en la nube altamente escalable, esto puede expandirse bajo ataque
para mantener la disponibilidad, pero la desventaja es una gran factura a fin de mes para todos los
recursos adicionales.

8. Explotación de servicios no parcheados

Si bien los parches actualizados no lo harán seguro, operar servicios vulnerables sin parches
aumentará significativamente la probabilidad de verse comprometido.

a. Asegúrese de mantener un inventario completo y actualizado de los componentes de software

en sus sistemas, incluidas las bibliotecas de terceros y de código abierto en uso.

si. Establezca un proceso de gestión de vulnerabilidades que le permita determinar, de manera

regular, qué vulnerabilidades están presentes dentro de su (s) sistema (s) y priorizar la corrección.
Esto debería incluir suscribirse a servicios de notificación de vulnerabilidad relevantes e
idealmente usar un sistema automatizado de evaluación de vulnerabilidad (VAS).

El personal interno puede ejecutar un VAS y marcará problemas de configuración y parches, por lo
que es una inversión muy valiosa.

9. Arquitectura insegura del sistema

Si bien los controles contra amenazas específicas de la base de datos son importantes, deben
formar parte de un diseño que sea seguro en general. Este es un gran tema, pero a continuación
se dan algunos consejos:

a. Si bien la protección de límites es importante, también lo es la defensa en profundidad, para

limitar el impacto del compromiso inicial. Piense en escenarios en los que un atacante ha ganado
un punto de apoyo inicial, por ejemplo, soltando un shell de comando web en su servidor web de
límites. ¿Qué podrían hacer a continuación? Puede probar escenarios reales añadiéndolos a su
próxima Prueba de penetración.

si. Si su base de datos contiene principalmente datos utilizados internamente pero tiene un
subconjunto de datos disponibles externamente, considere enviar los datos externos a una base
de datos completamente separada con su propia aplicación externa. Eso evita el compromiso de la
interfaz pública que afecta los datos internos.

C. Revise la seguridad de las interfaces de administración hacia y dentro de su sistema. Los

servicios de acceso remoto con conexión a Internet deben estar adecuadamente diseñados y ser
robustos. Las redes de administración internas no deben permitir eludir los controles de seguridad
escalonados.

10. Copia de seguridad inadecuada

El robo de cintas de copia de seguridad de bases de datos y discos duros ha sido una preocupación
durante mucho tiempo, pero han surgido nuevas amenazas a la disponibilidad de datos y no
deben ignorarse.

a. Todas las copias de seguridad deben estar encriptadas para proteger la confidencialidad e
integridad de los datos, y esto debe incluir una gestión de claves adecuada. Las claves no deben
caer en las manos equivocadas, pero deben estar disponibles cuando sea necesario para restaurar
los datos.

si. Ransomware ahora apunta a los servidores y sus bases de datos, así como a las máquinas de los
usuarios. Si sus copias de seguridad están todas en línea y son accesibles a través de un recurso
compartido de archivos, por ejemplo, el ransomware las cifrará.

C. La resistencia dentro de los servicios en la nube, por ejemplo, la replicación geográfica, no es lo

mismo que la copia de seguridad. Es posible que un atacante elimine tanta infraestructura de nube
y datos de clientes que una organización no puede sobrevivir, como algunos ya han encontrado.

Asegúrese de que sus copias de seguridad no estén sujetas a las mismas amenazas que los datos
en vivo y que el compromiso total del entorno de datos en vivo tampoco puede comprometer sus
copias de seguridad. Y pruebe sus procedimientos de restauración regularmente.
Conclusión

Si sigue la guía anterior, habrá mitigado muchas amenazas a sus datos, pero lo ideal sería realizar
una evaluación de riesgos y basar sus controles en los resultados.

El Centro Nacional de Seguridad Cibernética del Reino Unido publica guías de seguridad muy
accesibles para empresas de todos los tamaños, y se recomienda leer detenidamente su sitio web.

NOSQL

A1 - 2 Inyección SQL y NoSQL

Descripción
Las inyecciones SQL y NoSQL permiten a un atacante inyectar
código en la consulta que sería ejecutada por la base de
datos. Estos defectos se introducen cuando los desarrolladores
de software crean consultas dinámicas de bases de datos que
incluyen entradas proporcionadas por el usuario.

Mecánica de ataque
Las bases de datos SQL y NoSQL son vulnerables al ataque de
inyección. Aquí hay un ejemplo de ataque equivalente en ambos
casos, donde el atacante logra recuperar el registro del usuario
administrador sin conocer la contraseña:

1. Inyección SQL

Consideremos un ejemplo de sentencia SQL utilizada para

autenticar al usuario con nombre de usuario y contraseña
SELECT * FROM accounts WHERE username = '$username' AND password = '$password'
Si esta declaración no se prepara o maneja adecuadamente
cuando se construye, un atacante puede proporcionar admin' --en
el campo de nombre de usuario para acceder a la cuenta del
usuario administrador sin pasar por la condición que verifica la
contraseña. La consulta SQL resultante se vería así:
SELECT * FROM accounts WHERE username = 'admin' -- AND password = ''
 2. Inyección NoSQL

El equivalente de la consulta anterior para la base de datos

NoSQL MongoDB es:
db.accounts.find({username: username, password: password});
Si bien aquí ya no tratamos con el lenguaje de consulta, un
atacante aún puede lograr los mismos resultados que la
inyección SQL al proporcionar el objeto de entrada JSON como
se muestra a continuación:
{
"username": "admin",
"password": {$gt: ""}
}
En MongoDB, $gtselecciona aquellos documentos donde el valor
del campo es mayor que (es decir,>) el valor especificado. Por lo
tanto, la declaración anterior compara la contraseña en la base
de datos con una cadena vacía para la grandeza, que
devuelve true.
Se pueden lograr los mismos resultados utilizando otro operador
de comparación como $ne.

¿Cómo lo prevengo?
Aquí hay algunas medidas para prevenir ataques de inyección
SQL / NoSQL, o minimizar el impacto si sucede:

 Declaraciones preparadas: para llamadas SQL, use

declaraciones preparadas en lugar de crear consultas dinámicas
utilizando la concatenación de cadenas.
 Validación de entrada: Valide las entradas para detectar
valores maliciosos. Para las bases de datos NoSQL, también
valide los tipos de entrada contra los tipos esperados
 Privilegio mínimo: para minimizar el daño potencial de un
ataque de inyección exitoso, no asigne derechos de acceso de
tipo administrador o DBA a sus cuentas de aplicación. De
manera similar, minimice los privilegios de la cuenta del sistema
operativo con la que se ejecuta el proceso de la base de datos.