El primero en la lista de las diez vulnerabilidades más comunes (OWASP) es la inyección. Este tipo de hallazgo es más como una categoría, e incluye todos los tipos de vulnerabilidades donde una aplicación envía datos no confiables a un intérprete. Se encuentra a menudo en las consultas de bases de datos, pero otros ejemplos son los comandos OS, XML parsers o cuando la entrada del usuario se envía como variables acuerdo con los consultores de auditoría 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 la base 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 auditoría 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 un formulario 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 lista de 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.
Pueden aprender todo sobre remediación sobre inyección SQL curso de seguridad de base de datos y resolver las vulnerabilidades de sus sistemas informáticos.
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
