Database security; Encriptación & SQL Injection (II)

SDB, 2, BloG - 010

SDB, 2, BloG - 011.png
Captura 1: Final (artículo) -; Database security; Diseño & conexión (I) 🙂

SDB, 2, BloG - 012

Continuamos por donde nos quedamos (podéis revisar, si os apetece, el <anterior artículo> haciendo “clic” en -artículo-), cap. superior 😉

SDB, 2, BloG - 013

SSL/SSH protege los datos que viajan desde el cliente al servidor: SSL/SSH no protege los datos persistentes almacenados en una base de datos. SSL es un protocolo que protege los datos mientras viajan por el cable.

SDB, 2, BloG - 014

Una vez que el “malote” (atacante) obtiene acceso directo a una base de datos (eludiendo el servidor web), los datos sensibles almacenados podrían ser divulgados o mal utilizados, a menos que la información esté protegida por la base de datos misma. Encriptar los datos es una buena forma de mitigar esta amenaza, pero muy pocas bases de datos ofrecen este tipo de encriptación de datos.

SDB, 2, BloG - 015

La forma más sencilla para evitar este problema es crear primero un paquete de encriptación propio y utilizarlo en los scripts de PHP. Hay muchas extensiones de PHP que pueden ser de ayuda para esto, tales como Mcrypt y Mhash, cubriendo así una amplia variedad de algoritmos de encriptación. El script encripta los datos antes de insertarlos en la base de datos, y los desencripta al obtenerlos.

En caso de datos que deban estar realmente ocultos, si no fuera necesaria su representación real, (es decir, que no sean mostrados), quizás convenga utilizar algoritmos hash. El ejemplo más típico del uso del hash es a la hora de almacenar el hash criptográfico de una contraseña en una base de datos, en lugar de almacenar la contraseña en sí.

SDB, 2, BloG - 016

Muchos desarrolladores web no son conscientes de cómo las consultas SQL pueden ser manipuladas, y asumen que una consulta SQL es una orden fiable. Esto significa que las consultas SQL son capaces de eludir controles de acceso, evitando así las comprobaciones de autenticación y autorización estándar, e incluso algunas veces, que las consultas SQL podrían permitir el acceso a comandos al nivel del sistema operativo del equipo anfitrión.

La inyección directa de comandos SQL es una técnica donde un atacante crea o altera comandos SQL existentes para exponer datos ocultos, sobrescribir los valiosos, o peor aún, ejecutar comandos peligrosos a nivel de sistema en el equipo que hospeda la base de datos. Esto se logra a través de la práctica de tomar la entrada del usuario y combinarla con parámetros estáticos para elaborar una consulta SQL. Los siguientes ejemplos están basados en historias reales, desafortunadamente.

SDB, 2, BloG - 017

Debido a la falta de validación en la entrada de datos y a la conexión a la base de datos con privilegios de superusuario o de alguien con privilegios para crear usuarios, el atacante podría crear un superusuario en la base de datos.

Ejemplos -;

Ejemplo #1 -; Dividir el conjunto de resultados en páginas … y crear superusuarios (PostgreSQL) -;

<?php

$índice    = $argv[0]; // ¡Cuidado, no hay validación en la entrada de datos!
$consulta  = “SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $índice;”;
$resultado = pg_query($conexión, $consulta);

?>

Un usuario común hace clic en los enlaces ‘siguiente’ o ‘atrás’ donde el $índice está codificado en el URL. El script espera que el $índice entrante sea un número décimal. Sin embargo, ¿qué pasa si alguien intenta irrumpir anteponiendo a la URL algo como lo siguiente empleando urlencode()?

0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
    select 'crack', usesysid, 't','t','crack'
    from pg_shadow where usename='postgres';
--

Si esto sucediera, el script podría otrogar un acceso de superusuario al atacante. Observad que 0; es para proveer un índcie válido a la consulta original y así finalizarla.

Nota I: Es una técnica común forzar al analizador de SQL a ignorar el resto de la consulta escrita por el desarrollador con , lo cual representa un comentario en SQL.

Una forma factible de obtener contraseñas es burlar las páginas de búsqueda de resultados. Lo único que el atacante necesita hacer es ver si hay variables que hayan sido enviadas y sean empleadas en sentencias SQL que no sean manejadas apropiadamente. Estos filtros se pueden establecer comunmente en un formulario anterior para personalizar las cláusulas WHERE, ORDER BY, LIMIT y OFFSET en las sentencias SELECT. Si la base de datos admite el constructor UNION, el atacante podría intentar anteponer una consulta entera a la consulta original para enumerar las contraseñas de una tabla arbitraria. Se recomienda encarecidamente utilizar campos de contraseña encriptadas.

Hasta aquí la <segunda parte>, continuaremos con más -ejemplos- en el <próximo artículo> 😉

Salu2


TonyHAT - 474

Anuncios

Un comentario en “Database security; Encriptación & SQL Injection (II)”

  1. Hola Tony, espero estés bien! 😉 SQL es una cuenta pendiente ya que cuando tuve unas clases en Operador GNU/Linux el profe ni sabía instalarlo en Debian, algún día tendría que estudiar algo de esto. Alguna recomendación autodidacta? Gracias!

    Le gusta a 1 persona

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s