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.
ngDespué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
No hay comentarios:
Publicar un comentario