Database security; SQL Injection (III)

SDB, 3, BloG - 019

SDB, 3, BloG - 020
Captura: Final (artículo) -; Database security; Diseño & conexión (I)

Database security; Diseño & conexión (I)

SDB, 3, BloG - 021
Captura 2: Final (artículo) -;Database security; Encriptación & SQL Injection (II) 😉

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

SDB, 3, BloG - 022

Ejemplo #2 <Enumerar artículos> … y algunas “contraseñas” (cualquier “servidor” de <bases de datos>) -;

<?php

$consulta  = “SELECT id, name, inserted, size FROM products
WHERE size = ‘$tamaño'”;
$resultado = odbc_exec($conexión, $consulta);

?>

La parte “estática” de la consulta se puede combinar con otra -sentencia- <SELECT> la cual revelará todas las <contraseñas> -;

'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--

Si esta consulta (jugando con y ) fuera asignada a una de las variables utilizadas en $consulta, despertaría a la consulta “monstruo”.

SDB, 3, BloG - 023.png

Las sentecias UPDATE de <SQL> también son susceptibles a ataques. Estas consultas también están amenazadas por el corte y la anteposición de una consulta completamente nueva. El atacante podría juguetear con la cláusula SET, aunque en este caso, debe poseer algo de información sobre los esquemas para manipular la consulta con éxito. Esta información puede adquirirse examinando los nombres de las variables del formulario, o sencillamente mediante la fuerza bruta. No hay muchas convenciones de nombres para campos que almacenen contraseñas o nombres de usuarios.

SDB, 3, BloG - 024

Ejemplo #3 Desde -restablecer una <contraseña>- … hasta obtener más privilegios (cualquier -servidor- de <bases de datos>) -;

<?php
$consulta = “UPDATE usertable SET pwd=’$pwd’ WHERE uid=’$uid’;”;
?>

Pero un usuario malicioso (alias; -el malote-) podría enviar el valor ‘ or uid like’%admin% a $uid para cambiar la contraseña del administrador, o simplemente cambiar $pwd a jejeje’, trusted=100, admin=’yes para obtener más privilegios. Entonces, la consulta se tornaría -;

<?php

// $uid: ‘ or uid like ‘%admin%
$consulta = “UPDATE usertable SET pwd=’…’ WHERE uid=” or uid like ‘%admin%’;”;

// $pwd: jejeje’, trusted=100, admin=’yes
$consulta = “UPDATE usertable SET pwd=’jejeje’, trusted=100, admin=’yes’ WHERE
…;”;

?>

Un ejemplo turbador de cómo se puede acceder a los <comandos> a nivel del “sistema operativo” en algunos equipos anfitriones de <bases de datos>.

SDB, 3, BloG - 025

Ejemplo #4 -Atacar el “sistema operativo” que hospeda la <base de datos> (-Servidor- <MSSQL>) -;

<?php

$consulta  = “SELECT * FROM products WHERE id LIKE ‘%$prod%'”;
$resultado = mssql_query($consulta);

?>

Si -el malote- envía el valor a%’ exec master..xp_cmdshell ‘net user test testpass /ADD’ — a $prod, la $consulta será -;

<?php

$consulta  = “SELECT * FROM products
WHERE id LIKE ‘%a%’
exec master..xp_cmdshell ‘net user test testpass /ADD’ –%'”;
$resultado = mssql_query($consulta);

?>

El servidor <MSSQL> ejecuta la -sentencia- <SQL> en el lote incluyendo un comando para añadir un usuario nuevo a la <base de datos> de cuentas local. Si esta aplicación estuviera ejecutándose como –sa- y el servicio <MSSQLSERVER> se estuviera ejecutando con los privilegios suficientes, el -malote- ahora podría tener una cuenta con la cual acceder a esta <máquina>.

Nota I: Algunos de los ejemplos citados están vinculados a un servidor de <bases de datos> específico. Esto no significa que un ataque similar sea imposible en otros productos. Su servidor de <base de datos> también podría ser vulnerable de otra manera.


 

SDB, 3, BloG - 027.png

Pese a que pueda parecer obvio que un atacante debe tener al menos algún conocimiento de arquitecturas de bases de datos para poder realizar un ataque con éxito, la obtención de esta información suele ser muy sencilla. Por ejemplo, cuando la base de datos forma parte de un software de código abierto o disponible públicamente con una instalación predefinida, dicha información se encuentra completamente libre y utilizable. Esta información podría haber sido divulgada en proyectos de código cerrado (incluso si está codificada, ofuscada o compilada), o incluso por el propio código mediante la visualización de mensajes de error. Otros métodos incluyen el uso de nombres frecuentes de tablas y columnas. Por ejemplo, un formulario de inicio de sesión que utiliza una tabla ‘usuarios’ con los nombres de columna ‘id’, ‘username’, y ‘password’.

Estos ataques se basan principalmente en explotar el código que no ha sido escrito teniendo en cuenta la seguridad. Nunca se ha de confiar en ningún tipo de entrada, especialmente la que viene del lado del cliente, aún cuando esta venga de un cuadro de selección, un campo oculto o una cookie. El primer ejemplo muestra cómo una inofensiva consulta puede causar desastres -;

  • Nunca os conectéis como superusuario o como propietario de la base de datos. Siempre utilizar usuarios personalizados con privilegios muy limitados.
  • Emplear sentencias preparadas con variables vinculadas. Son proporcionadas por PDO, MySQLi y otras bibliotecas.
  • Comprobar si la entrada proporcionada tiene el tipo de datos previsto. PHP tiene un amplio rango de funciones para validar la entrada de datos, desde las más simples, encontradas en Funciones de variables y en Funciones del tipo carácter (p.ej., is_numeric(), ctype_digit() respectivamente), hasta el soporte para Expresiones regulares compatibles con Perl.

Si la expresión espera una entrada numérica, considerar verificar los datos con la función ctype_digit(), o silenciosamente cambiar su tipo utilizando settype(), o emplear su representación numérica por medio de sprintf().


Ejemplo #5 Una forma más -segura- de componer una “consulta” para <paginación> -;

<?php

settype($índice, ‘integer’);
$consulta = “SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $índice;”;

// Observe %d en el string de formato; el uso de %s podría no tener un resultado significativo
$consulta = sprintf(“SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;”,
$índice);

?>

  • Si la capa de la base de datos no admite variables vinculadas, entrecomille cada valor no numérico proporcionado por el usuario que sea pasado a la base de datos con la función de escapado de cadenas específica de la base de datos (p.ej. mysql_real_escape_string(), sqlite_escape_string(), etc.). Las funciones genéricas como addslashes() son útiles solamente en un entorno muy específico (p.ej., MySQL en un juego de caracteres monobyte con NO_BACKSLASH_ESCAPES deshabilitada), por lo que es mejor evitarlas.
  • Sea como sea, no muestre ninguna información específica de la base de datos, especialmente sobre el esquema. Vea también Notificación de errores y Manejo de errores y funciones de registro.
  • Se pueden utilizar procedimientos almacenados y cursores previamente definidos para abstraer el acceso a datos para que los usuarios no tengan acceso directo a las tablas o vistas, aunque que esta solución tiene otros impactos.

SDB, 3, BloG - 028

Además, se puede beneficiar del registro de consultas, ya sea dentro de un script o mediante la base de datos en sí misma, si es que lo soporta. Obviamente, llevar un registro no previene los intentos dañinos, aunque puede ser útil para realizar un seguimiento de las aplicación que han sido eludidas. El registro no es útil por sí mismo, sino por la información que contiene. Normalmente cuantos más detalles, mejor }:D

Salu2


TonyHAT - 475

Anuncios

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