Cómo hackear un sitio web usando SQL u otro método La tecnología cambia la vida futura

Es bastante fácil hackear un sitio web y / o un servidor de base de datos si se cumplen estas condiciones:

La aplicación accede a la base de datos utilizando el contexto de seguridad del administrador o la cuenta raíz. (terriblemente común)
El sitio usa SQL dinámico y desarrolla su consulta usando la entrada de formulario web, como en:

var = “SI EXISTE (SELECCIONE * de los usuarios
WHERE username = ‘”+ # form.usernam # +
“‘Y contraseña ='” + # form.password # + “‘)”

EJECUTAR var

// si la consulta tiene éxito, deje que esta persona ingrese a su sitio web

El código exacto anterior variará dependiendo de la elección del idioma del servidor web y la base de datos, pero el concepto es el mismo. Hay algunos problemas con este código SQL.

Primero y ante todo, el hecho de que es dinámico y concatena alegremente la entrada del usuario y la fuerza al servidor db. Pero, ¿qué pasa si soy un usuario maligno y lo ingresé en el campo de nombre de usuario:

‘OR 1 = 1; –

El apóstrofe inicial ‘termina la primera mitad de la cláusula where como username =’ ‘ , que no debería devolver ninguna fila, pero OR 1 = 1 seguido del punto y coma (ejecute este código ahora) seguido de la secuencia de comentarios – (dos guiones) garantiza que se ignore el resto del SQL dinámico. Resultado: se devuelven todas las filas y la consulta se realiza correctamente.

Una forma aún más simple de ingresar al sitio anterior es ingresar un solo carácter comodín SQL % en los campos de nombre de usuario y contraseña. Esto garantiza que el sql dinámico devolverá todas las filas de la tabla de usuarios, pasando así la prueba IF EXISTS.

Lo que me lleva a mi segundo punto, a saber, que IF EXISTS es una mala elección para esta aplicación porque prueba una o más filas. Las credenciales de inicio de sesión válidas deberían generar una y solo una fila , por lo que querrá establecer una variable, digamos filas , en el número de filas devueltas por la consulta y probar algo como esto:

si filas == 0
echo “Ingreso inválido, intente nuevamente”
elseif filas == 1
// déjalos entrar a tu sitio
elseif filas> 1
echo ‘Inicio de sesión fallido “.
// alerta a un administrador del sistema, registra la dirección IP del usuario, etc.
terminara si

Ahora, esto ni siquiera es lo peor que puede pasar. Ampliando nuestro ejemplo de entrada de formulario malvado, no hay nada que impida que este hacker ingrese esto en el campo de nombre de usuario:

‘OR 1 = 1; HAGA ALGO MALO COMO RECIBIRSE A LA LÍNEA DE MANDO DEL SERVIDOR DB Y ELIMINAR LAS COSAS –

Mejores prácticas para mitigar el riesgo de ataques de inyección SQL:

Otorgue a la cuenta anónima del servidor web los permisos mínimos necesarios para ejecutar su aplicación y servir páginas.
Asimismo, otorgue a esta cuenta los permisos mínimos en la base de datos a la que necesita conectarse: solo aquellas tablas, columnas, vistas y procedimientos almacenados que necesita, y considere qué acceso específico es apropiado (SELECCIONAR, INSERTAR, ACTUALIZAR, ELIMINAR, CREAR, ALTERAR , DROP, etc.) y use las declaraciones GRANT y REVOKE según sea necesario para minimizar su superficie de ataque.
Nunca use SQL dinámico. Utilizar procedimientos almacenados siempre que procesa campos de formulario que un usuario ingresó y simplemente pasa los valores del formulario como argumentos al procedimiento almacenado. Incluso si el hacker intenta pasarle un código SQL malicioso, el procedimiento almacenado procesará cada campo como texto tonto. Esto es especialmente importante cuando se trata de nombres del mundo real en campos de formulario como O’Reilly o d’Amato.
Para la visualización de datos de solo lectura, considere usar una VISTA solo con las columnas que la aplicación web necesita ver. Esto crea un control de acceso aún más detallado, pero también agrega una capa útil de abstracción: si las reglas de su negocio cambian, simplemente redefina la vista en el cambio de regla instantáneo db y * voila * sin tener que buscar todo el código de la aplicación que hace referencia a la tabla modifique la cláusula WHERE de cada uno porque la VISTA en la base de datos es donde vive la cláusula WHERE. Entonces, el código de su aplicación solo necesita enviar algo como SELECT * FROM ListActiveUsers y en la base de datos crearías tu vista así:

CREAR VISTA ListActiveUsers AS
SELECCIONAR * DE usuarios
ORDENAR POR apellido, nombre

Y ahora, supongamos que su sitio pasa de un modelo gratuito a uno de suscripción y cada cuenta de usuario tiene una caducidad asociada. Simplemente redefine la vista de la siguiente manera y listo:

CREAR VISTA ListActiveUsers AS
SELECCIONAR * DE usuarios
DONDE expdate> getdate ()
ORDENAR POR apellido, nombre

Si su aplicación / plataforma web lo permite, apague los mensajes de error detallados, excepto las direcciones IP específicas del cliente en su LAN, presumiblemente las IP de los desarrolladores, dba’s y sysadmims. Todos los demás deberían recibir mensajes de error “bonitos” e inocuos sin ningún volcado de pila o detalles de error de SQL, ya que esta información es muy útil para los piratas informáticos que intentan entrar en su sitio. Los ataques de inyección SQL a menudo son asuntos de prueba y error donde el pirata informático deliberadamente inyecta código que arrojará errores para obtener la mayor cantidad de información posible en su servidor de base de datos y servidor de aplicaciones.

HTH