seguridad bases de datos de tipo postgresql

5/7/2018 SEGURIDAD Bases de Datos de Tipo PostgreSQL - slidepdf.com

http://slidepdf.com/reader/full/seguridad-bases-de-datos-de-tipo-postgresql 1/20

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DE EDUCACIÓN SUPERIOR

COLEGIO UNIVERSITARIO FRANCISCO DE MIRANDA

MATERIA: BASE DE DATOS II

MENCIÓN: INFORMÁTICA

SECCIÓN: 442

SEGURIDAD DE BASES DE DATOS

Integrantes:

Cabrera Henry Carnet 5000543

Cedeño Rosiris Carnet 6300158

Cedeño Rosmari Carnet 6300148



Indice

Introducción ................................ ................................ ................................ ................................ 3 Seguridad de Bases de Datos ................................ ................................ ................................ ........ 4

Diseño de Bases de Datos ................................ ................................ ................................ ............. 4

Conexión con la Base de Datos................................ ................................ ................................ ...... 5

Modelo de Almacenamiento Encriptado ................................ ................................ ....................... 5

Inyección de SQL ................................ ................................ ................................ ........................... 6

Técnicas de protección ................................ ................................ ................................ ............... 10

Recomendaciones ................................ ................................ ................................ ....................... 11

Seguridad de la bases de datos de tipo PostgreSQL. ................................ ................................ .... 12

El manejo de roles ................................ ................................ ................................ ...................... 12

Conclusiones ................................ ................................ ................................ ............................... 14



Introducción

Todos sabemos que se debe considerar, la seguridad de la basede datos como lo más importante en el proceso de implementar soluciones que interactuen con información sensible, es decir, si lossistemas de administración base de datos(RDBMS) en la que todosconfiamos implícitamente, para guardar nuestros datos importantes, noson seguras, el impacto en nuestras vidas, y en general en nuestrasociedad podrían ser devastadores.

Los sistemas de base de datos son elementos TI esenciales, eimporta su protección puesto que "información es poder", y el dato y suacceso es el primer componente de ese poder. La importancia de estosactivos es extrema, y el impacto ante su compromiso alto, por lo quelos controles de seguridad han de reducir el factor de exposición almínimo.

En el presente documento haremos un breve repaso sobreseguridad de base de datos y como establecer ciertas restricciones enpostgresql.



Seguridad de Bases de Datos

Para recuperar o almacenar cualquier información es necesarioconectarse a la base de datos, enviar una consulta válida, recoger el resultado ycerrar la conexión. Hoy en día, el lenguaje de consultas usado comúnmente enestas interacciones es el Lenguaje de Consultas Estructurado (SQL por sus

siglas en inglés). Es importante resaltar que un atacante puede intentar acometidas con una consulta SQL.

Entre más acciones tome para incrementar la protección de su base dedatos, menor será la probabilidad de que un atacante tenga éxito, y exponga oabuse de cualquier información secreta que estuviera almacenada, un buendiseño del esquema de la base de datos y de la aplicación basta para lidiar consus mayores temores.

Diseño de Bases de Datos

El primer paso siempre es crear la base de datos, a menos que se deseeusar una existente, creada por alguien más. Cuando una base de datos escreada, ésta es asignada a un dueño, quien ejecutó la sentencia de creación.Usualmente, únicamente el dueño (o un súper usuario) puede hacer cualquier cosa con los objetos de esa base de datos, y para que otros usuarios puedanusarla, deben otorgarse privilegios.

Las aplicaciones nunca deberían conectarse a la base de datos bajo elusuario correspondiente a su dueño, o como un súper usuario, ya que éstosusuarios pueden, por ejemplo, ejecutar cualquier consulta a su antojo,modificando el esquema (por ejemplo eliminando tablas) o borrando sucontenido completo.

Se pueden crear diferentes usuarios de la base de datos para cadaaspecto de su aplicación 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 dedatos 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 puedeefectuar tantos cambios como su aplicación se lo permita.

Es recomendable no implementar toda la lógica del asunto en laaplicación 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 aplicación, y tendrá quereimplementar la lógica para cada cliente de la base de datos. Por sobre todo,los disparadores pueden ser usados para gestionar de forma transparente todoslos campos automáticamente, lo cual con frecuencia provee información útilcuando se depuren problemas de su aplicación, o se realicen rastreos sobretransacciones particulares.



Conexión con la Base de Datos

Si se desea establecer las conexiones sobre SSL para encriptar lascomunicaciones cliente/servidor, incrementando el nivel de seguridad, o se

puede hacer uso de ssh para encriptar la conexión de red entre los clientes y elservidor de la base de datos. Si cualquiera de estos recursos es usado, entoncesmonitorear su tráfico y adquirir información de esta manera será un trabajomas difícil.

Modelo de Almacenamiento 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 (evitandoel paso por el servidor web), los datos críticos almacenados pueden estar expuestos o mal utilizados, a menos que la información esté protegida en la

base de datos. La encriptación de datos es una buena forma de mitigar estaamenaza, pero muy pocas bases de datos ofrecen este tipo de mecanismo deencriptación de datos.

La forma más sencilla de evitar este problema es crear primero su

propio paquete de encriptación, y luego utilizarlo desde sus scripts de PHP.PHP puede ayudar en este caso con sus varias extensiones, como Mcrypt yMhash, las cuales cubren una amplia variedad de algoritmos de encriptación.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 representación original

no se necesita (es decir, no debe ser desplegada), los resúmenes criptográficos pueden llegar a considerarse. El ejemplo clásico de gestión de resúmenescriptográficos es el almacenamiento de secuencias MD5 de una contraseña enuna base de datos, en lugar de la contraseña misma.

Ejemplo 1

// almacenamiento de resumen criptografico de la contrasenya

$consulta = sprintf("INSERT INTO usuarios(nombre,contr)VALUES('%s','%s');",

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));


if (pg_numrows($resultado) > 0) {

echo "¡Bienvenido, $nombre_usuario!";

}

else {

echo "No pudo autenticarse a $nombre_usuario_";

}

Inyección de SQL

Muchos desarrolladores web no son conscientes de cómo puedenmanipularse las consultas SQL, y asumen que una consulta SQL es uncomando confiable. Esto representa que las consultas SQL pueden burlar loscontroles de acceso, y de este modo evitar los chequeos estándares deautenticación y autorización, y a veces las consultas SQL pueden incluso

permitir acceso a comandos al nivel del sistema operativo de la máquinahuésped.

La Inyección Directa de Comandos SQL es una técnica en la cual unatacante crea o altera comandos SQL existentes para exponer datosescondidos, o sobrescribir datos críticos, o incluso ejecutar comandos delsistema peligrosos en la máquina en donde se encuentra la base de datos. Estose consigue cuando la aplicación toma información de entrada del usuario y lacombina con parámetros estáticos para construir una consulta SQL. Lossiguientes ejemplos, están basados en historias reales:

Debido a la falta de validación de la información de entrada y elestablecimiento de conexiones con la base de datos desde un súper usuario o



aquel que puede crear usuarios, el atacante podría crear un súper usuario en su base de datos.

Ejemplo 2_ Paginación del conjunto de resultados y creación de

super_usuarios (PostgreSQL y MySQL)

$offset = argv[0]; // atencion, no se valida la entrada!

$consulta = "SELECT id, nombre FROM productos ORDER BY nombreLIMIT 20 " _

"OFFSET $offset;";

// con PostgreSQL


// con MySQL

$resultado = mysql_query($consulta);

Los usuarios normales pulsan sobre los enlaces 'siguiente' y 'anterior',

en donde el desplazamiento ($offset) es un número decimal. Sin embargo,alguien puede intentar un ataque añadiendo 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 presentaría un acceso de súper

usuario al atacante; Note que 0; es usado para ofrecer un desplazamientoválido a la consulta original y finalizarla.

Nota: Es una técnica común obligar al analizador sintáctico de SQL aque ignore el resto de la consulta escrita por el desarrollador mediante, el cuales el signo de comentarios en SQL.

Una forma viable de adquirir contraseñas es jugar con las páginas deresultados de búsquedas. Todo lo que necesita el atacante es probar si existealguna variable enviada por el usuario que sea usada en una sentencia SQL sin

el tratamiento adecuado. Estos filtros pueden ubicarse por lo general previos acláusulas WHERE, ORDER BY, LIMIT y OFFSET en sentencias SELECT

para personalizar la instrucción Si su base de datos soporta la construcciónUNION, el atacante puede intentar añadir una consulta completa a la consultaoriginal para generar una lista de contraseñas desde una tabla cualquiera. Eluso de campos encriptados de contraseñas es altamente recomendable.

Ejemplo 3_ Listado de artículos y algunas contraseñas (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 estática de la consulta puede combinarse con otra sentencia

SELECT la cual revela todas las contraseñas:

'

union select '1', concat(uname||'_'||passwd) as name, '1971_01_01', '0' fromusertable;



__

Si esta consulta (la cual juega con ' y ) fuera asignada a una de lasvariables usadas en $consulta, la bestia de la consulta habrá despertado

Las sentencias UPDATE en SQL también son objetivos de ataques en

su base de datos. Estas consultas también se encuentran amenazadas por un posible acotamiento y adición de una consulta completamente nueva. Pero en

este caso el atacante puede amañar la información de una cláusula SET. Eneste caso se requiere contar con cierta información sobre el esquema de la base

de datos para poder manipular la consulta satisfactoriamente. Esta información puede ser adquirida mediante el estudio de los nombres de variables de los

formularios, o simplemente por fuerza bruta. No existen demasiadasconvenciones para nombrar campos de contraseñas o nombres de usuario.

Ejemplo 4_ De restablecer una contraseña a adquirir más privilegios (con

cualquier servidor de base de datos)

$consulta = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";

Pero un usuario malicioso envía el valor ' or uid like'%admin%'; como$uid para cambiar la contraseña del administrador, o simplemente establece$pwd a "hehehe', admin='yes', trusted=100 " (con un espacio al inicio) paraadquirir más privilegios. En tal caso, la consulta sería 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=100WHERE ___;"

Este es un ejemplo de cómo puede accederse a comandos del nivel delsistema operativo en algunas máquinas anfitrionas de bases de datos.

Ejemplo 5_ Ataque al sistema operativo de la máquina anfitriona de la



base de datos (MSSQL Server)

$consulta = "SELECT * FROM productos WHERE id LIKE '%$prod%'";

$resultado = mssql_query($consulta);

Si el atacante envía 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 uncomando para agregar un nuevo usuario a la base de datos de cuentas locales.Si esta aplicación estuviera corriendo como sa y el servicio MSSQLSERVER está corriendo con los privilegios suficientes, el atacante tendría ahora unacuenta con la que puede acceder a esta máquina.

Nota: Algunos de los ejemplos anteriores están atados a un servidor de base de datos específico. Esto no quiere decir que un ataque similar seaimposible con otros productos. Su base de datos puede ser tanto o más

vulnerable en otras formas distintas.

Técnicas de protección

Usted puede argumentar con justa razón que el atacante debe poseer cierta cantidad de información sobre el esquema de la base de datos en lamayoría de ejemplos que hemos visto. Tiene razón, pero nunca se sabe cuándoy cómo puede filtrarse esta información, y si ocurre, la base de datos estaráexpuesta. Si se está usando un paquete de gestión de bases de datos de códigoabierto, o cuyo código fuente está disponible públicamente, el cual puede

pertenecer a algún sistema de administración de contenido o foro, los intrusos pueden producir fácilmente una copia de un trozo de código. También puede

ser un riesgo de seguridad si es un segmento de código pobremente diseñado.

Estos ataques se basan principalmente en la explotación del código queno ha sido escrito pensando en la seguridad. Nunca se debe confiar en ningúntipo de información de entrada, especialmente si proviene del lado del cliente,aun si lo hace desde una caja de selección, un campo de entrada hidden o unacookie. El primer ejemplo le muestra que una consulta así de descuidada

puede causar desastres.



R ecomendaciones

Nunca se debe conectar a la base de datos como un súper usuario ocomo el dueño 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 poseeun amplio rango de funciones de validación de datos, desde los más simplesencontrados en Funciones sobre variables y en funciones de tipo de caracter (ejemplo is_numeric(), ctype_digit() respectivamente) hasta el soporte paraexpresiones regulares compatibles con Perl.

Si la aplicación espera alguna entrada numérica, es necesario considerar

verificar la información con is_numeric(), o modificar silenciosamente su tipousando settype(), o utilizando su representación numérica, dada por sprintf().

Ejemplo 6_ Una forma más 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 numérica que sea pasada a la basede datos entre comillas con addslashes() o addcslashes(). Vea el primer

ejemplo, como se ve allí, las comillas colocadas en la parte estática de laconsulta no son suficientes, y pueden ser manipuladas fácilmente.

No se imprime ninguna información específica sobre la base de datos,especialmente sobre su esquema, ya sea por razones justas o por

equivocaciones. Vea también reporte de errores y gestión de errores yfunciones de registro.

Se pueden usar procedimientos almacenados y cursores previamentedefinidos para abstraer el acceso a las bases de datos, de modo que los usuariosno tengan acceso directo a las tablas o vistas, aunque esta solución tiene otrosimpactos.



Además de estas acciones, es posible beneficiarse del registro explícitode 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 cuálesaplicaciones han sido usadas para violar la seguridad. El registro en sí no esútil; lo es la información que contiene. Entre más 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 desu manejo. En el pasado se ha contado con sistemas de bases dedatos funcionales, que han dejado de utilizarse después de comprobar lo vulnerable que eran a ser accedidas por usuarios no autorizados.Por el ejemplo, el caso de bases de sistemas FoxPro 2.0 que podíanaccederse 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 directorios no relacionados directamente con la base

de datos.b) Dentro de una aplicación Web también se pueden imponer ciertas medidas de

seguridad. Se puede omitir el uso de Telnet y en su lugar usar una aplicación

como pgAdmin para acceder a la base de da tos. La aplicación Web, puede incluir

un sistema de validación que incluya la identificación del usuario, y manejar una

tabla de usuarios con funciones restringidas, lo cual implicaría 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 acción. Es justamente en torno a este tipo de restricciones que se

enfocara esta sección del curso.

El manejo de roles



A diferencia de Mysql, PostgreSQL no tiene una tabla e specíficaen que se almacenen datos de los usuarios. En su lugar usa unacategoría diferente de objetos llamados roles. Existen los llamadosGroup Roles y los Login roles. Se puede administrar una base de datosde 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 losiguiente:



Aun para un neófito, es evidente que se pueden configurar privilegios, o hacer cambios de password sobre el rol, en una situaciónsimilar al manejo de usuarios que se hace en otros tipos de bases dedatos.

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 diálogos 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 DROPEROLE. También 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 privilegiosindividuales. Al hacer clic derecho sobre el objeto Group roles, apareceel siguiente cuadro de dialogo.

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



(en la pestaña role membreship) heredara los privilegios y restriccionesdel grupo.

Ya que las tablas y los roles no se crean simultáneamente, sepuede optar por conceder ciertos privilegios a algunos roles nuevosmucho después de haber creado una tabla, o crear una tabla

específica sobre al cual se conceden privilegios a roles previamenteexistentes. Si se hace clic derecho sobre un objeto schema o un objetotable aparecerá el menú contextual que incluye la opción Grant Wizard,mediante la cual es posible conceder privilegios sobre estos objetos alos roles.

En la primera pestaña del cuadro de dialogo que aparece alelegir Grant Wizard, se observaran las tablas sobre las cuales esposible conceder privilegios.



En la pestaña contigua se especifican los privilegios concedid ospara cada uno de los roles disponibles:



Como es de esperarse, si bien esta es una forma bastantesimple de conceder o negar privilegios, para el usuario de PostgreSQLque no cuente con PgAdmin, siempre existe la posibilidad de usar loscomandos GRANT y REVOKE de SQL mediante los cuales es posiblellevar a cabo la administración 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 queexisten usuarios que en un momento dado dejan de trabajar para laempresa, o que sufren cambios de funciones en los cuales es más



conveniente la revocación de ciertos privilegios. La sintaxis deREVOKE 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 también pueden usarse para incluir o no a un roledentro de un grupo, de acuerdo a la siguiente sintaxis:

GRANT group_rol e TO rol e1, ... ; REVOKE group_rol e FROM rol e1, ...;



Conclusiones

La seguridad de base de datos, consiste en las acciones que toma el

diseñador 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 quién visualice la información 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 diseñar y modelar la base

de datos con el fin de hacerla mas robusta y minimizar los riesgos de accesos

no autorizados a ella.

Debemos tomar en cuenta, que mientras más 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

serán mucho menores.

seguridad bases de datos de tipo postgresql

Documents