Menú

Tutorial de pruebas de inyección de SQL (ejemplo y prevención de un ataque de inyección de SQL)

  • Principal
  • Web Testing
  • Tutorial de pruebas de inyección de SQL (ejemplo y prevención de un ataque de inyección de SQL)

sql injection testing tutorial example

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Preguntas y respuestas de la entrevista de Android por 3 años de experiencia

Ejemplos de inyección de SQL y formas de prevenir ataques de inyección de SQL en aplicaciones web

Al probar un sitio web o un sistema, el objetivo del probador es asegurarse de que el producto probado esté lo más protegido posible.

Las pruebas de seguridad se realizan generalmente para este propósito. Para realizar este tipo de pruebas, inicialmente, debemos considerar qué ataques tienen más probabilidades de ocurrir. SQL Injection es uno de esos ataques.

Ejemplo y prevención de conexión de inyección SQL

La inyección de SQL se considera uno de los ataques más comunes, ya que puede traer consecuencias graves y dañinas a su sistema y datos confidenciales.

Lo que vas a aprender:

¿Qué es la inyección SQL?

Algunas de las entradas del usuario se pueden utilizar para enmarcar Declaraciones SQL que luego son ejecutados por la aplicación en la base de datos. Es posible que una aplicación NO maneje correctamente las entradas dadas por el usuario.

Si este es el caso, un usuario malintencionado podría proporcionar entradas inesperadas a la aplicación que luego se utilizan para enmarcar y ejecutar declaraciones SQL en la base de datos. A esto se le llama inyección SQL. Las consecuencias de tal acción podrían ser alarmantes.

Como su propio nombre lo indica, el propósito del ataque de inyección SQL es inyectar el código SQL malicioso.

Todos y cada uno de los campos de un sitio web son como una puerta a la base de datos. En el formulario de inicio de sesión, el usuario ingresa los datos de inicio de sesión, en el campo de búsqueda el usuario ingresa un texto de búsqueda, en el formulario de almacenamiento de datos el usuario ingresa los datos que se guardarán. Todos estos datos indicados van a la base de datos.

En lugar de datos correctos, si se ingresa algún código malicioso, existe la posibilidad de que se produzcan daños graves en la base de datos y en todo el sistema.

La inyección SQL se realiza con el lenguaje de programación SQL. SQL (lenguaje de consulta estructurado) se utiliza para administrar los datos almacenados en la base de datos. Por lo tanto, durante este ataque, este código de lenguaje de programación se está utilizando como una inyección maliciosa.

Este es uno de los ataques más populares, ya que las bases de datos se utilizan para casi todas las tecnologías.

Muchas aplicaciones utilizan algún tipo de base de datos. Una aplicación bajo prueba puede tener una interfaz de usuario que acepta la entrada del usuario que se utiliza para realizar las siguientes tareas:

#1) Muestre los datos almacenados relevantes al usuario, p. Ej. la aplicación verifica las credenciales del usuario utilizando la información de inicio de sesión ingresada por el usuario y expone solo la funcionalidad y los datos relevantes al usuario

#2) Guarde los datos ingresados ​​por el usuario en la base de datos, p. Ej. una vez que el usuario llena un formulario y lo envía, la aplicación procede a guardar los datos en la base de datos; estos datos se ponen a disposición del usuario en la misma sesión, así como en sesiones posteriores

Riesgos de la inyección SQL

Hoy en día, se utiliza una base de datos para casi todos los sistemas y sitios web, ya que los datos deben almacenarse en algún lugar.

A medida que se almacenan datos confidenciales en la base de datos, hay más riesgos involucrados en la seguridad del sistema. Si se roba cualquier sitio web personal o datos de blog, entonces no habrá mucho daño en comparación con los datos que se robarían del sistema bancario.

El objetivo principal de este ataque es piratear la base de datos del sistema, por lo que las consecuencias de este ataque pueden ser realmente dañinas.

Las siguientes cosas pueden resultar de la inyección SQL

  • Hackear la cuenta de otra persona.
  • Robar y copiar datos confidenciales del sistema o del sitio web.
  • Cambiar los datos sensibles del sistema.
  • Eliminando los datos sensibles del sistema.
  • El usuario puede iniciar sesión en la aplicación como otro usuario, incluso como administrador.
  • El usuario puede ver información privada que pertenece a otros usuarios, p. Ej. detalles de los perfiles de otros usuarios, detalles de transacciones, etc.
  • El usuario puede cambiar la información de configuración de la aplicación y los datos de los otros usuarios.
  • El usuario puede modificar la estructura de la base de datos; incluso eliminar tablas en la base de datos de la aplicación.
  • El usuario puede tomar el control del servidor de la base de datos y ejecutar comandos en él a voluntad.

Los riesgos mencionados anteriormente realmente pueden considerarse graves, ya que restaurar una base de datos o sus datos puede costar mucho. Restaurar los datos y el sistema perdidos puede costarle a su empresa reputación y dinero. Por lo tanto, es muy recomendable proteger su sistema contra este tipo de ataque y considerar las pruebas de seguridad como una buena inversión en la reputación de su producto y empresa.

Como tester, me gustaría comentar que probar contra posibles ataques es una buena práctica incluso si Pruebas de seguridad no fue planeado. De esta forma, puede proteger y probar el producto contra casos inesperados y usuarios malintencionados.

La esencia de este ataque

Como se mencionó anteriormente, la esencia de este ataque es piratear la base de datos con fines maliciosos.

Para realizar esta prueba de seguridad, inicialmente, debe encontrar las partes vulnerables del sistema y luego enviar código SQL malicioso a través de ellas a la base de datos. Si este ataque es posible para un sistema, entonces se enviará el código SQL malicioso apropiado y se pueden realizar acciones dañinas en la base de datos.

Todos y cada uno de los campos de un sitio web son como una puerta a la base de datos. Cualquier dato o input que habitualmente ingresamos en cualquier campo del sistema o sitio web va a la consulta de la base de datos. Por lo tanto, en lugar de datos correctos, si escribiéramos algún código malicioso, entonces puede ejecutarse en la consulta de la base de datos y traer consecuencias perjudiciales.

Herramienta recomendada

# 1) Kiuwan

estandarte de kiuwan

Encuentre y corrija fácilmente vulnerabilidades como la inyección de SQL en su código en cada etapa del SDLC. Kiuwan cumple con los estándares de seguridad más estrictos, incluidos OWASP, CWE, SANS 25, HIPPA y más.

Integre Kiuwan en su IDE para obtener comentarios instantáneos durante el desarrollo. Kiuwan es compatible con los principales lenguajes de programación y se integra con las principales herramientas de DevOps.

=> Escanea tu código gratis

Para realizar este ataque, tenemos que cambiar el acto y el propósito de una consulta de base de datos adecuada. Uno de los posibles métodos para realizarlo es hacer que la consulta sea siempre verdadera y luego insertar su código malicioso. El cambio de la consulta de la base de datos a siempre verdadera se puede realizar con un código simple como 'o 1 = 1; -.

Esencia de inyección SQL

Los evaluadores deben tener en cuenta que, mientras verifican si se puede cambiar la consulta a siempre verdadera o no, se deben probar diferentes comillas: simples y dobles. Por lo tanto, si hemos probado un código como 'o 1 = 1; -, también deberíamos probar el código con comillas dobles' o 1 = 1; -.

Esencia de inyección SQL

Por ejemplo, consideremos que tenemos una consulta, que busca la palabra ingresada en la tabla de la base de datos:

seleccione * de las notas nt donde nt.subject = 'search_word';

Por lo tanto, en lugar de la palabra de búsqueda, si ingresamos una consulta de inyección SQL 'o 1 = 1; -, entonces la consulta siempre será verdadera.

seleccione * de las notas nt donde nt.subject = '' o 1 = 1; -

En este caso, el parámetro 'asunto' se cierra con la cita y luego tenemos el código o 1 = 1, lo que hace que una consulta sea siempre verdadera. Con el signo “-” comentamos el resto del código de consulta, que no se ejecutará. Es una de las formas más populares y fáciles de comenzar a controlar la consulta.

También se pueden usar algunos otros códigos para hacer que la consulta sea siempre verdadera, como:

  • 'O' abc '=' abc '; -
  • ‘O‘ ‘=‘ ‘; -

Lo más importante aquí es que después del signo de la coma podemos ingresar cualquier código malicioso que nos gustaría que se ejecutara.

Por ejemplo, puede ser 'o 1 = 1; dejar notas de la mesa; -

Notas de la tabla desplegable

Si esta inyección es posible, entonces se puede escribir cualquier otro código malicioso. En este caso, solo dependerá del conocimiento y la intención del usuario malintencionado. ¿Cómo comprobar la inyección de SQL?

La verificación de esta vulnerabilidad se puede realizar muy fácilmente. A veces es suficiente escribir 'o' iniciar sesión en los campos probados. Si devuelve algún mensaje inesperado o extraordinario, entonces podemos estar seguros de que la inyección SQL es posible para ese campo.

Por ejemplo , Si recibe un mensaje de error como 'Error interno del servidor' como resultado de la búsqueda, podemos estar seguros de que este ataque es posible en esa parte del sistema.

Otros resultados que pueden notificar un posible ataque incluyen:

  • Se cargó la página en blanco.
  • No hay mensajes de error ni de éxito: la funcionalidad y la página no reaccionan a la entrada.
  • Mensaje de éxito para código malicioso.

Veamos cómo funciona esto en la práctica.

Por ejemplo, Probemos si una ventana de inicio de sesión adecuada es vulnerable a la inyección SQL. Para este propósito, en el campo de dirección de correo electrónico o contraseña, simplemente escribimos firmar como se muestra a continuación.

Dirección de correo electrónico

Si dicha entrada devuelve un resultado como el mensaje de error 'Error interno del servidor' o cualquier otro resultado inapropiado en la lista, entonces podemos estar casi seguros de que este ataque es posible para ese campo.

Error Interno del Servidor

Muy complicado Código de inyección SQL también se puede probar. Me gustaría mencionar que en mi carrera no he encontrado ningún caso en el que haya un mensaje de 'Error interno del servidor' como resultado de la señal, pero en ocasiones los campos no reaccionaron ante un código SQL más complicado.

Por lo tanto, verificar la inyección de SQL con una sola comilla 'es una forma bastante confiable de verificar si este ataque es posible o no.

Si la comilla simple no arroja ningún resultado inapropiado, entonces podemos intentar ingresar comillas dobles y verificar los resultados.

Una frase

Además, el código SQL para cambiar la consulta a siempre verdadera se puede considerar como una forma de verificar si este ataque es posible o no. Cierra el parámetro y cambia la consulta a 'verdadera'. Por lo tanto, si no se valida, dicha entrada también puede devolver cualquier resultado inesperado e informar al mismo que este ataque es posible en este caso.

Esencia de inyección SQL

La verificación de posibles ataques SQL también se puede realizar desde el enlace del sitio web. Supongamos que tenemos el enlace de un sitio web como http://www.testing.com/books=1 . En este caso, 'libros' es un parámetro y '1' es su valor. Si en el enlace proporcionado escribiéramos 'signo en lugar de 1, verificaríamos la posible inyección.

Por lo tanto, enlace http://www.testing.com/books= será como una prueba si el ataque SQL es posible para el sitio web http://www.testing.com O no.

Enlace de prueba

En este caso, si enlace http://www.testing.com/books= devuelve un mensaje de error como 'Error interno del servidor' o una página en blanco o cualquier otro mensaje de error inesperado, entonces también podemos estar seguros de que la inyección SQL es posible para ese sitio web. Más tarde, podemos intentar enviar un código SQL más complicado a través del enlace del sitio web.

Para comprobar si este ataque es posible a través del enlace del sitio web o no, también se puede enviar un código como 'o 1 = 1; -'.

Prueba de enlaces

Como probador de software experimentado, me gustaría recordar que no solo el mensaje de error inesperado puede considerarse una vulnerabilidad de inyección SQL. Muchos probadores verifican posibles ataques solo de acuerdo con los mensajes de error.

Sin embargo, debe recordarse que ningún mensaje de error de validación o mensaje de éxito de código malicioso también puede ser una señal de que este ataque es posible.

Prueba de seguridad de aplicaciones web contra inyección SQL

Pruebas de seguridad de aplicaciones web explicadas con ejemplos simples:

Dado que las consecuencias de permitir esta técnica de vulnerabilidad podrían ser graves, se deduce que este ataque debe probarse durante las pruebas de seguridad de una aplicación. Ahora, con una descripción general de esta técnica, comprendamos algunos ejemplos prácticos de inyección SQL.

Importante: Esta prueba de inyección de SQL debe probarse solo en el entorno de prueba.

Si la aplicación tiene una página de inicio de sesión, es posible que la aplicación utilice SQL dinámico, como la siguiente declaración. Se espera que esta declaración devuelva al menos una sola fila con los detalles del usuario de la tabla Usuarios como el conjunto de resultados cuando hay una fila con el nombre de usuario y la contraseña ingresados ​​en la declaración SQL.

SELECCIONE * DE Usuarios DONDE User_Name = ‘' & strUserName & '‘ AND Password = ‘' & strPassword & “’;”

Si el evaluador ingresara John como strUserName (en el cuadro de texto para el nombre de usuario) y Smith como strPassword (en el cuadro de texto para la contraseña), la declaración SQL anterior se convertiría en:

|_+_|

Si el evaluador ingresara John'– como strUserName y sin strPassword, la declaración SQL sería:

|_+_|

Tenga en cuenta que la parte de la instrucción SQL posterior a John se convierte en un comentario. Si hubiera algún usuario con el nombre de usuario de John en la tabla de Usuarios, la aplicación podría permitir al evaluador iniciar sesión como el usuario John. El probador ahora puede ver la información privada del usuario John.

¿Qué pasa si el evaluador no conoce el nombre de ningún usuario existente de la aplicación? En tal caso, el evaluador podría probar nombres de usuario comunes como admin, administrador y sysadmin. Si ninguno de estos usuarios existe en la base de datos, el evaluador podría ingresar John 'o' x '=' x como strUserName y Smith 'o' x '=' x como strPassword. Esto haría que la instrucción SQL se pareciera a la siguiente.

|_+_|

Dado que la condición 'x' = 'x' siempre es verdadera, el conjunto de resultados estaría formado por todas las filas de la tabla Usuarios. La aplicación podría permitir que el evaluador inicie sesión como el primer usuario en la tabla Usuarios.

Importante: El evaluador debe solicitar al administrador de la base de datos o al desarrollador que copie la tabla en cuestión antes de intentar los siguientes ataques.

Si el evaluador ingresara John '; DROP table users_details; ’- como strUserName y cualquier cosa como strPassword, la declaración SQL se volvería como la siguiente.

|_+_|

Esta declaración podría hacer que la tabla 'users_details' se elimine permanentemente de la base de datos.

Aunque los ejemplos anteriores tratan sobre el uso de la técnica de inyección SQL solo en la página de inicio de sesión, el evaluador debe probar esta técnica en todas las páginas de la aplicación que aceptan la entrada del usuario en formato textual, p. páginas de búsqueda, páginas de comentarios, etc.

La inyección de SQL puede ser posible en aplicaciones que utilizan SSL. Incluso un firewall podría no proteger la aplicación contra esta técnica.

He intentado explicar esta técnica de ataque de una forma sencilla. Me gustaría repetir que este ataque debe probarse solo en un entorno de prueba y no en el entorno de desarrollo, entorno de producción o cualquier otro entorno.

ingeniero de desarrollo de software en preguntas de entrevista de prueba

En lugar de probar manualmente si la aplicación es vulnerable a un ataque SQL o no, se podría usar un Escáner de vulnerabilidad web que comprueba esta vulnerabilidad.

Lectura relacionada: Prueba de seguridad de la aplicación web . Consulte esto para obtener más detalles sobre diferentes vulnerabilidades web.

Partes vulnerables de este ataque

Antes de comenzar el proceso de prueba, todo evaluador sincero debería saber más o menos qué partes serían más vulnerables a este posible ataque.

También es una buena práctica planificar qué campo del sistema se va a probar exactamente y en qué orden. En mi carrera de pruebas, he aprendido que no es una buena idea probar campos contra ataques SQL al azar, ya que algunos campos pueden pasarse por alto.

Dado que este ataque se realiza en la base de datos, todas las partes del sistema de entrada de datos, los campos de entrada y los enlaces a sitios web son vulnerables.

Las partes vulnerables incluyen:

  • Campos de inicio de sesión
  • Campos de búsqueda
  • Campos de comentario
  • Cualquier otro campo de entrada y guardado de datos
  • Vínculos del sitio web

Es importante notar que mientras se prueba contra este ataque, no es suficiente verificar solo uno o algunos campos. Es bastante común que un campo esté protegido contra la inyección SQL, pero otro no. Por lo tanto, es importante no olvidar probar todos los campos del sitio web.

Automatización de pruebas de inyección SQL

Como algunos sistemas o sitios web probados pueden ser bastante complicados y contener datos confidenciales, la prueba manual puede ser realmente difícil y también lleva mucho tiempo. Por lo tanto, las pruebas contra este ataque con herramientas especiales pueden ser realmente útiles en ocasiones.

Una de estas herramientas de inyección SQL es IU de SOAP . Si tenemos pruebas de regresión automatizadas a nivel de API, también podemos cambiar la verificación contra este ataque usando esta herramienta. En la herramienta SOAP UI, ya hay plantillas de código preparadas para verificar este ataque. Estas plantillas también pueden complementarse con su propio código escrito.

Es una herramienta bastante confiable.

Sin embargo, una prueba ya debería estar automatizada a nivel de API, lo cual no es tan fácil. Otra forma posible de realizar pruebas automáticamente es mediante el uso de varios complementos del navegador.

Cabe mencionar que, incluso si las herramientas automatizadas le ahorran tiempo, no siempre se las considera muy confiables. Si estamos probando un sistema bancario o cualquier sitio web con datos muy sensibles, es muy recomendable probarlo manualmente. Donde puedas ver los resultados exactos y analizarlos. Además, en este caso, podemos estar seguros de que no se omitió nada.

Comparación con otros ataques

La inyección de SQL puede considerarse como uno de los ataques más graves, ya que influye en la base de datos y puede causar daños graves a sus datos y a todo el sistema.

Seguro que puede tener consecuencias más graves que una inyección de JavaScript o una inyección de HTML, ya que ambas se realizan en el lado del cliente. A modo de comparación, con este ataque, puede tener acceso a toda la base de datos.

Cabe mencionar que para probar este ataque, debe tener un conocimiento bastante bueno del lenguaje de programación SQL y, en general, debe saber cómo están funcionando las consultas a las bases de datos. Además, al realizar este ataque de inyección, debe ser más cuidadoso y atento, ya que cualquier inexactitud puede dejarse como vulnerabilidades de SQL.

Conclusión

Espero que haya tenido una idea clara de lo que es una inyección SQL y cómo debemos prevenir estos ataques.

Sin embargo, se recomienda encarecidamente realizar pruebas contra este tipo de ataque cada vez que se esté probando un sistema o sitio web con una base de datos. Cualquier vulnerabilidad de base de datos o sistema que quede puede costar la reputación de una empresa y muchos recursos para restaurar todo el sistema.

Como las pruebas contra esta inyección ayudan a encontrar la mayor importantes vulnerabilidades de seguridad , también se recomienda invertir en sus conocimientos y herramientas de prueba.

Si se planea realizar pruebas de seguridad, las pruebas con SQL Injection deben planificarse como una de las primeras partes de prueba.

¿Ha encontrado alguna inyección SQL típica? No dude en compartir sus experiencias en la sección de comentarios a continuación.

Lectura recomendada

^