Guía rápida: los 10 acrónimos más comunes de seguridad de aplicaciones
1 de diciembre de 2020
0 minutos de lecturaImagina esta situación: eres desarrollador y estás en una reunión donde un profesional de seguridad analiza los resultados de una prueba de penetración reciente o de un análisis estático del código que escribiste.
Durante la conversación, usa varios acrónimos dando por hecho que sabes qué significan, pero en realidad no son términos que conozcas. ¿Te resulta familiar? Por desgracia, parece ser algo común en muchas organizaciones de DevSecOps. De hecho, en Snyk caímos en esta trampa cuando anunciamos recientemente las capacidades de SAST en Snyk. Recibimos muchos comentarios en redes sociales de personas que no sabían qué era SAST. Así que pensamos que sería buena idea preparar una guía rápida con los 10 acrónimos de seguridad más comunes. Y no te preocupes: incluimos SAST, así que sigue leyendo para descubrir de qué se trata.
DAST: pruebas de seguridad de aplicaciones dinámicas
SCA: análisis de composición de software
OWASP: Open Web Application Security Project
XSS: secuencias de comandos entre sitios
CSRF: falsificación de solicitudes entre sitios
RASP: autoprotección de aplicaciones en tiempo de ejecución
DoS: denegación de servicio
CSP: política de seguridad de contenido
SSRF: falsificación de solicitudes del lado del servidor
1. SAST: pruebas de seguridad de aplicaciones estáticas
Las pruebas de seguridad de aplicaciones estáticas, o SAST, consisten en analizar el código fuente de una aplicación, un servicio, un microservicio, etc., para identificar posibles vulnerabilidades de seguridad causadas por prácticas de programación inseguras. Por lo general, SAST se implementa con herramientas automatizadas que buscan en el código fuente patrones de programación, funciones u objetos inseguros que podrían provocar vulnerabilidades. Se usa principalmente para identificar vulnerabilidades en código recién desarrollado. Normalmente se realiza durante la fase de programación o cuando el código se promueve a un entorno de prueba.
Una de las principales ventajas de SAST es que permite identificar vulnerabilidades temprano en el proceso de desarrollo y encontrar vulnerabilidades ocultas que podrían pasar desapercibidas al observar únicamente la funcionalidad de la aplicación. Las herramientas automatizadas de SAST pueden analizar grandes cantidades de código con mucha rapidez. Sin embargo, por eso también pueden generar muchos resultados, a menudo con falsos positivos o vulnerabilidades que, en el contexto de la aplicación, en realidad no representan ningún riesgo. Con algunas herramientas puede llevar bastante tiempo ajustarlas y eliminar estos problemas. Aun así, estas herramientas son fundamentales para tu postura de seguridad.
2. DAST: pruebas de seguridad de aplicaciones dinámicas
Las pruebas de seguridad de aplicaciones dinámicas, o DAST, consisten en analizar una aplicación o un servicio en ejecución para detectar vulnerabilidades de seguridad. DAST busca imitar los tipos de ataques que una persona malintencionada podría llevar a cabo contra la aplicación mediante la interfaz de usuario o de la aplicación. La ventaja de este enfoque es que permite identificar vulnerabilidades complejas que se originan en funciones específicas de la aplicación y que podrían pasar desapercibidas al analizar únicamente el código fuente.
En DAST, se analiza la interfaz para detectar distintos indicios de vulnerabilidades, mediante la inspección de cómo responde la aplicación a diferentes solicitudes y entradas (a menudo llamadas cargas útiles). Se revisa todo, desde los campos de entrada del usuario hasta los encabezados HTTP, para determinar si se implementaron correctamente las medidas de seguridad y el manejo de datos necesarios para evitar que los atacantes manipulen la aplicación o el servicio.
Para realizar DAST se pueden usar herramientas automatizadas, semiautomatizadas y manuales. Por lo general, las herramientas de DAST totalmente automatizadas pueden recorrer las distintas páginas de una aplicación y probarlas en busca de una gran variedad de posibles vulnerabilidades de seguridad mediante distintas variantes de cargas útiles. Estas herramientas también suelen poder probar servicios web y microservicios. Otras herramientas de DAST tienen un enfoque más especializado y analizan en mayor profundidad uno o varios tipos específicos de vulnerabilidades. Normalmente, DAST se realiza en las últimas fases de prueba, justo antes de implementar una aplicación o un servicio en un entorno de producción.
Para conocer más sobre la diferencia entre SAST y DAST, visita nuestra página de Snyk Learn sobre SAST y DAST.
3. SCA: análisis de composición de software
El análisis de composición de software, o SCA, consiste en analizar una aplicación para identificar los componentes de software de terceros o de código abierto que incluye. Por lo general, SCA analiza esas dependencias externas en busca de vulnerabilidades de seguridad conocidas y posibles problemas de licencias. Las herramientas automatizadas de SCA, como Snyk OpenSource, suelen poder trazar todo el árbol de dependencias: no solo revisan los componentes incluidos en el código fuente de la aplicación, sino también las dependencias de cada uno de ellos, y así sucesivamente.
El análisis de composición de software puede ejecutarse en cualquier etapa del pipeline de entrega, pero suele ser preferible hacerlo antes, a menudo durante la fase de programación, para poder resolver rápidamente cualquier problema que surja. Una de las principales razones para usar SCA es identificar posibles fallas de seguridad introducidas por componentes de terceros durante el desarrollo de una aplicación. También permite que, cuando se descubren nuevas vulnerabilidades en software de terceros o de código abierto, la organización evalúe rápidamente si está afectada y planifique una solución.
4. OWASP: Open Web Application Security Project
Open Web Application Security Project, u OWASP, es una organización sin fines de lucro enfocada en la seguridad del software. OWASP es conocida por sus numerosos proyectos impulsados por la comunidad, cuyo objetivo es ofrecer educación y orientación para crear software más seguro. OWASP fomenta una amplia comunidad de voluntarios que proponen, desarrollan y administran estos proyectos y materiales educativos en beneficio de las comunidades de seguridad y desarrollo de software.
Uno de sus proyectos más conocidos es OWASP Top 10, una lista de los diez tipos más comunes de vulnerabilidades en aplicaciones web, que se actualiza periódicamente con aportes de la comunidad. Al realizar SAST o DAST, quizá escuches hablar de OWASP Top 10 como guía de los tipos de vulnerabilidades que se buscan en las pruebas. Aunque no es una clasificación exhaustiva de todos los tipos de vulnerabilidades posibles, es un buen punto de partida.
OWASP también organiza distintas conferencias de seguridad en todo el mundo y cuenta con capítulos locales que se reúnen periódicamente para compartir ideas, trabajar en proyectos y difundir conocimientos. En ocasiones, los proyectos individuales también organizan cumbres para reunir a profesionales y miembros del proyecto, debatir y perfeccionar distintos aspectos de los proyectos.
5. XSS: secuencias de comandos entre sitios
Las secuencias de comandos entre sitios, o XSS, son un tipo de vulnerabilidad de seguridad que se detecta comúnmente en las aplicaciones web. Forman parte de OWASP Top 10 desde que se publicó su primera versión en 2003. XSS es un tipo de ataque a aplicaciones que permite a un atacante ejecutar código de scripts maliciosos (por lo general, JavaScript) en el navegador de una persona o de muchas. Este tipo de explotación puede usarse para obtener información confidencial, como datos de sesiones de usuario o información personal.
Por lo general, se habla de tres tipos de XSS:
Reflejado: el atacante hace que el usuario envíe a la aplicación una solicitud que contiene la carga útil del ataque. La aplicación la incluye en la respuesta, lo que hace que se ejecute en el navegador.
Almacenado: el atacante envía la carga útil del ataque a la aplicación, donde se guarda en un valor que se muestra a otros usuarios como parte de páginas generadas dinámicamente, lo que hace que el script se ejecute en sus navegadores.
Basado en el DOM: el atacante envía el script malicioso al usuario (por lo general, en un enlace malicioso) y este se ejecuta directamente en el DOM de la página, sin pasar por la aplicación.
Encontrarás más información sobre XSS y cómo prevenirlo en nuestra página de XSS en Snyk Learn.
6. CSRF: falsificación de solicitudes entre sitios
La falsificación de solicitudes entre sitios, o CSRF, es otro tipo común de ataque a aplicaciones web. En un ataque CSRF, el atacante aprovecha una sesión autenticada existente entre el navegador del usuario y la aplicación para ejecutar funciones de esa aplicación mediante solicitudes insertadas en un sitio web malicioso bajo su control. A veces, CSRF también se conoce como secuestro de sesión, y algunas personas prefieren pronunciarlo como «C-Surf».
La falsificación de solicitudes entre sitios suele explotarse tomando una solicitud válida dirigida a la aplicación objetivo y haciendo que se vuelva a enviar desde el navegador de la víctima mientras tiene una sesión autenticada activa con esa aplicación. Por ejemplo, el atacante podría capturar una solicitud de una aplicación de banca en línea que realiza una transferencia bancaria. Luego crearía un sitio malicioso y alojaría esa misma solicitud en un IFRAME, para que cualquier persona que visite el sitio la envíe a la aplicación bancaria. De esta manera, si la persona tiene una sesión activa con esa aplicación bancaria (quizá en otra pestaña del navegador), la solicitud se enviaría usando esa sesión. Para atraer visitantes al sitio, es probable que el atacante use una campaña de phishing dirigida para engañar a posibles clientes del banco (y, por lo tanto, posibles usuarios de la aplicación bancaria) y lograr que visiten el sitio malicioso.
Para obtener más información sobre la falsificación de solicitudes entre sitios y cómo prevenirla, consulta nuestra página de CSRF en Snyk Learn
7. RASP: autoprotección de aplicaciones en tiempo de ejecución
La autoprotección de aplicaciones en tiempo de ejecución, o RASP, es una técnica defensiva integrada en una aplicación que le permite detectar ataques y responder de inmediato. Por lo general, RASP se implementa mediante herramientas de terceros. Las herramientas de RASP suelen integrarse en la aplicación y monitorear no solo las solicitudes entrantes, sino también el comportamiento de la aplicación, para detectar y prevenir ataques. Esto puede hacerse mediante paquetes, bibliotecas o complementos que funcionan casi como un filtro en la entrada de la aplicación, capaz de inspeccionar las solicitudes y el comportamiento de la aplicación. La principal ventaja de RASP es que garantiza que, incluso si hay vulnerabilidades en la aplicación, un atacante no pueda explotarlas con éxito (o, al menos, limita considerablemente el alcance de la explotación).
8. DoS: denegación de servicio
La denegación de servicio, o DoS, es un tipo de explotación en el que un atacante busca limitar o impedir la disponibilidad de una aplicación o un servicio. Esto suele hacerse provocando que la aplicación, el servicio o el sistema deje de responder o responda con mucha lentitud. También se puede lograr atacando la infraestructura de red que permite la comunicación con la aplicación. Los ataques DoS ocurren cuando un atacante explota una falla en el código, el software del sistema o la infraestructura de red de una aplicación para que deje de estar disponible para otras personas. Hay muchas formas de llevar a cabo un ataque DoS, pero suelen mencionarse dos tipos específicos:
DDoS: la denegación de servicio distribuida ocurre cuando un atacante usa una gran cantidad de sistemas (por lo general, parte de una botnet) para saturar un objetivo con tráfico y dejarlo fuera de servicio.
REDoS: la denegación de servicio mediante expresiones regulares es una falla específica que se encuentra comúnmente en aplicaciones JavaScript del lado del servidor. Un atacante puede hacer que el motor de expresiones regulares consuma muchos recursos y deje la aplicación sin responder.
9. CSP: política de seguridad de contenido
La política de seguridad de contenido (CSP) es una medida de protección para aplicaciones web diseñada para prevenir ataques XSS. Permite que los desarrolladores de aplicaciones usen un encabezado HTTP para indicar al navegador que solo cargue y ejecute scripts de fuentes específicas. Al impedir que se carguen scripts de fuentes no previstas, los desarrolladores pueden evitar que se ejecuten en el navegador los scripts proporcionados mediante un ataque XSS.
Encuentra más recursos e información sobre CSP en nuestro blog.
10. SSRF: falsificación de solicitudes del lado del servidor
La falsificación de solicitudes del lado del servidor (SSRF) es un tipo de ataque a aplicaciones en el que un atacante puede hacer que la aplicación de frontend envíe solicitudes a ubicaciones arbitrarias (como otros servidores internos, servidores externos o incluso a sí misma). Esto puede darle acceso a datos o funciones no autorizados.
Para obtener más información sobre SSRF, te recomendamos esta guía de OWASP.
En resumen
Como en cualquier industria, en seguridad se usan muchos términos técnicos que suelen abreviarse para facilitar la conversación. Esto puede resultar confuso para quienes no trabajan en seguridad. Para los desarrolladores, entender los términos que usan sus socios de seguridad puede ser una herramienta poderosa para mejorar la colaboración en el flujo de entrega de DevSecOps.
¡Descarga ahora la guía de los 10 principales acrónimos de seguridad de aplicaciones!
