Inyeccion SQL

El primero en la lista de las diez vulnerabilidades mas comunes es la inyeccion . Este tipo de hallazco es mas como una categoria, e incluye a todos los tipos de vulnerabilidades donde una aplicacion envia datos no confiables a un interprete. Se encuentra a menudo en las consultas de base de datos, otros ejemplos son el comando OS, XML parsers o cuando la entrada del usuario se evia como variables acuerdo con los consultores de auditoria de base de datos.

Según maestros de curso de seguridad de base de datos, este es un tipo de vulnerabilidad muy común, especialmente en código antiguo, ya que era mucho más común hace unos años cuando estaban menos conscientes del peligro. La Inyección de SQL debe ser considerada como la más conocida del tipo de inyección acuerdo con el curso de seguridad de base de datos. 

Como se trata de una categoría muy amplia de la vulnerabilidad, el riesgo varía mucho de un caso a otro. Como la inyección de SQL es el tipo de inyección más conocida, el impacto es a menudo el robo de datos de labase de datos. Eso puede incluir nombres de usuario, contraseña y otros datos confidenciales. El peor de los casos sería una adquisición completa del sistema, lo que ciertamente es posible dependiendo de dónde se dé la inyección y en qué entorno mencionan los consultores de auditoría de base de datos.

Este es un ataque que puede ser automatizado, lo que lo supone en mayor riesgo.

Un atacante no necesita estar tras de ti, el simplemente puede escribir una secuencia que explota a tantos sitios como sea posible y si el tuyo es uno de ellos es una coincidencia. Uno de los ataques más conocidos realizados por inyección de SQL estuvo dirigido contra Sony. Otro casi irónico fue cuando MySQL sufrió el mismo una inyección SQL. Como se puede entender partir de los ejemplos, grandes jugadores también están en riesgo y el resultado de un ataque puede ser aterrador sin algún tipo de auditoria de base de datos. 

¿CÓMO DESCUBRIR LA INYECCIÓN DE SQL?

Para los usuarios más avanzados es una vulnerabilidad que pueden encontrarse a menudo mientras se está haciendo el análisis de código. Esa es la identificación de todas las consultas en la aplicación web y siguiendo el flujo de datos. Ya que a veces no genera ninguna reacción visible y puede ser difícil de detectar durante black box-test, a pesar de que a algunas veces eso es posible también. Según el curso de seguridad de base de datos, la inyección es una definición muy amplia que varía de un caso a otro, pero en general una inyección SQL clásico es muy fácil de explotar.

Un ejemplo típico de una inyección de SQL sería en unformulario de acceso, con el código que se muestra a continuación:

$db = new mysqli(‘localhost’, ‘root’, ‘passwd’, ‘base’); $result = $db->query(‘SELECT * FROM users WHERE user=”‘.$_GET[‘user’].’” AND pass= “‘.$_GET[‘password’].’”‘);
Supongamos que el atacante entra “ OR 1– como nombre de usuario y cualquier contraseña de todo el código y se terminara viendo así:
SELECT * FROM users WHERE user=”” OR 1 — AND pass=”whatever”
Después de — (lo que se indica el inicio de un comentario en SQL) será desechado e ignorado. El código será ejecutado cuando se vea de la siguiente manera:
SELECT * FROM users WHERE user=”” OR 1
El código establece ahora “Obtener todo, desde la listade usuarios (donde el nombre de usuario coincide con nada o 1 (lo que se interpretara como cierto)”.

Desde que la última afirmación siempre resultará en cierto, la mano derecha de la declaración eliminara con éxito la declaración mano izquierda y la condición siempre será cierto. El resultado de esta consulta sería algo como éste:

SELECT * FROM users
El cual sería devolver todos los datos que hay sobre todos los usuarios. Ej., La inyección en el parámetro $ _GET [‘usuario’] es suficiente para hacer que el servidor MySQL seleccione el primer usuario y otorgué al atacante acceder a ese usuario.

REMEDIACIÓN
Mientras las inyecciones son más de una categoría de vulnerabilidades, las soluciones varían de un caso a otro, dependiendo de qué tipo de vector y el intérprete que estamos hablando. Acuerdo el curso de auditoría de base de datos y seguridad de base de datos, la solución óptima es utilizar un API que, o bien evita el intérprete o proporciona una interfaz con parámetros. El código con parámetros no es difícil de hacer, y si usas PHP nosotros te recomendamos PDO. Puede sonar extraño al principio, pero en realidad no es tan difícil como tú podrías pensar en un principio. Ejemplos en otros idiomas pueden ser aprendidos durante el curso de seguridad de base de datos.

Si el código parametrizado no es una opción en su caso, en su lugar debes escapar cuidadosamente de caracteres especiales. ¿Cómo se hace esto? depende del intérprete utilizado, y algunas veces tendrías que mejorar.

La validación de entrada de la lista blanca es también una alternativa, pero a menudo no se puede utilizar como aplicación puede requerir caracteres especiales, como de entrada. Por ejemplo, un blog quiere permitir a sus visitantes hacer comentarios usando comillas, a pesar de que es carácter podría ser utilizado para salir de una consulta. En esos casos, es necesario ir con una solución de uno o dos.