Usted sabe que su última aplicación web es intrínsecamente vulnerable a todo tipo de ataques. También sabes que la seguridad de las aplicaciones nunca puede ser perfecta, pero puedes hacer que mañana sea mejor que ayer.
El problema es que, tanto si utiliza herramientas de seguridad de nivel empresarial (es decir, caras y complejas), como si ha improvisado un puñado de proyectos de código abierto en una canalización CI/CD o ganchos de commit de Git y espera lo mejor, su conjunto de herramientas no puede ayudarle a ver:
- Cómo su aplicación podría ser vulnerable debido a prácticas de programación menos que ideales, dependencias inseguras y más.
- Dónde más probable es que las vulnerabilidades se escondan, hasta en LOC individuales o entradas en su
paquete.jsonarchivo. - Por qué debe solucionar ciertas vulnerabilidades inmediatamente y por qué otras son menos prioritarias.
Aikido existe para hacer que la seguridad de las aplicaciones sea relevante y eficiente para los desarrolladores que necesitan aplicar rápidamente las correcciones de seguridad adecuadas y volver a publicar el código. Al igual que hacemos en nuestra plataforma de seguridad centrada en el desarrollador, vamos a reducir el ruido en torno a las vulnerabilidades comunes y centrarnos en tres detalles esenciales:
- El TL;DR, que le enseñará lo justo para tener miedo... y las palabras clave adecuadas para continuar su búsqueda educativa.
- Una respuesta concisa a la pregunta "¿Esto me afecta?" con un sí o un no claros (✅ o 🙅) y una breve explicación.
- Consejos rápidos en respuesta a "¿Cómo puedo solucionarlo?" que no implican herramientas caras ni refactorizaciones costosas.
#1: Inyección SQL && Inyección NoSQL
TL;DR: Esta vulnerabilidad clásica es posible gracias a la entrada de usuario no sanitizada y no validada, que permite a los atacantes ejecutar consultas directamente contra tu base de datos. A partir de ahí, pueden extraer datos, modificar registros o eliminarlos a voluntad, anulando por completo cualquier otra medida de seguridad de la aplicación que hayas implementado.
¿Me afecta?
- ✅ si su aplicación interactúa con una base de datos SQL o NoSQL en cualquier punto. Los ataques de inyección existen desde hace décadas, y los ataques automatizados empezarán inmediatamente a sondear tus endpoints con exploits comunes.
- 🙅 si no tienes contenido dinámico basado en registros de la base de datos. Esto podría deberse a que estás completamente del lado del cliente, usando un generador de sitios estáticos (SSG), o haciendo renderizado del lado del servidor con una base de datos pero nunca aceptando entradas de los usuarios.
¿Cómo solucionarlo? Lo primero y más importante es desinfectar y validar todas las entradas del usuario para eliminar caracteres o cadenas no deseados. Utiliza bibliotecas y marcos de trabajo de código abierto que permitan consultas parametrizadas, y nunca concatenes la entrada del usuario en una consulta a la base de datos. Si utilizas Node.js, considera nuestro motor de seguridad de código abierto Runtime, que te protege de forma autónoma de ataques de inyección SQL/NoSQL y mucho más.
#2: Secuencias de comandos en sitios cruzados (XSS)
TL;DR: XSS es otro ataque de inyección que permite a un atacante enviar un script malicioso a otro, recopilando potencialmente sus credenciales de autenticación o datos confidenciales.
¿Me afecta?
- ✅ si tu aplicación acepta entradas del usuario y las emite en otro lugar como contenido dinámico.
- 🙅 si no aceptas ninguna entrada del usuario.
¿Cómo lo arreglo? Al igual que con los ataques de inyección SQL/NoSQL, debe validar la entrada del usuario cuando incluya dicha entrada dentro del archivo href de las etiquetas de anclaje para garantizar que el protocolo no sea javascript. Tenga cuidado al utilizar métodos JavaScript como innerHTML o React dangerouslySetInnerHTMLque puede ejecutar arbitrariamente cualquier código incrustado en la cadena durante la salida. Independientemente de su enfoque, desinfecte la salida HTML con desinfectadores de código abierto como DOMPurificar para enviar sólo HTML limpio y no ejecutable a sus usuarios.
#3: Falsificación de peticiones del lado del servidor (SSRF)
TL;DR: Los ataques SSRF se producen cuando un actor malicioso abusa de tu aplicación para interactuar con su red subyacente, operándola como un proxy para saltar a servicios potencialmente más vulnerables o lucrativos.
¿Me afecta?
- ✅ si tu aplicación interactúa con otro servicio o API que realiza una operación específica con los datos del usuario, incluso si has utilizado listas de permisos para restringir el tráfico sólo entre puntos finales conocidos y de confianza.
- 🙅 si estás realmente estático.
¿Cómo solucionarlo? Aunque una regex para validar direcciones IP o nombres de host es un buen comienzo, suele ser propensa a derivaciones como la codificación octal. Dos soluciones más fiables son utilizar una lista de permitidos y el analizador de URL nativo de tu plataforma para restringir la entrada sólo a hosts seguros y conocidos, y deshabilitar las redirecciones en las peticiones de obtención. Dependiendo de tu framework, también puedes aprovechar libremente proyectos de código abierto -como ssrf-req-filter para Node.js- para rechazar adecuadamente cualquier petición a hosts internos.
#4: Recorrido
TL;DR: Este fallo de seguridad permite a los atacantes acceder a archivos y directorios de su servidor web mediante archivos de referencia utilizando ../ o incluso rutas absolutas. Utilizando tácticas astutas como la doble codificación, los atacantes pueden usar jerarquías de carpetas y archivos específicas del marco de trabajo o nombres de archivo comunes para encontrar información valiosa.
¿Me afecta?
- ✅. Tu aplicación se ejecuta en un servidor web e incluye referencias al sistema de archivos.
¿Cómo solucionarlo? El primer paso consiste en eliminar del directorio raíz del servidor todos los archivos confidenciales, como los que contienen variables de entorno o secretos, y establecer un proceso para evitar más errores.
Nunca almacene archivos sensibles, como los que contienen variables de entorno o secretos, en el directorio raíz de su servidor web. Tampoco los almacene en carpetas de acceso público, como la carpeta /estática y /público carpetas de un Proyecto Next.js. Por último, tira ../ separadores de ruta y sus variantes codificadas a partir de la entrada del usuario.
El tiempo de ejecución también funciona fantásticamente bien para atravesar caminos... por decir algo.
#5: Inyección de entidades externas XML (XXE)
TL;DR: Los ataques XXE aprovechan una debilidad en los analizadores XML que permite que entidades externas, referenciadas por una definición de tipo de documento (DTD), sean obtenidas y procesadas sin validación o limpieza. El tipo y la gravedad del ataque están limitados principalmente por las habilidades del atacante y cualquier seguridad/permisos a nivel de sistema operativo de su proveedor de infraestructura.
¿Me afecta?
- ✅ si analiza XML por cualquier motivo, incluidos los flujos de autenticación de inicio de sesión único mediante SAML.
- 🙅 ¡si no tienes que lidiar con XML en tu app!
¿Cómo solucionarlo? Desactive la resolución de DTD externos en su analizador XML. Es probable que no pueda rechazar por completo los DTD, ya que es normal que algunas cargas útiles XML los contengan, pero no permita que el analizador XML haga nada con ellos.
#6: Deserialización
TL;DR: Los atacantes pueden enviar datos maliciosos a través de una función de deserialización integrada en su aplicación (como deserializar() de node-serialize) para ejecutar código de forma remota, ejecutar una denegación de servicio o incluso crear una shell inversa.
¿Me afecta?
- ✅ si tu aplicación deserializa datos directamente de la interacción del usuario o a través de funciones/servicios en segundo plano como cookies, formularios HTML, API de terceros, almacenamiento en caché, etc.
- 🙅 si estás ejecutando una app totalmente estática sin nada de lo anterior.
¿Cómo puedo solucionarlo? En general, evite deserializar datos introducidos por el usuario (también conocidos como datos no fiables). Si tienes que hacerlo, solo acepta datos de usuarios autenticados y autorizados basados en firmas, certificados y proveedores de identidad de confianza.
#7: Inyección de Shell/inyección de comandos
TL;DR: Su aplicación pasa la entrada del usuario directamente al shell subyacente del sistema operativo en el que se ejecuta su servidor web y la aplicación, lo que permite a los atacantes ejecutar comandos arbitrarios o recorrer el sistema de archivos, a menudo con privilegios suficientes para extraer datos o pasar a otro sistema.
¿Me afecta?
- ✅ si su aplicación interactúa con el sistema de archivos o shell directamente, como un comando UNIX como
cat. - 🙅 si ya utilizas una API o método del framework para pasar argumentos de forma segura al comando que necesitas ejecutar, o no necesitas interactuar con el sistema de archivos/shell, como en un SSG.
¿Cómo lo arreglo? Evite aceptar la entrada del usuario directamente en los comandos o llamarlos directamente. En su lugar, utilice la API/método de su framework, como por ejemplo proceso_hijo.execFile() en Node.js, que te permite pasar argumentos en una lista de cadenas. Incluso con esa protección, ejecuta siempre tus aplicaciones con los mínimos privilegios necesarios para la lógica de negocio requerida, para evitar que un atacante "escape" del servidor web y acceda a raíz-sólo carpetas y archivos.
Y sí, volvemos con otro recordatorio amistoso para añadir Tiempo de ejecución a cualquier proyecto Node.js con un solo comando (npm add @aikidosec/runtime || yarn install @aikidosec/runtime) para proteger instantáneamente su aplicación contra ataques comunes de inyección de shell/comandos.
#8: Inclusión local de archivos (LFI)
TL;DR: Los ataques LFI consisten en engañar a tu aplicación para que exponga o ejecute archivos en el sistema que ejecuta tu servidor web, lo que permite a los atacantes extraer información o ejecutar código de forma remota. Mientras que el path traversal solo permite a los atacantes leer archivos, los ataques LFI ejecutan esos archivos dentro de tu aplicación, exponiéndote a una larga lista de vulnerabilidades de seguridad como la ejecución remota de código (RCE).
¿Me afecta?
- ✅ si tu aplicación utiliza la ruta a un archivo como entrada del usuario.
- 🙅 si tu aplicación no requiere que los usuarios proporcionen rutas para completar ninguna acción.
¿Cómo lo arreglo? Desinfecte siempre la entrada del usuario para evitar los métodos de exploración de rutas mencionados anteriormente. Si debe incluir archivos en el sistema de archivos local más allá de los que se encuentran típicamente en "seguro" /público o /estática utilice una lista de nombres de archivos y ubicaciones que su aplicación pueda leer y ejecutar.
#9: Prototipo de contaminación
TL;DR: Este Vulnerabilidad específica de JavaScript permite a un atacante manipular los objetos globales de tu aplicación utilizando __proto__. El nuevo objeto se hereda en toda la aplicación, lo que puede darles acceso a datos confidenciales o aumentar sus privilegios.
¿Me afecta?
- ✅ si utiliza JavaScript.
- 🙅 ¡si usas algo que no sea JavaScript!
¿Cómo lo arreglo? Comience por desinfectar las claves de entrada del usuario utilizando allowlists o una biblioteca de ayuda de código abierto. Puede ampliar su protección utilizando Objeto.congelar() para evitar cambios en un prototipo, o incluso utilizando la función --disable-proto=borrar que ofrece Node.js.
#10: Redirecciones abiertas
TL;DR: En este vector común de phishing, los atacantes crean una URL personalizada como https://www.example.com/abc/def?&success=true&redirectURL=https://example.phishing.com para engañar a su aplicación y redirigir a los usuarios desprevenidos a un sitio web malicioso. Además, los atacantes pueden encadenar redirecciones junto con otras vulnerabilidades para obtener un impacto aún mayor, lo que lleva a la toma de cuentas y más.
¿Me afecta?
- ✅ si tu app redirige a los usuarios a otra página/vista después de completar una acción, como enviarlos a
ejemplo.app/panel de controltras una autenticación correcta. - 🙅 si sigues viviendo esa vida generada por la estática.
¿Cómo solucionarlo? En primer lugar, elimina las redirecciones basadas en parámetros de tu aplicación y sustitúyelas por redirecciones fijas basadas en una lista de dominios y rutas de confianza a los que puedes redirigir a los usuarios después de que realicen acciones específicas. Esto puede degradar ligeramente la experiencia del usuario, pero es un compromiso significativo para mejorar la seguridad de la aplicación, no uno que les haga culparte de los extraños gastos en el extracto de su tarjeta de crédito.
¿Qué es lo próximo para la seguridad de su aplicación?
Si se siente abrumado por el alcance de los ataques y todo el trabajo necesario para protegerse contra ellos, sepa que no está solo.
Nadie espera que tú mismo resuelvas todos estos problemas de seguridad y posibles vulnerabilidades. Los ataques de inyección SQL existen desde hace décadas, y la gente sigue encontrando CVE en aplicaciones, frameworks y bibliotecas sofisticadas. Eso no quiere decir que debas tomarte estos problemas de seguridad a la ligera: si tu proyecto cumple los ✅ requisitos de cualquiera de estos 10 problemas de seguridad de aplicaciones, deberías empezar a tomar medidas.
En primer lugar, regístrate en Aikido para empezar a centrarte en las amenazas reales a la seguridad de tu aplicación. En dos minutos, y de forma gratuita, puedes escanear repositorios y obtener detalles relevantes además de correcciones guiadas para las vulnerabilidades más críticas basadas en la arquitectura específica de tu aplicación y qué características, funciones y bibliotecas de ayuda has implementado. Con Aikido, reducirá el alcance a lo que importa e implementará correcciones inteligentes más rápidamente, y será informado al instante de los nuevos problemas de seguridad introducidos en sus últimos commits.
A continuación, añada Runtime, nuestro motor de seguridad integrado de código abierto, a sus aplicaciones Node.js. Runtime protege de forma instantánea y autónoma sus aplicaciones contra varios ataques de inyección, contaminación de prototipos y path traversal bloqueándolos a nivel de servidor, pero sin el coste y la complejidad de los cortafuegos de aplicaciones web o las plataformas de gestión de seguridad de aplicaciones basadas en agentes. Runtime le da la confianza de que su aplicación y los usuarios están a salvo de estos problemas de seguridad comunes, pero también puede alimentar los datos en tiempo real de nuevo a Aikido para darle visibilidad a los vectores de ataque actuales para ayudarle a priorizar las correcciones.
Ahora empiezas con buen pie, con una idea más clara:
- Cómo su aplicación es vulnerable de más formas de las que podría haber pensado.
- Dónde debe centrar su tiempo y atención para solucionar primero los problemas más críticos.
- Por qué la seguridad de las aplicaciones y el análisis de vulnerabilidades no es un esfuerzo único, sino un proceso continuo, uno mucho más fácil con Aikido.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)