Tipos populares de ataques de inyección de aplicaciones web.El problema con las aplicaciones web es que están expuestas abiertamente a miles de millones de usuarios de Internet, muchos de los cuales querrán romper sus medidas de seguridad, por cualquier razón.
En los primeros días de Internet, uno de los métodos de ataque más comunes era la fuerza bruta básica y simple . Bots usualmente realizaba estos ataques, o personas con mucho tiempo libre, que intentaban miles de millones de combinaciones de nombres de usuario y contraseñas hasta que encontraban uno que les permitiera acceder a la aplicación de destino.
Los ataques de fuerza bruta ya no son una amenaza, gracias a las políticas de contraseña, intentos de inicio de sesión limitados y captchas. Pero a los cibercriminales les encanta descubrir nuevas hazañas y usarlas para realizar nuevos tipos de ataques. Hace mucho tiempo, descubrieron que los campos de texto en aplicaciones o páginas web podían explotarse ingresando –o inyectando– texto inesperado que obligaría a la aplicación a hacer algo que no debía hacer. De esa manera, los llamados ataques de inyección entraron en escena.
Los ataques de inyección se pueden usar no solo para iniciar sesión en una aplicación sin conocer el nombre de usuario y la contraseña, sino también para exponer información privada, confidencial o confidencial, o incluso para secuestrar un servidor completo. Es por eso que estos ataques no son solo una amenaza para las aplicaciones web , sino también para los usuarios cuyos datos residen en esas aplicaciones y, en el peor de los casos, para otras aplicaciones y servicios conectados.
Inyección de código
La inyección de código es uno de los tipos más comunes de ataques de inyección. Si los atacantes conocen el lenguaje de programación, el marco, la base de datos o el sistema operativo utilizado por una aplicación web, pueden inyectar código a través de campos de entrada de texto para obligar al servidor web a hacer lo que quieran.
Estos tipos de ataques de inyección son posibles en aplicaciones que carecen de validación de datos de entrada. Si un campo de entrada de texto permite a los usuarios ingresar lo que quieran, entonces la aplicación es potencialmente explotable. Para evitar estos ataques, la aplicación necesita restringir tanto como sea posible a los usuarios de entrada que pueden ingresar.
Por ejemplo, necesita limitar la cantidad de datos esperados, verificar el formato de datos antes de aceptarlo y restringir el conjunto de caracteres permitidos.
Las vulnerabilidades de inyección de código pueden ser fáciles de encontrar, simplemente probando la entrada de texto de una aplicación web con diferentes tipos de contenido. Cuando se encuentran, las vulnerabilidades son moderadamente difíciles de explotar. Pero cuando un atacante logra explotar una de estas vulnerabilidades, el impacto podría incluir la pérdida de confidencialidad, integridad, disponibilidad o funcionalidad de la aplicación.
Inyección SQL
De manera similar a la inyección de código, este ataque inserta un script SQL, el lenguaje utilizado por la mayoría de las bases de datos para realizar operaciones de consulta, en un campo de entrada de texto. El script se envía a la aplicación, que lo ejecuta directamente en su base de datos. Como resultado, el atacante podría pasar por una pantalla de inicio de sesión o hacer cosas más peligrosas, como leer datos confidenciales directamente de la base de datos, modificar o destruir datos de la base de datos, o ejecutar operaciones de administración en la base de datos.
Las aplicaciones PHP y ASP son propensas a los ataques de inyección SQL debido a sus interfaces funcionales más antiguas. Las aplicaciones J2EE y ASP.Net generalmente están más protegidas contra estos ataques. Cuando se encuentra una vulnerabilidad de inyección SQL, y podrían encontrarse fácilmente, la magnitud de los posibles ataques solo estará limitada por la habilidad y la imaginación del atacante. Por lo tanto, el impacto de un ataque de inyección SQL es indudablemente alto.
Inyección de comando
Estos ataques también son posibles, principalmente debido a una validación de entrada insuficiente. Se diferencian de los ataques de inyección de código en que el atacante inserta comandos del sistema en lugar de fragmentos de código o scripts de programación. Por lo tanto, el hacker no necesita saber el lenguaje de programación en el que se basa la aplicación o el lenguaje utilizado por la base de datos. Pero necesitan saber el sistema operativo utilizado por el servidor de alojamiento.
El sistema operativo host ejecuta los comandos del sistema insertados con los privilegios de la aplicación, lo que podría permitir exponer el contenido de archivos arbitrarios que residen en el servidor, mostrar la estructura de directorios de un servidor, cambiar las contraseñas de los usuarios, entre otras cosas. .
Un administrador del sistema puede evitar estos ataques limitando el nivel de acceso al sistema de las aplicaciones web que se ejecutan en un servidor.
Secuencias de comandos entre sitios
Cada vez que una aplicación inserta información de un usuario dentro de la salida que genera, sin validarla o codificarla, le da la oportunidad a un atacante de enviar código malicioso a un usuario final diferente. Los ataques de Cross-Site Scripting (XSS) aprovechan estas oportunidades para inyectar scripts maliciosos en sitios web confiables, que finalmente se envían a otros usuarios de la aplicación, que se convierten en víctimas del atacante.
El navegador de las víctimas ejecutará el script malicioso sin saber que no se debe confiar. Por lo tanto, el navegador le permitirá acceder a tokens de sesión, cookies o información confidencial almacenada por el navegador. Si se programa correctamente, las secuencias de comandos podrían incluso reescribir el contenido de un archivo HTML.
Los ataques XSS generalmente se pueden dividir en dos categorías diferentes: almacenados y reflejados.
En los ataques XSS almacenados , el script malicioso reside permanentemente en el servidor de destino, en un foro de mensajes, en una base de datos, en un registro de visitantes, etc. La víctima lo obtiene cuando su navegador solicita la información almacenada. En los ataques XSS reflejados , el script malicioso se refleja en una respuesta que incluye la entrada enviada al servidor. Esto podría ser un mensaje de error o un resultado de búsqueda, por ejemplo.
Inyección XPath
Este tipo de ataque es posible cuando una aplicación web utiliza la información proporcionada por un usuario para crear una consulta XPath para datos XML. La forma en que funciona este ataque es similar a la inyección SQL : los atacantes envían información con formato incorrecto a la aplicación para averiguar cómo se estructuran los datos XML, y luego atacan nuevamente para acceder a esos datos.
XPath es un lenguaje estándar con el que, como SQL, puede especificar los atributos que desea encontrar. Para realizar una consulta sobre datos XML, las aplicaciones web utilizan la entrada del usuario para establecer un patrón que los datos deben coincidir. Al enviar una entrada con formato incorrecto, el patrón puede convertirse en una operación que el atacante quiere aplicar a los datos.
A diferencia de lo que sucede con SQL, en XPath, no hay versiones diferentes. Esto significa que la inyección de XPath se puede realizar en cualquier aplicación web que use datos XML, independientemente de la implementación. Eso también significa que el ataque puede ser automatizado; por lo tanto, a diferencia de la inyección SQL, tiene el potencial de dispararse contra un número arbitrario de objetivos.
Inyección de comando de correo
Este método de ataque se puede utilizar para explotar los servidores de correo electrónico y las aplicaciones que crean declaraciones IMAP o SMTP con una entrada del usuario incorrectamente validada. Ocasionalmente, los servidores IMAP y SMTP no tienen una fuerte protección contra ataques, como sería el caso con la mayoría de los servidores web, y por lo tanto podrían ser más explotables. Al ingresar a través de un servidor de correo, los atacantes podrían evadir restricciones como captchas, un número limitado de solicitudes, etc.
Para explotar un servidor SMTP, los atacantes necesitan una cuenta de correo electrónico válida para enviar mensajes con comandos inyectados. Si el servidor es vulnerable, responderá a las solicitudes de los atacantes, permitiéndoles, por ejemplo, anular las restricciones del servidor y usar sus servicios para enviar spam.
La inyección de IMAP podría realizarse principalmente en aplicaciones de correo web, explotando la funcionalidad de lectura de mensajes. En estos casos, el ataque se puede realizar simplemente ingresando, en la barra de direcciones de un navegador web, una URL con los comandos inyectados.
Inyección CRLF
La inserción de caracteres de retorno de carro y avance de línea, combinación conocida como CRLF, en los campos de entrada de formulario web representa un método de ataque llamado inyección CRLF. Estos caracteres invisibles indican el final de una línea o el final de un comando en muchos protocolos de Internet tradicionales, como HTTP, MIME o NNTP.
Por ejemplo, la inserción de un CRLF en una solicitud HTTP, seguida de cierto código HTML, podría enviar páginas web personalizadas a los visitantes de un sitio web.
Este ataque se puede realizar en aplicaciones web vulnerables que no aplican el filtrado adecuado a la entrada del usuario. Esta vulnerabilidad abre la puerta a otros tipos de ataques de inyección, como XSS e inyección de código, y también podría derivar en un sitio web que está siendo secuestrado.
Inyección de encabezado de host
En los servidores que alojan muchos sitios web o aplicaciones web, el encabezado del host se hace necesario para determinar cuáles de los sitios web o aplicaciones residentes, cada uno de ellos conocido como host virtual, debe procesar una solicitud entrante. El valor del encabezado le dice al servidor a cuál de los hosts virtuales debe enviar una solicitud. Cuando el servidor recibe un encabezado de host no válido, generalmente lo pasa al primer host virtual de la lista. Esto constituye una vulnerabilidad que los atacantes pueden usar para enviar encabezados de host arbitrarios al primer host virtual en un servidor.
La manipulación del encabezado del host se relaciona comúnmente con las aplicaciones PHP, aunque también se puede hacer con otras tecnologías de desarrollo web. Los ataques de encabezado de host funcionan como habilitadores para otros tipos de ataques, como el envenenamiento de caché web. Sus consecuencias podrían incluir la ejecución de operaciones sensibles por parte de los atacantes, por ejemplo, restablecimiento de contraseña.
Inyección LDAP
LDAP es un protocolo diseñado para facilitar la búsqueda de recursos (dispositivos, archivos, otros usuarios) en una red. Es muy útil para las intranets, y cuando se usa como parte de un sistema de inicio de sesión único, se puede usar para almacenar nombres de usuario y contraseñas. Las consultas LDAP implican el uso de caracteres de control especiales que afectan su control. Los atacantes pueden cambiar potencialmente el comportamiento previsto de una consulta LDAP si pueden insertar caracteres de control en ella.
Nuevamente, el problema raíz que permite los ataques de inyección LDAP es la entrada de usuario validada incorrectamente. Si el texto que un usuario envía a una aplicación se usa como parte de una consulta LDAP sin desinfectarlo, la consulta podría terminar recuperando una lista de todos los usuarios y mostrándola a un atacante, simplemente usando un asterisco (*) a la derecha colocar dentro de una cadena de entrada.
Prevención de ataques de inyección
Como vimos en este artículo, todos los ataques de inyección están dirigidos a servidores y aplicaciones con acceso abierto a cualquier usuario de Internet. La responsabilidad de prevenir estos ataques se distribuye entre los desarrolladores de aplicaciones y los administradores del servidor.
Los desarrolladores de aplicaciones necesitan conocer los riesgos involucrados en la validación incorrecta de la entrada del usuario y aprender las mejores prácticas para desinfectar la entrada del usuario con fines de prevención de riesgos. Los administradores del servidor deben auditar sus sistemas periódicamente para detectar vulnerabilidades y corregirlos lo antes posible. Hay muchas opciones para realizar estas auditorías, ya sea a pedido o de forma automática.
Leer también:Mejores prácticas de prevención de pérdida de datos; Cómo evitar convertirse en una víctima de ransomware: consejos y mejores prácticas; ¿Es un Vps más rápido y seguro que un hosting compartido?
More from Hosting
Servidores Dedicados: ¿Qué son y por qué podrías necesitar uno?
En la era digital actual, la presencia en línea se ha convertido en un pilar fundamental para empresas y emprendedores. …
Protegiendo tu Blog de Ataques de Rastreo y Scraping
En el mundo digital actual, los blogs son una parte integral de la expresión personal y profesional en línea. Sin …
Soluciones a 5 problemas comunes del server room
Soluciones a 5 problemas comunes del server room. Cuando se trata de seguridad para la red de su empresa, la …