{"id":789,"date":"2020-03-31T08:00:26","date_gmt":"2020-03-31T13:00:26","guid":{"rendered":"https:\/\/www.hostdime.la\/blog\/?p=789"},"modified":"2026-05-04T09:50:53","modified_gmt":"2026-05-04T14:50:53","slug":"tipos-populares-de-ataques-de-inyeccion-de-aplicaciones-web","status":"publish","type":"post","link":"https:\/\/www.hostdime.la\/blog\/tipos-populares-de-ataques-de-inyeccion-de-aplicaciones-web\/","title":{"rendered":"Tipos populares de ataques de inyecci\u00f3n de aplicaciones web"},"content":{"rendered":"<p style=\"text-align: justify;\">Tipos populares de ataques de inyecci\u00f3n de aplicaciones web.El problema con las aplicaciones web es que est\u00e1n expuestas abiertamente a miles de millones de usuarios de Internet, muchos de los cuales querr\u00e1n romper sus medidas de seguridad, por cualquier raz\u00f3n.<!--more--><\/p>\n<p style=\"text-align: justify;\">En los primeros d\u00edas de Internet, uno de los m\u00e9todos de ataque m\u00e1s comunes era la fuerza bruta b\u00e1sica 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\u00f1as hasta que encontraban uno que les permitiera acceder a la aplicaci\u00f3n de destino.<\/p>\n<p style=\"text-align: justify;\">Los ataques de fuerza bruta ya no son una amenaza, gracias a las pol\u00edticas de contrase\u00f1a, intentos de inicio de sesi\u00f3n limitados y captchas. Pero a los cibercriminales les encanta descubrir nuevas haza\u00f1as y usarlas para realizar nuevos tipos de ataques. Hace mucho tiempo, descubrieron que los campos de texto en aplicaciones o p\u00e1ginas web pod\u00edan explotarse ingresando \u2013o inyectando\u2013 texto inesperado que obligar\u00eda a la aplicaci\u00f3n a hacer algo que no deb\u00eda hacer. De esa manera, los llamados ataques de inyecci\u00f3n entraron en escena.<\/p>\n<p style=\"text-align: justify;\">Los ataques de inyecci\u00f3n se pueden usar no solo para iniciar sesi\u00f3n en una aplicaci\u00f3n sin conocer el nombre de usuario y la contrase\u00f1a, sino tambi\u00e9n para exponer informaci\u00f3n privada, confidencial o confidencial, o incluso para secuestrar un <a href=\"https:\/\/www.hostdime.com.es\/servidores-dedicados\" target=\"_blank\" rel=\"noopener noreferrer\">servidor<\/a> completo. Es por eso que estos ataques no son solo una amenaza para las aplicaciones web , sino tambi\u00e9n para los usuarios cuyos datos residen en esas aplicaciones y, en el peor de los casos, para otras aplicaciones y servicios conectados.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n de c\u00f3digo<\/span><\/h2>\n<p style=\"text-align: justify;\">La inyecci\u00f3n de c\u00f3digo es uno de los tipos m\u00e1s comunes de ataques de inyecci\u00f3n. Si los atacantes conocen el lenguaje de programaci\u00f3n, el marco, la base de datos o el sistema operativo utilizado por una aplicaci\u00f3n web, pueden inyectar c\u00f3digo a trav\u00e9s de campos de entrada de texto para obligar al servidor web a hacer lo que quieran.<\/p>\n<p style=\"text-align: justify;\">Estos tipos de ataques de inyecci\u00f3n son posibles en aplicaciones que carecen de validaci\u00f3n de datos de entrada. Si un campo de entrada de texto permite a los usuarios ingresar lo que quieran, entonces la aplicaci\u00f3n es potencialmente explotable. Para evitar estos ataques, la aplicaci\u00f3n necesita restringir tanto como sea posible a los usuarios de entrada que pueden ingresar.<br \/>\nPor ejemplo, necesita limitar la cantidad de datos esperados, verificar el formato de datos antes de aceptarlo y restringir el conjunto de caracteres permitidos.<\/p>\n<p style=\"text-align: justify;\">Las vulnerabilidades de inyecci\u00f3n de c\u00f3digo pueden ser f\u00e1ciles de encontrar, simplemente probando la entrada de texto de una aplicaci\u00f3n web con diferentes tipos de contenido. Cuando se encuentran, las vulnerabilidades son moderadamente dif\u00edciles de explotar. Pero cuando un atacante logra explotar una de estas vulnerabilidades, el impacto podr\u00eda incluir la p\u00e9rdida de confidencialidad, integridad, disponibilidad o funcionalidad de la aplicaci\u00f3n.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n SQL<\/span><\/h2>\n<p style=\"text-align: justify;\">De manera similar a la inyecci\u00f3n de c\u00f3digo, este ataque inserta un script SQL, el lenguaje utilizado por la mayor\u00eda de las bases de datos para realizar operaciones de consulta, en un campo de entrada de texto. El script se env\u00eda a la aplicaci\u00f3n, que lo ejecuta directamente en su base de datos. Como resultado, el atacante podr\u00eda pasar por una pantalla de inicio de sesi\u00f3n o hacer cosas m\u00e1s 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\u00f3n en la base de datos.<\/p>\n<p style=\"text-align: justify;\">Las aplicaciones PHP y ASP son propensas a los ataques de inyecci\u00f3n SQL debido a sus interfaces funcionales m\u00e1s antiguas. Las aplicaciones J2EE y ASP.Net generalmente est\u00e1n m\u00e1s protegidas contra estos ataques. Cuando se encuentra una vulnerabilidad de inyecci\u00f3n SQL, y podr\u00edan encontrarse f\u00e1cilmente, la magnitud de los posibles ataques solo estar\u00e1 limitada por la habilidad y la imaginaci\u00f3n del atacante. Por lo tanto, el impacto de un ataque de inyecci\u00f3n SQL es indudablemente alto.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n de comando<\/span><\/h2>\n<p style=\"text-align: justify;\">Estos ataques tambi\u00e9n son posibles, principalmente debido a una validaci\u00f3n de entrada insuficiente. Se diferencian de los ataques de inyecci\u00f3n de c\u00f3digo en que el atacante inserta comandos del sistema en lugar de fragmentos de c\u00f3digo o scripts de programaci\u00f3n. Por lo tanto, el hacker no necesita saber el lenguaje de programaci\u00f3n en el que se basa la aplicaci\u00f3n o el lenguaje utilizado por la base de datos. Pero necesitan saber el sistema operativo utilizado por el servidor de alojamiento.<\/p>\n<p style=\"text-align: justify;\">El sistema operativo host ejecuta los comandos del sistema insertados con los privilegios de la aplicaci\u00f3n, lo que podr\u00eda permitir exponer el contenido de archivos arbitrarios que residen en el servidor, mostrar la estructura de directorios de un servidor, cambiar las contrase\u00f1as de los usuarios, entre otras cosas. .<\/p>\n<p style=\"text-align: justify;\">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.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Secuencias de comandos entre sitios<\/span><\/h2>\n<p style=\"text-align: justify;\">Cada vez que una aplicaci\u00f3n inserta informaci\u00f3n de un usuario dentro de la salida que genera, sin validarla o codificarla, le da la oportunidad a un atacante de enviar c\u00f3digo 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\u00edan a otros usuarios de la aplicaci\u00f3n, que se convierten en v\u00edctimas del atacante.<\/p>\n<p style=\"text-align: justify;\">El navegador de las v\u00edctimas ejecutar\u00e1 el script malicioso sin saber que no se debe confiar. Por lo tanto, el navegador le permitir\u00e1 acceder a tokens de sesi\u00f3n, cookies o informaci\u00f3n confidencial almacenada por el navegador. Si se programa correctamente, las secuencias de comandos podr\u00edan incluso reescribir el contenido de un archivo HTML.<br \/>\nLos ataques XSS generalmente se pueden dividir en dos categor\u00edas diferentes: almacenados y reflejados.<\/p>\n<p style=\"text-align: justify;\">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\u00edctima lo obtiene cuando su navegador solicita la informaci\u00f3n almacenada. En los ataques XSS reflejados , el script malicioso se refleja en una respuesta que incluye la entrada enviada al servidor. Esto podr\u00eda ser un mensaje de error o un resultado de b\u00fasqueda, por ejemplo.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n XPath<\/span><\/h2>\n<p style=\"text-align: justify;\">Este tipo de ataque es posible cuando una aplicaci\u00f3n web utiliza la informaci\u00f3n proporcionada por un usuario para crear una consulta XPath para datos XML. La forma en que funciona este ataque es similar a la inyecci\u00f3n SQL : los atacantes env\u00edan informaci\u00f3n con formato incorrecto a la aplicaci\u00f3n para averiguar c\u00f3mo se estructuran los datos XML, y luego atacan nuevamente para acceder a esos datos.<\/p>\n<p style=\"text-align: justify;\">XPath es un lenguaje est\u00e1ndar 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\u00f3n que los datos deben coincidir. Al enviar una entrada con formato incorrecto, el patr\u00f3n puede convertirse en una operaci\u00f3n que el atacante quiere aplicar a los datos.<\/p>\n<p style=\"text-align: justify;\">A diferencia de lo que sucede con SQL, en XPath, no hay versiones diferentes. Esto significa que la inyecci\u00f3n de XPath se puede realizar en cualquier aplicaci\u00f3n web que use datos XML, independientemente de la implementaci\u00f3n. Eso tambi\u00e9n significa que el ataque puede ser automatizado; por lo tanto, a diferencia de la inyecci\u00f3n SQL, tiene el potencial de dispararse contra un n\u00famero arbitrario de objetivos.<a href=\"https:\/\/www.hostdime.la\/blog\/?attachment_id=806\" rel=\"attachment wp-att-806\"><img decoding=\"async\" class=\"alignleft  wp-image-806\" src=\"https:\/\/www.hostdime.la\/blog\/wp-content\/uploads\/2020\/03\/interno-post-seguridad-01-compressor-300x206.png\" alt=\"\" width=\"891\" height=\"611\" title=\"\"><\/a><\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n de comando de correo<\/span><\/h2>\n<p style=\"text-align: justify;\">Este m\u00e9todo de ataque se puede utilizar para explotar los servidores de correo electr\u00f3nico 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\u00f3n contra ataques, como ser\u00eda el caso con la mayor\u00eda de los servidores web, y por lo tanto podr\u00edan ser m\u00e1s explotables. Al ingresar a trav\u00e9s de un servidor de correo, los atacantes podr\u00edan evadir restricciones como captchas, un n\u00famero limitado de solicitudes, etc.<\/p>\n<p style=\"text-align: justify;\">Para explotar un servidor SMTP, los atacantes necesitan una cuenta de correo electr\u00f3nico v\u00e1lida para enviar mensajes con comandos inyectados. Si el servidor es vulnerable, responder\u00e1 a las solicitudes de los atacantes, permiti\u00e9ndoles, por ejemplo, anular las restricciones del servidor y usar sus servicios para enviar spam.<\/p>\n<p style=\"text-align: justify;\">La inyecci\u00f3n de IMAP podr\u00eda 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.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n CRLF<\/span><\/h2>\n<p style=\"text-align: justify;\">La inserci\u00f3n de caracteres de retorno de carro y avance de l\u00ednea, combinaci\u00f3n conocida como CRLF, en los campos de entrada de formulario web representa un m\u00e9todo de ataque llamado inyecci\u00f3n CRLF. Estos caracteres invisibles indican el final de una l\u00ednea o el final de un comando en muchos protocolos de Internet tradicionales, como HTTP, MIME o NNTP.<\/p>\n<p style=\"text-align: justify;\">Por ejemplo, la inserci\u00f3n de un CRLF en una solicitud HTTP, seguida de cierto c\u00f3digo HTML, podr\u00eda enviar p\u00e1ginas web personalizadas a los visitantes de un sitio web.<\/p>\n<p style=\"text-align: justify;\">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\u00f3n, como XSS e inyecci\u00f3n de c\u00f3digo, y tambi\u00e9n podr\u00eda derivar en un sitio web que est\u00e1 siendo secuestrado.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n de encabezado de host<\/span><\/h2>\n<p style=\"text-align: justify;\">En los servidores que alojan muchos sitios web o aplicaciones web, el encabezado del host se hace necesario para determinar cu\u00e1les 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\u00e1l de los hosts virtuales debe enviar una solicitud. Cuando el servidor recibe un encabezado de host no v\u00e1lido, 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.<\/p>\n<p style=\"text-align: justify;\">La manipulaci\u00f3n del encabezado del host se relaciona com\u00fanmente con las aplicaciones PHP, aunque tambi\u00e9n se puede hacer con otras tecnolog\u00edas de desarrollo web. Los ataques de encabezado de host funcionan como habilitadores para otros tipos de ataques, como el envenenamiento de cach\u00e9 web. Sus consecuencias podr\u00edan incluir la ejecuci\u00f3n de operaciones sensibles por parte de los atacantes, por ejemplo, restablecimiento de contrase\u00f1a.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Inyecci\u00f3n LDAP<\/span><\/h2>\n<p style=\"text-align: justify;\">LDAP es un protocolo dise\u00f1ado para facilitar la b\u00fasqueda de recursos (dispositivos, archivos, otros usuarios) en una red. Es muy \u00fatil para las intranets, y cuando se usa como parte de un sistema de inicio de sesi\u00f3n \u00fanico, se puede usar para almacenar nombres de usuario y contrase\u00f1as. 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.<br \/>\nNuevamente, el problema ra\u00edz que permite los ataques de inyecci\u00f3n LDAP es la entrada de usuario validada incorrectamente. Si el texto que un usuario env\u00eda a una aplicaci\u00f3n se usa como parte de una consulta LDAP sin desinfectarlo, la consulta podr\u00eda terminar recuperando una lista de todos los usuarios y mostr\u00e1ndola a un atacante, simplemente usando un asterisco (*) a la derecha colocar dentro de una cadena de entrada.<\/p>\n<h2 style=\"text-align: justify;\"><span style=\"color: #ff6600;\">Prevenci\u00f3n de ataques de inyecci\u00f3n<\/span><\/h2>\n<p style=\"text-align: justify;\">Como vimos en este art\u00edculo, todos los ataques de inyecci\u00f3n est\u00e1n 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.<\/p>\n<p style=\"text-align: justify;\">Los desarrolladores de aplicaciones necesitan conocer los riesgos involucrados en la validaci\u00f3n incorrecta de la entrada del usuario y aprender las mejores pr\u00e1cticas para desinfectar la entrada del usuario con fines de prevenci\u00f3n de riesgos. Los administradores del servidor deben auditar sus sistemas peri\u00f3dicamente para detectar vulnerabilidades y corregirlos lo antes posible. Hay muchas opciones para realizar estas auditor\u00edas, ya sea a pedido o de forma autom\u00e1tica.<\/p>\n<p>Leer tambi\u00e9n:<a href=\"https:\/\/www.hostdime.la\/blog\/mejores-practicas-de-prevencion-de-perdida-de-datos\/\" target=\"_blank\" rel=\"noopener noreferrer\">Mejores pr\u00e1cticas de prevenci\u00f3n de p\u00e9rdida de datos<\/a>; <a href=\"https:\/\/www.hostdime.la\/blog\/como-evitar-convertirse-en-una-victima-de-ransomware-consejos-y-mejores-practicas\/\" target=\"_blank\" rel=\"noopener noreferrer\">C\u00f3mo evitar convertirse en una v\u00edctima de ransomware: consejos y mejores pr\u00e1cticas<\/a>; <a href=\"https:\/\/www.hostdime.la\/blog\/es-un-vps-mas-rapido-y-seguro-que-un-hosting-compartido\/\" target=\"_blank\" rel=\"noopener noreferrer\">\u00bfEs un Vps m\u00e1s r\u00e1pido y seguro que un hosting compartido?<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Tipos populares de ataques de inyecci\u00f3n de aplicaciones web.El problema con las aplicaciones web es que est\u00e1n expuestas abiertamente a miles de millones de usuarios de Internet, muchos de los cuales querr\u00e1n romper sus medidas de seguridad, por cualquier raz\u00f3n.<\/p>\n","protected":false},"author":2,"featured_media":804,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-789","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting"],"jetpack_featured_media_url":"https:\/\/www.hostdime.la\/blog\/wp-content\/uploads\/2020\/03\/tipos-02-compressor.png","_links":{"self":[{"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/posts\/789","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/comments?post=789"}],"version-history":[{"count":1,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/posts\/789\/revisions"}],"predecessor-version":[{"id":1280,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/posts\/789\/revisions\/1280"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/media\/804"}],"wp:attachment":[{"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/media?parent=789"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/categories?post=789"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hostdime.la\/blog\/wp-json\/wp\/v2\/tags?post=789"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}