SQL Injection…

Es un tema que afecta a la gran mayoría de los sitios web del mundo. Suena exagerado decirlo así, pero si lo analizamos desde la perspectiva de que es un problema que muchas veces los programadores resuelven únicamente donde/cuando han sido atacados, y en el futuro vuelven a escribir código inseguro, tal vez entonces no suene tan descabellado.

Mucha gente escucha “inyección sql” y piensan que es un vector de ataque que permite únicamente inyectar sentencias SQL con el objeto de modificar la información de una base de datos.

Lo cual es verdad.

El problema es que la inyección sql, y dependiendo del sistema de base de datos utilizado por el backend del aplicativo web, permite incluso la ejecución de programas en el servidor donde se encuentra la base de datos a la cual se accede, indirectamente, vía web.

La principal solución es sencilla: desconfiar del usuario. O mejor aún, SABER que el aspecto de un sitio web, sus formularios, su tecnología AJAX, en fin, el diseño del sitio web no limitan de ninguna manera lo que el atacante puede enviar al servidor web.

¿Qué quiero decir con eso? Muchísimos diseñadores web incorporan algún tipo de validación de datos, pero si esta validación ocurre únicamente vía JavaScript en el NAVEGADOR del usuario, dicha validación para un atacante de poco conocimiento es sinceramente fácil de evitar.

Por ejemplo, filtrar un campo numérico para que solo admita caracteres del 0 al 9 utilizando únicamente JavaScript, pasa a ser únicamente algo “funcional” para el verdadero usuario, y una inexistente limitación para el atacante. Con instalar la extensión Tamper Data para Mozilla Firefox, al momento de hacer clic en “enviar” a dicho formulario, podemos modificar a nuestro antojo casi cualquier aspecto de la consulta HTTP “fabricada” por el formulario. Y poner una comilla simple y ver que resultados no esperados (por ejemplo, un mensaje de error del motor de base de datos) surgen de dicha manipulación.

Si la validación de datos ocurriera TAMBIÉN del lado del aplicativo web, en el nivel que sea, dicha técnica no sería aplicable.

Referencias:
Puede encontrar más información:

https://www.owasp.org/index.php/Guide_to_SQL_Injection

https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)

 

Y ahora, para divertirse un poco… piensen que abusar parametros, cookies, cualquier dato que pueda de una manera u otra ser controlado por un navegante es potencialmente un punto de inyeccion, no solo de SQLi, sino para XSS, RFI, etc.

 

Artículos relacionados:

Si te gustó este articulo, ¿ Porque no dejas un comentario a continuación y continuas la conversación, o te suscribes a los feeds y recibes los artículos directamente en tu lector?

Comentarios

No comments yet.

Sorry, the comment form is closed at this time.