Durante la evaluación de la vulnerabilidad o las pruebas de penetración,
la identificación de los vectores de entrada de la aplicación de
destino es un paso primordial. A veces, cuando se trata de pruebas de
aplicaciones Web, las rutinas de verificación en relación con los
errores de inyección
SQL descubrimiento se restringen a las variables
GET y
POST como las entradas vectores singulares de la historia. ¿Qué pasa con otros parámetros de cabecera
HTTP? ¿No son los vectores de entrada potencial para los ataques de inyección
SQL?
¿Cómo se puede probar todos estos parámetros HTTP y que los escáneres
de vulnerabilidad a utilizar con el fin de evitar dejar vulnerabilidades
sin descubrir en algunas partes de la aplicación?
Un resultado de una comparación de 60 comerciales y de código abierto de
la caja negro escáneres de vulnerabilidades de aplicaciones web fue
puesto en libertad y titulado:
«La Legión de escaneo: Escáner de aplicaciones Web Precisión Evaluación y Comparación de funciones».
Este punto de referencia, realizado por el investigador de seguridad
Shay Chen en 2011, se centró en las pruebas de las herramientas
comerciales y de código abierto que son capaces de detectar (y no
explotar necesariamente) las vulnerabilidades de seguridad en una amplia
gama de las direcciones
URL.
Hemos concluido el siguiente gráfico que muestra la cobertura del
parámetro de entrada el apoyo de scanners de aplicaciones web probadas.
Estas entradas son básicamente:
Parámetros de cadena de consulta HTTP (GET): parámetros de entrada enviados en la
URL.
Parámetros Cuerpo HTTP (POST): parámetros de entrada enviados en el cuerpo
HTTP.
Parámetros HTTP Cookie: parámetros de entrada enviados en la
cookie HTTP.
Encabezados HTTP: HTTP encabezados de solicitud utilizados por la aplicación.
Esta gráfica muestra obviamente que el 75% de los escáneres de aplicaciones Web no pudo descubrir encabezados
HTTP parámetros defectos relacionados. Por otra parte, el 70% de estos escáneres no inspeccionar
cookies HTTP
vulnerabilidades persona. Estas tasas se refieren exactamente a la
capacidad de los escáneres para escanear el vector de entrada, no
simplemente para interpretarlo. En comparación con la puntuación
razonable realizada por
GET y
POST, algunas herramientas de pruebas automatizadas pueden llevar a resultados no satisfechas cuando se trata de la cabecera
HTTP como un vector de entrada de inyección
SQL.
Como cuestión de hecho, las
Cookies Encabezados
HTTP y no
debe ser subestimado. Por lo tanto, estos dos vectores se deben tomar en
consideración durante plan de pruebas. Sin embargo, cuando los
escáneres de vulnerabilidad utilizados no están apoyando a estas
características, debemos pensar en las pruebas de estos parámetros de
forma manual.
Encabezados HTTP potenciales para inyecciones SQL
Campos de encabezado HTTP
Campos de cabecera
HTTP son componentes de la cabecera del mensaje de peticiones y respuestas en el Protocolo de transferencia de hipertexto (
HTTP). Se definen los parámetros de funcionamiento de una transacción
HTTP.
Ejemplo: solicitud HTTP
GET / HTTP/1.1
Connection: Keep-Alive
Keep-Alive: 300
Accept:*/*
Host: host
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)
Cookie: guest_id=v1%3A1328019064; pid=v1%3A1328839311134
Podemos considerar las
cookies HTTP, cuando se almacenan en bases de datos para la identificación de las sesiones, como los primeros potenciales variables de
HTTP que deben ser probadas. Veremos a continuación en un ejemplo de inyección
SQL basada Cookie. También hay otras cabeceras
HTTP relacionadas con la aplicación.
X-Forwarded-For
X-Forwarded-For es un campo de encabezado HTTP considerado como un
estándar de facto para la identificación de la dirección IP de origen de
un cliente que se conecta a un servidor web a través de un
proxy HTTP o equilibrador de carga.
Vamos a ver un ejemplo de esto basándose defecto de un envío de formularios.
$req = mysql_query("SELECT user,password FROM admins WHERE user='".sanitize($_POST['user'])."' AND password='".md5($_POST['password'])."' AND ip_adr='".ip_adr()."'");
El inicio de sesión variable se controla correctamente debido al sanitize() method.
function sanitize($param){ if (is_numeric($param)) { return $param; } else { return mysql_real_escape_string($param); } }
Vamos a inspeccionar la variable ip. Se está asignando la salida ip_addr() method.
function ip_adr() { if
(isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ip_adr = $_SERVER['HTTP_X_FORWARDED_FOR']; } else { $ip_adr = $_SERVER["REMOTE_ADDR"]; } if (preg_match("#^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}#",$ip_addr)) { return $ip_adr; } else { return $_SERVER["REMOTE_ADDR"]; } }
Obviamente, la dirección IP se recupera de la
X_FORWARDED_FOR cabecera
HTTP. Esta tarde está controlado por el
preg_match que verifica si este parámetro no celebre al menos una dirección
IP. Como cuestión de hecho, el entorno
HTTP_X_FORWARDED_FOR variable no es verificada apropiadamente antes de su valor que se utiliza en la consulta de
SQL. Esto puede llevar a ejecutar cualquier consulta SQL inyectando código SQL arbitrario en este campo.
El simple modificación de este campo de encabezado a algo así como:
GET /index.php HTTP/1.1
Host: [host]
X_FORWARDED_FOR :127.0.0.1' or 1=1#
llevará a pasar por alto el control de autenticación.
User-agent
User agent es un campo de encabezado HTTP da el programa de software
utilizado por el cliente original. Esto es para fines estadísticos y el
rastreo de las violaciónes de protocolo. Se debe incluirse. La primera
palabra espacio delimitado blanco debe ser el nombre del producto de
software, con una barra y la versión designador opcional.
No todas las aplicaciones están escritas para capturar los datos de user
agent, pero a veces las aplicaciones se han diseñado para almacenar
dicha información (por ejemplo:shopping cart providers) para hacer uso
de ella. En este caso, vale la pena investigar el encabezado de agente
de usuario de posibles problemas.
Ejemplo de consulta HTTP:
GET /index.php HTTP/1.1
Host: [host]
User-Agent: aaa' or 1/*
Referer
Referer es otra cabecera HTTP que puede ser vulnerable a la inyección de
SQL, una vez que la aplicación se almacena en la base de datos sin
esterilizarlo. Es un campo de encabezado opcional que permite al cliente
especificar, para el beneficio del servidor, la dirección (URI) del
documento (o elemento dentro del documento) de la que se obtuvo el URI
de la solicitud. Esto permite a un servidor para generar listas de nuevo
los enlaces a los documentos, por interés, la explotación forestal, etc
Permite a los malos acoplamientos a remontar para el mantenimiento.
Ejemplo:
GET /index.php HTTP/1.1
Host: [host]
User-Agent: aaa' or 1/*
Referer: http://www.yaboukir.com
Perspectiva del atacante?
Como todos sabemos, los errores de inyección se clasifican los primeros
en el OWASP Top 10 Los riesgos de seguridad de aplicaciones Web. Los
atacantes están buscando cada vez más para los puntos de inyección para
tener acceso total de sus bases de datos. No importa el tipo de la
entrada del punto de inyección, ya sea un GET, POST, Cookie o otras
cabeceras HTTP; lo importante para los intrusos es siempre tener al
menos un punto de inyección que permiten a iniciar la fase de
explotación.
Inyecciones SQL basadas probar manualmente Cookies
En esta sección, vamos a introducir algunos métodos de control de las variables HTTP cookies.
El uso de un Navegadores Add-on
Cookies Manager+
Cookies Manager + permite ver, editar y crear nuevas cookies. También
permite mostrar información adicional acerca de las cookies y permite
editar varias Cookies a la vez, así como copia de seguridad /
restauración de ellos.
Después de instalarlo, en el menú Herramientas, seleccione Administrador
de cookies +. Seleccionamos una variable de cookies relacionadas con la
aplicación de destino.
Vamos a editar la variable language_id. Para averiguar la falla de inyección SQL, vamos a añadir una quote "'" en el campo
contenido de la variable de language_id.
Después de actualizar la página o hacer clic en otro enlace interno de
la aplicación, la aplicación envía la solicitud mediante la cookie HTTP
editado. El resultado se dispara un error SQL:
Este error de base de datos nos está alertando de un fallo de inyección SQL susceptible.
La ventaja de utilizar cookies Gestor + es que es fácil de usar, actúa
directamente en la cookie y guarda el valor anterior edición de la
cookie.
Vamos a tratar de determinar el número de columna utilizando otro Firefox plug-in.
Tamper Data:
Tamper Data es un poderoso complemento de Firefox para ver y modificar HTTP / HTTPS y los parámetros encabezados de correos.
Después de instalarlo, en el menú Herramientas, seleccione Tamper Data.
Comience manipulación petición HTTP, haga clic en el botón Star Tamper.
Al poner en marcha cualquier solicitud de la aplicación de destino,
Tamper Data abre un cuadro y le pregunta si se quiere alterar la actual
solicitud HTTP acaba de enviar.
ng
Después de hacer clic en Tamper, tenemos la ventana emergente completa Tamper:
Añadimos: order by 4 en la variable de cookie HTTP como se muestra en la
captura de pantalla anterior. La respuesta es normal de la aplicación.
Incrementamos el número y añadimos esta vez:. Order by 5 La respuesta a esta inyección es el siguiente:
Así que podemos concluir que el número de columnas es de 4.
Ahora, vamos a tratar de averiguar las columnas afectadas con el fin de
inyectar en ella más consultas SQL. Por lo tanto, vamos a añadir la
siguiente consulta en la variable de cookie HTTP language_id:
-1 + UNION + ALL + SELECT +1,2,3,4
La explotación puede necesitar técnicas de inyección SQL a veces avanzadas.
El uso de escáner automatizado de pruebas de penetración
Sqlmap como ejemplo
Sqlmap es una herramienta popular de código abierto de pruebas de
penetración, que automatiza el proceso de detectar y explotar los
errores de inyección SQL y hacerse cargo de los servidores de bases de
datos.
Sqlmap compatible con las características de HTTP Cookies por lo que puede ser útil en dos sentidos:
*La autenticación basada en cookies cuando la aplicación web requiere que.
*La detección y explotación de inyección SQL en dichos valores de Headers.
By default sqlmap defecto todos los parametros GET y parámetros POST.
Cuando el valor de nivel se establece en 2 o por encima de ella también
pone a prueba los valores de encabezado HTTP cookies. Cuando este valor
se establece en 3 o superior, que pone a prueba también HTTP User-Agent y
HTTP Referer valor de encabezado de inyecciones SQL. Sin embargo, es
posible especificar manualmente una lista separada por comas de
parámetro (s) que desea sqlmap para probar. Esto omitirá Bypass de la
dependencia del valor de nivel también.
Nivel de parámetros HTTP------------sqlmap
GET 1 (Default)
POST 1 (Default)
HTTP Cookie 2 ≥
HTTP User-Agent 3 ≥
HTTP Referer 3 ≥
Por ejemplo, para la prueba de Identificación de parámetros GET y HTTP User-Agent sólo, proporcionar-p id, user-agent.
Este es un ejemplo de cómo podemos probar el parámetro denominado
seguridad de una cookie HTTP del DVWA (Web Application Damn Vulnerable).
./sqlmap.py -u 'http://127.0.0.1/vulnerabilities/sqli/?id=1&Submit=Submit#'
--cookie='PHPSESSID=0e4jfbrgd8190ig3uba7rvsip1; security=low'
--string='First name' --dbs --level 3 -p PHPSESSID
The flag-string compare las páginas válidos y una inválida (a causa de
la inyección). En el otro lado, the flag-DBS se utiliza para enumerar
los sistemas de gestión de base de datos. Por último, the flag-P Force
la prueba de la variable PHPSESSID.
Herramientas para la inyección de prueba SQL: elegir por su precisión en la detección o por su cobertura de vector de entrada?
Con el fin de responder a esta pregunta, hemos explotado los resultados
del índice de referencia proporcionado por sectoolmarket.com. Hemos
tomar en la hipótesis de que la precisión en la detección de los
escáneres de candidatos tiene la misma importancia que los vectores de
entrada de la cobertura y apoyo. Hemos considerado GET, POST, HTTP
Cookies y HTTP Headers como los vectores de entrada que deben ser
apoyadas. Cuando se admiten todos estos parámetros, los escáneres hacen
una tasa de 100% de cobertura (4/4).
Sugerimos la siguiente ecuación de la media aritmética de adaptar una
puntuación de equilibrio para los escáneres de vulnerabilidad.
Después de equilibrar las tasas obtenidas con el porcentaje de precisión
en la detección, nos detuvimos por este resultado por debajo de los 14
primeros escáneres.
Podemos mostrar un gráfico que representa los escáneres de
vulnerabilidad por su puntuación equilibrada que define tanto por su
precisión en la detección de errores de inyección SQL y su cobertura
vector de entrada.
¿Qué sigue?
Para los desarrolladores
Cookies y otras cabeceras HTTP almacenados deben ser tratados por los
desarrolladores como otra forma de entrada del usuario y se someterán a
las mismas rutinas de validación.
Para testers
La manipulación de la información del encabezado HTTP en solicitudes de
páginas (sobre todo los campos REFERER y USER-AGENT) es importante
identificar si la aplicación es vulnerable a los vectores de inyección
SQL o incluso a otras vulnerabilidades estándar (XSS). Es una buena
práctica para definir y describir todos los aspectos que un usuario
puede manipular los datos que es utilizado por la aplicación. Estos
datos pueden ser almacenados, descabellada y se procesan Cookies,
HTTP-headers (like HTTP_USER_AGENT ), form-variables (visible and
hidden), Ajax-, JQuery-, XML-requests. x
Saludos y gracias por su preferencia
Saludos a DARKSPARK
Visitar la fuente para imágenes y códigos mejor organizado :)
http://krauser.diosdelared.com/?coment=12579
Entradas
