22 vulnerabilidades comunes de aplicaciones web que debe conocer
Publicado: 2021-10-14Las empresas están constantemente "desplazándose hacia la izquierda" y aprovechando las innovadoras experiencias de clientes y empleados que ofrecen las aplicaciones basadas en la nube. Al mismo tiempo, los perpetradores malintencionados también revisan continuamente sus estrategias de ataque para adaptarse a este cambio.
Para preservar la privacidad y seguridad de los datos, es imperativo que las empresas busquen protección contra estas 22 vulnerabilidades comunes de aplicaciones web .
Control de acceso dañado
Los controles de acceso son responsables de cómo los usuarios interactúan con los recursos y los datos, así como de lo que pueden editar y/o leer. Una vulnerabilidad de control de acceso defectuosa es posible cuando el usuario puede acceder a los datos de una manera que es realmente innecesaria. Por ejemplo, si el usuario solo debe ser capaz de leer los detalles del pago pero en realidad tiene la capacidad de editarlos, tal situación ejemplifica un control de acceso roto. Los atacantes malintencionados aprovechan esta vulnerabilidad para obtener acceso no autorizado a software, redes y sistemas. Luego pueden aprovechar la situación, otorgar a la ID de usuario más acceso dentro de la infraestructura, para comprometer la disponibilidad, confidencialidad o integridad de los datos.
Autenticación dañada
Las vulnerabilidades de las aplicaciones web asociadas con la autenticación dañada o rota también se derivan del acceso del usuario. En este caso, sin embargo, los atacantes maliciosos impactan negativamente en los datos que confirman la identidad de un usuario, por ejemplo, mediante el secuestro de tokens de sesión, claves o contraseñas. El atacante malicioso obtiene acceso no autorizado al software, los sistemas y las redes porque la organización no pudo establecer adecuadamente los controles adecuados de administración de acceso e identidad.
Inyección de retorno de carro y avance de línea (CRLF)
El retorno de carro actúa como un comando que indica el comienzo de una línea de código, normalmente indicado como /r. El avance de línea, por otro lado, es un comando que indica el final de una línea de código, normalmente indicado como /n. Al igual que varios otros programas, cada sistema operativo utiliza diversas combinaciones de retorno de carro y avance de línea. Cuando los atacantes maliciosos están involucrados en las inyecciones de CRLF, el código ingresado altera la forma en que la aplicación web reacciona a los comandos. Esto puede usarse para divulgar datos confidenciales o ejecutar código.
Transformación de cifrado insegura
Cifrado, que es un término estándar para "algoritmo de cifrado", es en realidad las matemáticas detrás de un proceso de cifrado o descifrado. La transformación se refiere al esquema de las operaciones realizadas en la entrada para entregar la salida esperada. Por lo tanto, una transformación de cifrado se refiere a la cantidad de operaciones que convierten los datos cifrados ilegibles en datos descifrados legibles. Una vulnerabilidad insegura de transformación de cifrado describe que el algoritmo de cifrado se puede romper fácilmente y, en última instancia, sabotear la esencia del cifrado en primera instancia.
Componentes con vulnerabilidades obvias
Toda aplicación web depende de otros componentes para funcionar. Por ejemplo, si está operando una aplicación en un servidor web o de aplicaciones sin parches, el servidor es la parte con vulnerabilidades obvias. La lista de vulnerabilidades y exposiciones comunes (CVE) comprende todas las vulnerabilidades de seguridad conocidas. Debido a que los atacantes malintencionados tienen conocimiento de la lista, con frecuencia buscan componentes sin las actualizaciones de parches de seguridad adecuadas. En el momento en que pueden infiltrarse en un componente de la aplicación web, también pueden obtener acceso a los datos de la aplicación.
Política de Intercambio de Recursos de Origen Cruzado (CORS)
Todas las aplicaciones basadas en web utilizan una URL como medio para conectar el navegador del usuario a su servidor. La Póliza del Mismo Origen es una protección común. De acuerdo con esto, el servidor responderá solo a una URL con el mismo protocolo, esquema de ruta y nombre de dominio de nivel superior. Lo que esto significa es que puede acceder a http://organization.com/page1 y http://organization.com/page2 porque ambos comparten lo siguiente:
- Protocolo: HTTP
- Dominio: Empresa.com
- Esquema de ruta: /página#
Si bien es segura, la Política del mismo origen es restrictiva cuando se trata de aplicaciones basadas en la web que requieren acceso a recursos que se conectan a terceros o subdominios.
Una política de CORS otorga permiso al navegador para ver estos recursos interrelacionados mediante el establecimiento de una cantidad de encabezados HTTP permitidos que se consideran "de confianza". Por ejemplo, una aplicación podría tener que extraer datos de dos bases de datos en servidores web separados. Redactar una lista "permitida" en particular se convierte en un trabajo excesivo a medida que incluye servidores adicionales. Dado que ambos servidores "comparten" la aplicación, la empresa escribe una política CORS que permite que los navegadores se conecten a ambos. Sin embargo, si una política de CORS no está definida correctamente, entonces la política puede permitir que los servidores otorguen acceso cuando lo solicite un atacante malintencionado.
Gestión de credenciales
Las credenciales de usuario comprenden un ID de usuario y una clave de paso. El usuario debe proporcionar ambos elementos de información en la página de inicio de sesión antes de obtener acceso a una aplicación. Sin embargo, las bases de datos tienden a usar un cifrado débil o mantienen la información en texto sin formato. La gestión deficiente de las credenciales permite a los atacantes robar fácilmente las credenciales y explotarlas para obtener acceso a las aplicaciones web.
Falsificación de solicitud entre sitios (CSRF)
Un ataque CSRF utiliza metodologías de ingeniería social para impulsar a un usuario a modificar información, como contraseñas o nombres de usuario, en una aplicación. Un CSRF, a diferencia de los ataques de secuencias de comandos en sitios cruzados (XXS) o malware, requiere que un usuario inicie sesión en la aplicación que utiliza solo cookies de sesión para validar las solicitudes de los usuarios o realizar un seguimiento de las sesiones. En el momento en que el usuario realiza la acción anticipada, el actor malicioso usa el navegador para ejecutar la parte restante del ataque, como mover fondos, sin que el usuario sepa lo que sucedió.
Script entre sitios (XXS)
A diferencia de un CSRF que requiere que el usuario inicie sesión en una aplicación para ser engañado y cambiar cierta información, un ataque XXS requiere que el atacante malintencionado ingrese código en una página web, generalmente en algunos componentes de la página, como una imagen. Una vez que un usuario inicia la página web en su navegador, el código incorrecto comienza a descargarse y ejecutarse en el navegador. Por ejemplo, el código malicioso puede redirigir al usuario de un sitio confiable a uno ilegítimo.
Indexación de directorios
Por lo general, los servidores web describen todos los archivos guardados en ellos en un solo directorio. Cuando un usuario desea ubicar un archivo en particular en una aplicación web, generalmente agrega el nombre del archivo en la solicitud. En caso de que el archivo no esté disponible, la aplicación le presentará al usuario una lista de todos los archivos indexados, de modo que el usuario tenga la opción de seleccionar otra cosa.
Sin embargo, los servidores web indexan automáticamente los archivos. Cuando la aplicación presenta una lista de todos los archivos almacenados, un atacante malicioso aprovechando las vulnerabilidades en el índice del directorio puede obtener acceso a datos que le pueden dar más información sobre el sistema. Por ejemplo, pueden conocer las cuentas de usuario personales o las convenciones de nomenclatura. Estos dos puntos de datos pueden explotarse para llevar a cabo ataques de robo de credenciales o desentrañar información confidencial.
Recorrido de directorio
También conocida como ataque de retroceso, punto-punto-barra y escalada de directorios, la vulnerabilidad de cruce de directorios explota la forma en que una aplicación recibe datos del servidor web. Las listas de control de acceso (ACL) generalmente restringen el acceso de los usuarios a ciertos archivos dentro de un directorio raíz. Los atacantes malintencionados que utilizan el modo de vulnerabilidad transversal de directorio descubren el formato de URL que utiliza la aplicación para solicitar archivos.
Encapsulación
A diferencia de algunas de las otras vulnerabilidades de aplicaciones web comunes en la lista, la vulnerabilidad de encapsulación aprovecha las fallas en la forma en que un desarrollador ha codificado la aplicación. La encapsulación es un término de programación que se refiere a la agrupación de datos y acciones que se pueden realizar con esos datos en una sola unidad. La encapsulación protege los datos al ocultar información sobre cómo se ejecuta el código, lo que ofrece una mejor interfaz de usuario. Los usuarios no tienen que saber cómo les entrega los datos la aplicación; todo lo que necesitan es acceso a él.
Por ejemplo, un desarrollador de aplicaciones puede incluir controles de acceso, como permisos de lectura o escritura, en la capacidad de una aplicación para recuperar datos. Si el usuario solicita información en la aplicación, esta entrega solo los datos a los que se le ha permitido acceder.
Pero si los desarrolladores no establecen límites claramente definidos entre los datos y las acciones realizadas en varios aspectos de la aplicación, la aplicación sufre una vulnerabilidad de encapsulación. Los atacantes se aprovechan de esto enviando una solicitud a la aplicación, sabiendo que dicha acción generaría un mensaje de error. Este mensaje de error proporciona información sobre la estructura de la aplicación, lo que ayuda a más estrategias de ataque, como un DOS: denegación de servicio.
Referencias a objetos directos inseguros (IDOR)
Las URL de aplicaciones web pueden exponer el patrón o el formato empleado para dirigir a los usuarios a las ubicaciones de almacenamiento de back-end. Por ejemplo, una URL puede mostrar el patrón/formato de un identificador de registro en un sistema de almacenamiento como un sistema de archivos o una base de datos.
El IDOR por sí solo podría ser una preocupación de bajo riesgo. Sin embargo, cuando un IDOR se combina con una verificación de control de acceso fallida, los atacantes tienen la oportunidad de atacar con éxito.
Otras vulnerabilidades comunes de aplicaciones web que debe conocer son:
División de respuesta HTTP
Este es un tipo de ataque de inyección CRLF. HTTP es el proceso a través del cual los navegadores envían consultas y los servidores devuelven las respuestas. En esta vulnerabilidad de la aplicación web, los atacantes maliciosos hacen uso de las notaciones CR y LR para manipular cómo los navegadores y los servidores se comunican entre sí, lo que entrega una solicitud pero le dice al servidor que "divida" la respuesta en varias partes. Dividir la respuesta en dos partes diferentes permite que el actor malicioso obtenga control sobre la información que el servidor entrega en respuesta a la otra parte de la solicitud. Cuando dichos datos solicitados son datos de identificación de usuario o información confidencial, el actor malicioso ha realizado con éxito el ataque.
Defecto de inyección
Una falla de inyección permite una plétora de varias técnicas de ataque. Cualquier aplicación que permita a los usuarios actualizar el comando de shell, la llamada al sistema operativo o una base de datos puede sufrir una falla de inyección. Los atacantes maliciosos aprovechan las fallas de inyección para alterar los comandos que se convierten en acciones nuevas e inesperadas dentro de la aplicación. Al aprovechar estas vulnerabilidades, los actores malintencionados pueden crear, actualizar, leer o incluso eliminar datos.
Vulnerabilidad de resumen de mensaje inseguro
Esta es una vulnerabilidad criptográfica que limita la efectividad del cifrado. Un resumen de mensaje debe comprender la función hash criptográfica. A diferencia del cifrado, las funciones hash no requieren que el remitente y los usuarios usen claves.
Por lo tanto, los atacantes maliciosos se aprovechan de las vulnerabilidades de resumen inseguro para perpetuar el "ataque de colisión de hash". El objetivo del ataque es averiguar si el envío de una entrada conduce a la generación de un hash duplicado. Si la acción maliciosa genera por la fuerza un hash compartido, entonces pueden usar este hash para presentar un archivo malicioso para descargar. Esto, a su vez, deja al usuario final con la suposición de que el archivo es legítimo.
Protección insuficiente de la capa de transporte
La seguridad de la capa de transporte (TLS) se refiere al proceso a través del cual las aplicaciones informáticas pueden "comunicarse" de forma segura entre sí en Internet. Varias aplicaciones solo utilizan TLS durante el proceso de autenticación, lo que hace que los datos y la información de la sesión de identificación sean vulnerables cuando una persona usa la aplicación.
Los atacantes pueden aprovechar esta vulnerabilidad para desviar datos a medida que se mueven a través de Internet entre el dispositivo del usuario y el servidor de aplicaciones.
Ejecución remota de código (RCE)
Las vulnerabilidades de ejecución remota de código son errores de codificación en aplicaciones web que permiten a los atacantes maliciosos insertar código independientemente de su ubicación geográfica. Los RCE se incluyen en una categoría más amplia de vulnerabilidades de inyección de aplicaciones web en las que los atacantes ingresan su propio código en una aplicación que no confirmará las entradas del usuario, lo que hace que el servidor lo vea como un código de aplicación genuino. Por lo general, los atacantes maliciosos se aprovecharán de las vulnerabilidades comúnmente conocidas sin parches e insertarán su código en la aplicación.
Inclusión remota de archivos (RFI)
Para vincular directorios comunes a una aplicación, los desarrolladores agregan declaraciones de "inclusión" en su código. Por ejemplo, una aplicación podría tener que extraer datos de una base de datos. En lugar de codificarlo manualmente para obtener cada archivo, la declaración "incluir" ayuda a vincular todo el directorio de origen para que todo lo almacenado allí pueda usarse.
Cuando una aplicación web sufre una vulnerabilidad RFI, los atacantes pueden manipular la aplicación para cargar código malicioso o malware en la base de datos, el servidor o el sitio web.
Configuración incorrecta de seguridad
La probabilidad de una mala configuración de seguridad es, de hecho, una de las vulnerabilidades de aplicaciones web más comunes en la actualidad. Esta vulnerabilidad generalmente ocurrirá debido a que una organización no modificó la configuración de seguridad predeterminada. Las configuraciones incorrectas de seguridad comunes son:
- Hacer uso de contraseñas o cuentas predeterminadas
- software sin parches
- Sin encriptación
- Políticas de cortafuegos inadecuadas
- Descuidar los recursos, características y otros componentes no utilizados
inyección SQL
SQL, que significa lenguaje de consulta estructurado, es un lenguaje de programación utilizado para bases de datos. Permite la recuperación y manipulación de datos para bases de datos relacionales. Una vulnerabilidad de inyección SQL se encuentra bajo un grupo más grande de entradas de usuarios no verificadas. Cuando los actores malintencionados envían deliberadamente solicitudes falsas, la aplicación web responde con un mensaje de error que les proporciona información sobre la estructura y protección de la base de datos.
Activación de biblioteca automática no validada
Para ahorrar tiempo al codificar, los desarrolladores tienden a usar bibliotecas de terceros. En la mayoría de los casos, esto les permite hacer uso de código previamente probado que acelera el proceso de desarrollo de aplicaciones. Sin embargo, hacer uso de código de fuente abierta disponible públicamente aumenta los riesgos de seguridad, que incluyen:
- La ausencia de propiedad documentada aumenta el riesgo de código maligno agregado
- Proyectos descuidados que ya no se actualizan
Esta vulnerabilidad en particular es cada vez más frecuente, considerando que varias aplicaciones involucran dependencias de bibliotecas de terceros.
Esperamos que el contenido de esta publicación de blog haya sido realmente útil y revelador para usted. Asegurarse de encontrar una solución para cualquier vulnerabilidad de la aplicación web que se aplique a su caso cambiará las reglas del juego en las experiencias de sus empleados y clientes.