REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DE EDUCACIN SUPERIOR COLEGIO UNIVERSITARIO FRANCISCO DE MIRANDA MATERIA: BASE DE DATOS II MENCIN: INFORMTICA

SECCIN: 442

SEGURIDAD DE BASES DE DATOS

Integrantes: Cabrera Henry Carnet 5000543 Cedeo Rosiris Carnet 6300158 Cedeo Rosmari Carnet 6300148

Indice
Introduccin ................................ ................................ ................................ ................................ 3 Seguridad de Bases de Datos ................................ ................................ ................................ ........ 4 Diseo de Bases de Datos ................................ ................................ ................................ ............. 4 Conexin con la Base de Datos................................ ................................ ................................ ...... 5 Modelo de Almacenamiento Encriptado ................................ ................................ ....................... 5 Inyeccin de SQL................................ ................................ ................................ ........................... 6 Tcnicas de proteccin ................................ ................................ ................................ ............... 10 Recomendaciones................................ ................................ ................................ ....................... 11 Seguridad de la bases de datos de tipo PostgreSQL................................. ................................ .... 12 El manejo de roles ................................ ................................ ................................ ...................... 12 Conclusiones................................ ................................ ................................ ............................... 14

Introduccin
Todos sabemos que se debe considerar, la seguridad de la base de datos como lo ms importante en el proceso de implementar soluciones que interactuen con informacin sensible, es decir, si los sistemas de administracin base de datos(RDBMS) en la que todos confiamos implcitamente, para guardar nuestr os datos importantes, no son seguras, el impacto en nuestras vidas, y en general en nuestra sociedad podran ser devastadores. Los sistemas de base de datos son elementos TI esenciales, e importa su proteccin puesto que "informacin es poder", y el dato y su acceso es el primer componente de ese poder. La importancia de estos activos es extrema, y el impacto ante su compromiso alto, por lo que los controles de seguridad han de reducir el factor de exposicin al mnimo. En el presente documento haremos un breve repaso sobre seguridad de base de datos y como establecer ciertas restricciones en postgresql.

Seguridad de Bases de Datos

Para recuperar o almacenar cualquier informacin es necesario conectarse a la base de datos, enviar una consulta vlida, recoger el resultado y cerrar la conexin. Hoy en da, el lenguaje de consultas usado comnmente en estas interacciones es el Lenguaje de Consultas Estructurado (SQL por sus siglas en ingls). Es importante resaltar que un atacante puede intentar acometidas con una consulta SQL. Entre ms acciones tome para incrementar la proteccin de su base de datos, menor ser la probabilidad de que un atacante tenga xito, y exponga o abuse de cualquier informacin secreta que estuviera almacenada, un buen diseo del esquema de la base de datos y de la aplicacin basta para lidiar con sus mayores temores.

Diseo de Bases de Datos

El primer paso siempre es crear la base de datos, a menos que se desee usar una existente, creada por alguien ms. Cuando una base de datos es creada, sta es asignada a un dueo, quien ejecut la sentencia de creacin. Usualmente, nicamente el dueo (o un sper usuario) puede hacer cualquier cosa con los objetos de esa base de datos, y para que otros usuarios puedan usarla, deben otorgarse privilegios. Las aplicaciones nunca deberan conectarse a la base de datos bajo el usuario correspondiente a su dueo, o como un sper usuario, ya que stos usuarios pueden, por ejemplo, ejecutar cualquier consulta a su antojo, modificando el esquema (por ejemplo eliminando tablas) o borrando su contenido completo. Se pueden crear diferentes usuarios de la base de datos para cada aspecto de su aplicacin con derechos muy limitados sobre los objetos de la base de datos. Tan solo deben otorgarse los privilegios estrictamente necesarios, y evitar que el mismo usuario pueda interactuar con la base de datos en diferentes casos de uso. Esto quiere decir que si un intruso gana acceso a su base de datos usando una de stas credenciales, l solo puede efectuar tantos cambios como su aplicacin se lo permita. Es recomendable no implementar toda la lgica del asunto en la aplicacin web (es decir, en su script); en su lugar, se hace en el esquema de la base de datos usando vistas, disparadores o reglas. Si el sistema evoluciona, se espera que nuevos puertos sean abiertos a la aplicacin, y tendr que reimplementar la lgica para cada cliente de la base de datos. Por sobre todo, los disparadores pueden ser usados para gestionar de forma transparente todos los campos automticamente, lo cual con frecuencia provee informacin til cuando se depuren problemas de su aplicacin, o se realicen rastreos sobre transacciones particulares.

Conexin con la Base de Datos

Si se desea establecer las conexiones sobre SSL para encriptar las comunicaciones cliente/servidor, incrementando el nivel de seguridad, o se puede hacer uso de ssh para encriptar la conexin de red entre los clientes y el servidor de la base de datos. Si cualquiera de estos recursos es usado, entonces monitorear su trfico y adquirir informacin de esta manera ser un trabajo mas difcil.

Modelo de Almacena miento Encriptado

SSL/SSH protege los datos que viajan desde el cliente al servidor, SSL/SSH no protege los datos persistentes almacenados en la base de datos, SSL es un protocolo sobre el cable. Una vez el atacante adquiere acceso directo a la base de datos (evitando el paso por el servidor web), los datos crticos almacenados pueden estar expuestos o mal utilizados, a menos que la informacin est protegida en la base de datos. La encriptacin de datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de mecanismo de encriptacin de datos. La forma ms sencilla de evitar este problema es crear primero su propio paquete de encriptacin, y luego utilizarlo desde sus scripts de PHP. PHP puede ayudar en este caso con sus varias extensiones, como Mcrypt y Mhash, las cuales cubren una amplia variedad de algoritmos de encriptacin. El script entonces debe encriptar los datos a ser almacenados primero, y luego la decripta cuando la recupera. En el caso de datos realmente escondidos, si su representacin original no se necesita (es decir, no debe ser desplegada), los resmenes criptogrficos pueden llegar a considerarse. El ejemplo clsico de gestin de resmenes criptogrficos es el almacenamiento de secuencias MD5 de una contrasea en una base de datos, en lugar de la contrasea misma. Ejemplo 1 // almacenamiento de resumen criptografico de la contrasenya

$consulta = sprintf("INSERT VALUES('%s','%s');",

INTO

usuarios(nombre,contr)

addslashes($nombre_usuario), md5($contrasenya));

$resultado = pg_exec($conexion, $consulta);

// consulta de verificacion de la contrasenya enviada

$consulta = sprintf("SELECT 1 FROM usuarios WHERE nombre='%s' AND contr='%s';", addslashes($nombre_usuario), md5($contrasenya)); $resultado = pg_exec($conexion, $consulta);

if (pg_numrows($resultado) > 0) { echo "¡Bienvenido, $nombre_usuario!"; } else { echo "No pudo autenticarse a $nombre_usuario_"; }

Inyeccin de SQL
Muchos desarrolladores web no son conscientes de cmo pueden manipularse las consultas SQL, y asumen que una consulta SQL es un comando confiable. Esto representa que las consultas SQL pueden burlar los controles de acceso, y de este modo evitar los chequeos estndares de autenticacin y autorizacin, y a veces las consultas SQL pueden incluso permitir acceso a comandos al nivel del sistema operativo de la mquina husped. La Inyeccin Directa de Comandos SQL es una tcnica en la cual un atacante crea o altera comandos SQL existentes para exponer datos escondidos, o sobrescribir datos crticos, o incluso ejecutar comandos del sistema peligrosos en la mquina en donde se encuentra la base de datos. Esto se consigue cuando la aplicacin toma informacin de entrada del usuario y la combina con parmetros estticos para construir una consulta SQL. Los siguientes ejemplos, estn basados en historias reales: Debido a la falta de validacin de la informacin de entrada y el establecimiento de conexiones con la base de datos desde un sper usuario o

aquel que puede crear usuarios, el atacante podra crear un sper usuario en su base de datos. Ejemplo 2_ Paginacin del conjunto de resultados y creacin de super_usuarios (PostgreSQL y MySQL)

$offset = argv[0]; // atencion, no se valida la entrada! $consulta = "SELECT id, nombre FROM productos ORDER BY nombre LIMIT 20 " _ "OFFSET $offset;";

// con PostgreSQL $resultado = pg_exec($conexion, $consulta);

// con MySQL $resultado = mysql_query($consulta); Los usuarios normales pulsan sobre los enlaces 'siguiente' y 'anterior', en donde el desplazamiento ($offset) es un nmero decimal. Sin embargo, alguien puede intentar un ataque aadiendo una forma codificada (urlencode()) de lo siguiente en la URL // en el caso de PostgreSQL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select 'crack', usesysid, 't','t','crack' from pg_shadow where usename='postgres'; __

// en el caso de MySQL

0; UPDATE user SET Password=PASSWORD('crack') WHERE user='root'; FLUSH PRIVILEGES; Si esto ocurriera, entonces el script le presentara un acceso de sper usuario al atacante; Note que 0; es usado para ofrecer un desplazamiento vlido a la consulta original y finalizarla. Nota: Es una tcnica comn obligar al analizador sintctico de SQL a que ignore el resto de la consulta escrita por el desarrollador mediante, el cual es el signo de comentarios en SQL. Una forma viable de adquirir contraseas es jugar con las pginas de resultados de bsquedas. Todo lo que necesita el atacante es probar si existe alguna variable enviada por el usuario que sea usada en una sentencia SQL sin el tratamiento adecuado. Estos filtros pueden ubicarse por lo general previos a clusulas WHERE, ORDER BY, LIMIT y OFFSET en sentencias SELECT para personalizar la instruccin Si su base de datos soporta la construccin UNION, el atacante puede intentar aadir una consulta completa a la consulta original para generar una lista de contraseas desde una tabla cualquiera. El uso de campos encriptados de contraseas es altamente recomendable.

Ejemplo 3_ Listado de artculos y algunas contraseas (en cualquier base de datos) $consulta = "SELECT id, nombre, insertado, tam FROM productos WHERE tam = '$tam' ORDER BY $orden LIMIT $limite, $offset;"; $resultado = odbc_exec($conexion, $consulta); La parte esttica de la consulta puede combinarse con otra sentencia SELECT la cual revela todas las contraseas: ' union select '1', concat(uname||'_'||passwd) as name, '1971_01_01', '0' from usertable;

__ Si esta consulta (la cual juega con ' y ) fuera asignada a una de las variables usadas en $consulta, la bestia de la consulta habr despertado Las sentencias UPDATE en SQL tambin son objetivos de ataques en su base de datos. Estas consultas tambin se encuentran amenazadas por un posible acotamiento y adicin de una consulta completamente nueva. Pero en este caso el atacante puede amaar la informacin de una clusula SET. En este caso se requiere contar con cierta informacin sobre el esquema de la base de datos para poder manipular la consulta satisfactoriamente. Esta informacin puede ser adquirida mediante el estudio de los nombres de variables de los formularios, o simplemente por fuerza bruta. No existen demasiadas convenciones para nombrar campos de contraseas o nombres de usuario. Ejemplo 4_ De restablecer una contrasea a adquirir ms privilegios (con cualquier servidor de base de datos) $consulta = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';"; Pero un usuario malicioso enva el valor ' or uid like'%admin%'; como $uid para cambiar la contrasea del administrador, o simplemente establece $pwd a "hehehe', admin='yes', trusted=100 " (con un espacio al inicio) para adquirir ms privilegios. En tal caso, la consulta sera manipulada: // $uid == ' or uid like'%admin%'; __ $consulta = "UPDATE usertable SET pwd='___' WHERE uid='' or uid like '%admin%'; __";

// $pwd == "hehehe', admin='yes', trusted=100 " $consulta = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE ___;" Este es un ejemplo de cmo puede accederse a comandos del nivel del sistema operativo en algunas mquinas anfitrionas de bases de datos.

Ejemplo 5_ Ataque al sistema operativo de la mquina anfitriona de la

base de datos (MSSQL Server) $consulta = "SELECT * FROM productos WHERE id LIKE '%$prod%'"; $resultado = mssql_query($consulta);

Si el atacante enva el valor a%' exec master__xp_cmdshell 'net user test testpass /ADD' __ a $prod, entones la $consulta ser: $consulta = "SELECT * FROM productos WHERE id LIKE '%a%' exec master__xp_cmdshell 'net user test testpass /ADD'__"; $resultado = mssql_query($consulta);

MSSQL Server ejecuta sentencias SQL en el lote, incluyendo un comando para agregar un nuevo usuario a la base de datos de cuentas locales. Si esta aplicacin estuviera corriendo como sa y el servicio MSSQLSERVER est corriendo con los privilegios suficientes, el atacante tendra ahora una cuenta con la que puede acceder a esta mquina. Nota: Algunos de los ejemplos anteriores estn atados a un servidor de base de datos especfico. Esto no quiere decir que un ataque similar sea imposible con otros productos. Su base de datos puede ser tanto o ms vulnerable en otras formas distintas.

Tcnicas de proteccin
Usted puede argumentar con justa razn que el atacante debe poseer cierta cantidad de informacin sobre el esquema de la base de datos en la mayora de ejemplos que hemos visto. Tiene razn, pero nunca se sabe cundo y cmo puede filtrarse esta informacin, y si ocurre, la base de datos estar expuesta. Si se est usando un paquete de gestin de bases de datos de cdigo abierto, o cuyo cdigo fuente est disponible pblicamente, el cual puede pertenecer a algn sistema de administracin de contenido o foro, los intrusos pueden producir fcilmente una copia de un trozo de cdigo. Tambin puede ser un riesgo de seguridad si es un segmento de cdigo pobremente diseado. Estos ataques se basan principalmente en la explotacin del cdigo que no ha sido escrito pensando en la seguridad. Nunca se debe confiar en ningn tipo de informacin de entrada, especialmente si proviene del lado del cliente, aun si lo hace desde una caja de seleccin, un campo de entrada hidden o una cookie. El primer ejemplo le muestra que una consulta as de descuidada puede causar desastres.

Recomendaciones
Nunca se debe conectar a la base de datos como un sper usuario o como el dueo de la base de datos. Es recomendable usar siempre usuarios personalizados con privilegios muy limitados. Se debe revisar si la entrada recibida es del tipo apropiado. PHP posee un amplio rango de funciones de validacin de datos, desde los ms simples encontrados en Funciones sobre variables y en funciones de tipo de caracter (ejemplo is_numeric(), ctype_digit() respectivamente) hasta el soporte para expresiones regulares compatibles con Perl. Si la aplicacin espera alguna entrada numrica, es necesario considerar verificar la informacin con is_numeric(), o modificar silenciosamente su tipo usando settype(), o utilizando su representacin numrica, dada por sprintf(). Ejemplo 6_ Una forma ms segura de generar una consulta para paginado settype($offset, 'integer'); $consulta = "SELECT id, nombre FROM productos ORDER BY nombre " _ "LIMIT 20 OFFSET $offset;";

// note el simbolo %d en la cadena de formato, usar %s no tendria sentido $consulta = sprintf("SELECT id, nombre FROM productos ORDER BY nombre" _ "LIMIT 20 OFFSET %d;", $offset); Ubique cada entrada del usuario no numrica que sea pasada a la base de datos entre comillas con addslashes() o addcslashes(). Vea el primer ejemplo, como se ve all, las comillas colocadas en la parte esttica de la consulta no son suficientes, y pueden ser manipuladas fcilmente. No se imprime ninguna informacin especfica sobre la base de datos, especialmente sobre su esquema, ya sea por razones justas o por equivocaciones. Vea tambin reporte de errores y gestin de errores y funciones de registro. Se pueden usar procedimientos almacenados y cursores previamente definidos para abstraer el acceso a las bases de datos, de modo que los usuarios no tengan acceso directo a las tablas o vistas, aunque esta solucin tiene otros impactos.

Adems de estas acciones, es posible beneficiarse del registro explcito de las consultas realizadas, ya sea desde su script o por la base de datos misma, si sta lo soporta. Por supuesto, el registro de acciones no puede prevenir cualquier intento peligroso, pero puede ser til para rastrear cules aplicaciones han sido usadas para violar la seguridad. El registro en s no es til; lo es la informacin que contiene. Entre ms detalles se tengan, por lo general es mejor.

Seguridad de la bases de datos de tipo PostgreSQL.

La seguridad de las bases de datos es un aspecto prioritario de su manejo. En el pasado se ha contado con sistemas de bases de datos funcionales, que han dejado de utilizarse despus de comprobar lo vulnerable que eran a ser accedidas por usuarios n o autorizados. Por el ejemplo, el caso de bases de sistemas FoxPro 2.0 que podan accederse y modificarse usando aplicaciones de Excel 2000. Para mejorar la seguridad entorno a una base de datos se puede recurrir a varios medios:
a) Restricciones propias del entorno de red para su acceso remoto. Esto puede implicar limitar la cantidad de servicios en el servidor y los protocolos por los cuales se pueda tener acceso a l. A pesar de que se puedan restringir el uso de carpetas compartidas en el servidor, cuando la base es parte de un servicio Web o un servicio sobre una intranet, generalmente se dejan abiertos los puertos para el servicio FTP. Sin embargo se puede limitar este servicio nicamente para el uso del Webmaster y hacia dire ctorios no relacionados directamente con la base de datos. b) Dentro de una aplicacin Web tambin se pueden imponer ciertas medidas de seguridad. Se puede omitir el uso de Telnet y en su lugar usar una aplicacin como pgAdmin para acceder a la base de da tos. La aplicacin Web, puede incluir un sistema de validacin que incluya la identificacin del usuario, y manejar una tabla de usuarios con funciones restringidas, lo cual implicara limitar la cantidad de paginas Web o aplicaciones basadas en PHP a que cada usuario puede tener acceso, o sobre que datos tiene derecho de lectura o escritura. c) Restricciones de seguridad impuestas por el propio gestor de postgresql: En determinado momento la base de datos puede ser accesible para varios usuarios, pero cada uno puede tener un perfil diferente de privilegios que limiten su capacidad de accin. Es justamente en torno a este tipo de restricciones que se enfocara esta seccin del curso.

El manejo de roles

A diferencia de Mysql, PostgreSQL no tiene una tabla e specfica en que se almacenen datos de los usuarios. En su lugar usa una categora diferente de objetos llamados roles. Existen los llamados Group Roles y los Login roles. Se puede administrar una base de datos de este tipo sin Group Roles (roles de grupo) pero es necesario contar con al menos un role para logear al sistema. Al examinar las propiedades del Role root se observa lo siguiente:

Aun para un nefito, es evidente que se pueden configurar privilegios, o hacer cambios de password sobre e l rol, en una situacin similar al manejo de usuarios que se hace en otros tipos de bases de datos. Para crear un nuevo rol se puede recurrir a dos medios:
a) Usar el men contextual que aparece al hacer clic derecho sobre el objeto Roles en pgAdmin, y proceder a llenar los cuadros de dilogos que aparezcan. b) Usar el comando de SQL CREATE ROLE, de acuerdo a la siguiente sintaxis:

CREATE ROLE name; Para eliminar un role se puede utilizar el comando DROPE ROLE. Tambin es posible consultar lo roles existentes mediante el uso del comando SELECT.

El manejo de grupos de roles es una forma de conceder o limitar privilegios a todo un grupo de personas en lugar de manejar privilegios individuales. Al hacer clic derecho sobre el objeto Group roles, aparece el siguiente cuadro de dialogo.

Puede observarse que las propiedades son las similares que para un role ordinario, con la diferencia de que una vez establecidas para un grupo, cualquier nuevo rol que se incluya dentro de este grupo

(en la pestaa role me mbreship) heredara los privilegios y restricciones del grupo. Ya que las tablas y los roles no se crean simultneamente, se puede optar por conceder ciertos privilegios a algunos roles nuevos mucho despus de haber creado una tabla, o crear una tabla especfica sobre al cual se conceden privilegios a roles previamente existentes. Si se hace clic derecho sobre un objeto schema o un objeto table aparecer el men contextual que incluye la opcin Grant Wizard, mediante la cual es posible conceder privilegios sobre estos objetos a los roles.

En la primera pestaa del cuadro de dialogo que aparece al elegir Grant Wizard, se observaran las tablas sobre las cuales es posible conceder privilegios.

En la pestaa contigua se especifican los privilegios concedid os para cada uno de los roles disponibles:

Como es de esperarse, si bien esta es una forma bastante simple de conceder o negar privilegios, para el usuario de PostgreSQL que no cuente con PgAdmin, siempre existe la posibilidad de usar los comandos GRANT y REVOKE de SQL mediante los cuales es posible llevar a cabo la administracin de privilegios. La sintaxis de GRANT es: GRANT privilegio ON objeto TO role. Por ejemplo: GRANT UPDATE ON accounts TO joe; Los privilegios que pueden concederse o revocarse son: SELECT , INSERT, UPDATE , DELETE , RULE, REFERENCES , TRIGGER , CREATE , TEMPORARY , EXECUTE , y USAGE. El quitar privilegios a un usuario es una necesidad, ya que existen usuarios que en un momento dado dejan de trabajar para la empresa, o que sufren cambios de funciones en los cuales es ms

conveniente la revocacin de ciertos privilegios. La sintaxis de REVOKE es: REVOKE privilegio ON objeto FROM role. Por ejemplo, para revocar todos los privilegios de un rol: REVOKE ALL ON accounts FROM PUBLIC; GRANT y REVOKE tambin pueden usarse para incluir o no a un role dentro de un grupo, de acuerdo a la siguiente sintaxis: GRANT group_role TO role1, ... ; REVOKE group_role FROM role1, ... ;

Conclusiones

La seguridad de base de datos, consiste en las acciones que toma el diseador de la misma al momento de crear la base de datos, tomando en cuenta el volumen de las transacciones y las restricciones que tiene que especificar en el acceso a los datos; esto permitir que el usuario adecuado sea quin visualice la informacin adecuada. Partiendo de esta premisa, debemos tener en cuenta todas las acciones a ser tomadas en cada uno de los niveles de acceso de la misma al momento de disear y modelar la base de datos con el fin de hacerla mas ro busta y minimizar los riesgos de accesos no autorizados a ella. Debemos tomar en cuenta, que mientras ms acciones realicemos en pro de hacer menos vulnerable la base de datos, los riesgos de acciones en su contra se minimizaran. Con esto no se quiere decir que ser una base de datos 100% segura, pero las perdidas de datos y accesos no autorizados sern mucho menores.