inyección de SQL genérico CGI

1

Estaba escaneando un sitio con Nessus cuando se reportó la siguiente vulnerabilidad:

  

CGI Generic SQL Injection

Nessus dice que:

  

"Un atacante puede explotar esta falla para evitar la autenticación, leer datos confidenciales, modificar la base de datos remota o incluso tomar el control del sistema operativo remoto".

Así que continué leyendo y descubrí que la vulnerabilidad se encuentra en este fragmento de código:

  

Usando el método HTTP POST, Nessus encontró que:

     

Los siguientes recursos pueden ser vulnerables a la inyección de SQL:

     

El parámetro '_codeTextBox' del /LoginTeacherForm.aspx CGI:

     

/LoginTeacherForm.aspx [loginButton = iniciar sesión &pp ;, _VIEWSTATE = dDwtMTU2NDIxMDkwN Ts7Pg% 3d% & amp.

     

-------- salida --------

     

Detalles de la excepción: System.Data.SqlClient.SqlException: La cadena o los datos binarios se truncarían.   La instrucción se ha terminado.

Pero me pregunto cómo un atacante podría explotar esta vulnerabilidad, porque cuando pego esa url solo me da un error.

Entonces, mi pregunta es ¿cómo podría un ataque piratear el sitio y omitir el inicio de sesión, etc.?

    
pregunta ruben 24.08.2013 - 15:17
fuente

2 respuestas

1

Comenzaré mencionando la parte habitual que hacemos cuando se usan las herramientas de prueba de seguridad, que es muy importante que solo se usen en sitios que está autorizado a probar. La ejecución de herramientas de seguridad en sitios para los que no está autorizado a realizar pruebas puede ser un delito penal según su jurisdicción.

Dicho esto, diría que es probable que Nessus informe que, en base a la mención de la excepción de SQL en el mensaje de error, esto implica que la consulta SQL en esa página se modificó, aunque he visto falsos positivos con ese tipo de error antes.

En términos de cómo podría ser vulnerable, es probable que la consulta detrás de ese tipo de página sea una instrucción SELECT que compare los valores proporcionados para el inicio de sesión con los almacenados en la base de datos para ese usuario. Si la página toma los valores directamente del usuario y los coloca en la consulta, existe la posibilidad de que sea vulnerable.

Si es vulnerable, un atacante puede modificar la consulta SQL que se está ejecutando en su sitio y, a continuación, omitir el inicio de sesión es un posible resultado, junto con un atacante que daña el servidor subyacente.

Una buena manera de probar esto de una manera no destructiva podría ser usar los caracteres de comillas y la concatenación de cadenas.

Primero verifique si puede reproducir el error. Ingrese un solo 'carácter en el campo junto con datos válidos en los otros campos en ese formulario. Si lanza un error, es posible que sea vulnerable.

Luego, si tiene un valor válido para el campo codetextbox (digamos que es abcdef) intente ingresar

  

abc '+' def

como el valor en ese campo junto con datos válidos en los otros campos. Si la aplicación inicia sesión, puede eliminar los caracteres no alfa (es posible, pero no explicaría su mensaje de error) o puede concatenar las dos cadenas, lo que implica que tiene inyección de SQL.

En ese momento, lo mejor que puede hacer es mirar la fuente de la página para confirmar.

    
respondido por el Rоry McCune 25.08.2013 - 09:39
fuente
0

El error System.Data.SqlClient.SqlException indica un error en su declaración de consulta SQL. Esto implica que el valor almacenado en el parámetro _codeTextBox no está validado u otro tipo de desinfección antes de colocarlo en la consulta.

Esto tendría diferentes implicaciones según la consulta y la lógica que rodea su valor de retorno. Es imposible determinar el peor de los casos sin una comprensión profunda de la aplicación web. Basta con decir que este problema debe ser resuelto por el desarrollador. Afortunadamente, generalmente es fácil de solucionar una vez identificado.

En este caso, parece que el parámetro _codeTextBox se pasa a la función convert . Dudo que alguien pueda explotar esto. Pero, esto indica prácticas de codificación inseguras que probablemente aparecen en otras áreas que Nessus no conoce. Lea a continuación para obtener más información.

Veo esto más a menudo cuando el programador simplemente concatena los valores con la cadena de consulta SQL:

Ejemplo no seguro (java) (Fuente OWASP )

String query = "SELECT account_balance FROM user_data WHERE user_name = "
  + request.getParameter("customerName");

try {
    Statement statement = connection.createStatement( … );
    ResultSet results = statement.executeQuery( query );
}

Dado que el valor simplemente se agrega al final de la consulta, el usuario puede cambiar la consulta para hacer algo tan nefasto como iniciar sesión como cualquier usuario o ver todas las transacciones. En el ejemplo anterior, el usuario podría cambiar el parámetro customer name a algo como '' or 1=1 o peor.

Consulta esperada:

 SELECT account_balance FROM user_data WHERE user_name = someuser

Consulta errónea:

 SELECT account_balance FROM user_data WHERE user_name = '' OR 1=1

OWASP recomienda las siguientes medidas defensivas. Tu situación dictará lo que sea apropiado:

Defensas primarias :

  1. Uso de declaraciones preparadas (consultas parametrizadas)
  2. Uso de procedimientos almacenados
  3. Escapar de todas las entradas proporcionadas por el usuario

Defensas adicionales :

  • También imponer: privilegio mínimo
  • También realice: Validación de entrada de la lista blanca

Realmente necesitas visitar el sitio de OWASP y leer más sobre inyección SQL .

    
respondido por el ZnArK 09.09.2013 - 18:21
fuente

Lea otras preguntas en las etiquetas