Los 10 acrónimos de seguridad de aplicaciones más comunes
Explicación de los acrónimos más comunes de AppSec
Escrito por
0 minutos de lectura
Guía rápida
Explicación de las 10 principales siglas de seguridad de aplicaciones
Imagina 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 de seguridad de aplicaciones y da por sentado que conoces su significado, pero en realidad no son términos que te resulten familiares. ¿Te suena? Por desgracia, esto parece ocurrir con frecuencia en muchas organizaciones DevSecOps. De hecho, en Snyk caímos en esta trampa con nuestro reciente anuncio de las capacidades SAST de Snyk. Recibimos muchos comentarios en redes sociales de personas que no sabían qué era SAST. Por eso, 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.
1. SAST: pruebas estáticas de seguridad de aplicaciones
Las pruebas estáticas de seguridad de aplicaciones, o SAST, consisten en analizar el código fuente de una aplicación, servicio, microservicio, etc., para identificar posibles vulnerabilidades de seguridad que surgen de 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 inseguras u objetos inseguros que podrían provocar vulnerabilidades de seguridad. SAST se usa principalmente para identificar vulnerabilidades en código recién desarrollado. Normalmente, se lleva a cabo 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 puede identificar vulnerabilidades en las primeras etapas del proceso de desarrollo y encontrar vulnerabilidades ocultas que podrían pasar desapercibidas si solo se observa la funcionalidad de la aplicación. Las herramientas automatizadas de SAST pueden analizar grandes cantidades de código con 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, no representan un riesgo real. Ajustar algunas herramientas y eliminar estos problemas puede tomar bastante tiempo. Aun así, estas herramientas son fundamentales para tu postura de seguridad.
Comienza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.
2. DAST: pruebas dinámicas de seguridad de aplicaciones
Las pruebas dinámicas de seguridad de aplicaciones, o DAST, consisten en analizar una aplicación o un servicio en ejecución para encontrar vulnerabilidades de seguridad. DAST busca imitar los tipos de ataques que un usuario malicioso podría realizar contra la aplicación a través de la interfaz de usuario o de la aplicación. Una ventaja de este enfoque es que puede identificar vulnerabilidades complejas que surgen de funcionalidades específicas de la aplicación y que podrían pasar desapercibidas al analizar solo el código fuente.
En DAST, se analiza la interfaz para detectar distintos indicios de vulnerabilidades, observando cómo responde la aplicación a diferentes solicitudes y entradas (a menudo llamadas cargas útiles). Se revisa todo, desde los campos de entrada de usuario hasta los encabezados HTTP, para determinar si se implementaron correctamente el manejo de datos y las medidas de seguridad necesarias para evitar que los atacantes manipulen la aplicación o el servicio.
Para realizar DAST se pueden usar herramientas automatizadas, semiautomatizadas y manuales. Las herramientas DAST totalmente automatizadas suelen poder mapear las distintas páginas de una aplicación y probarlas en busca de una amplia 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 se centran en analizar en profundidad uno o algunos tipos específicos de vulnerabilidades. Por lo general, 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, lee nuestro artículo SAST vs. 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 incluye el análisis de esas dependencias externas para detectar vulnerabilidades de seguridad conocidas y posibles problemas de licencias. Las herramientas automatizadas de SCA, como Snyk Open Source, suelen poder mapear todo el árbol de dependencias: no solo revisan qué componentes se incluyen en el código fuente de la aplicación, sino que también analizan las dependencias de cada uno de esos componentes, y así sucesivamente.
El análisis de composición de software se puede ejecutar en cualquier etapa del pipeline de entrega, pero suele ser preferible hacerlo cuanto antes, a menudo durante la fase de programación, para poder resolver rápidamente los problemas que surjan. Una de las razones principales para usar SCA es identificar posibles fallas de seguridad introducidas por componentes de terceros durante el desarrollo de una aplicación y, además, garantizar que, cuando se descubran nuevas vulnerabilidades en software de terceros o de código abierto, la organización pueda determinar rápidamente si se ve afectada por ellas y planificar su corrección.
Lee más sobre SAST vs. SCA y cómo aprovecharlos para lanzar software seguro.
Empieza con los desafíos de Capture the Flag
Aprende a resolver desafíos de captura la bandera con nuestro taller virtual introductorio a pedido.
4. OWASP: Proyecto Abierto de Seguridad de Aplicaciones Web
El Proyecto Abierto de Seguridad de Aplicaciones Web, 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 reúne a una amplia comunidad de voluntarios que proponen, desarrollan y administran estos proyectos y materiales educativos para beneficio de toda la comunidad de seguridad y desarrollo de software.
Uno de los proyectos más conocidos es el OWASP Top 10, una lista de los diez tipos más comunes de vulnerabilidades de aplicaciones web que se actualiza periódicamente con aportes de la comunidad. Al realizar SAST o DAST, quizá escuches hablar del OWASP Top 10 como guía sobre los tipos de vulnerabilidades que los evaluadores podrían buscar. 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 con el fin de analizar y perfeccionar distintos aspectos de los proyectos.
5. XSS: scripting entre sitios
El scripting entre sitios, o XSS, es un tipo de vulnerabilidad de seguridad que se detecta comúnmente en aplicaciones web. Se incluye en el OWASP Top 10 desde que se publicó su primera versión en 2003. XSS es un tipo de ataque a aplicaciones que puede permitir que un atacante ejecute código de script malicioso (por lo general, JavaScript) en el navegador de una persona o de muchas personas. Este tipo de explotación se puede usar para recopilar información confidencial, como datos de sesiones de usuario o datos personales.
Por lo general, se habla de tres tipos de XSS:
Reflejado: el atacante hace que la persona usuaria envíe a la aplicación una solicitud que contiene la carga útil del ataque. La aplicación la incluye en la respuesta y, como resultado, el código se ejecuta en el navegador.
Almacenado: el atacante envía la carga útil del ataque a la aplicación, donde se almacena en un valor que se devuelve a otras personas como parte de páginas creadas dinámicamente. Esto hace que el script se ejecute en sus navegadores.
Basado en DOM: el atacante envía el script malicioso a la persona usuaria (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.
En nuestra página sobre XSS de Snyk Learn encontrarás más información sobre XSS y cómo prevenirlo.
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 ya autenticada entre el navegador de la persona usuaria y la aplicación para ejecutar funciones de esa aplicación mediante solicitudes incrustadas en un sitio web malicioso que controla. A veces, CSRF también se conoce como secuestro de sesión, y algunas personas prefieren pronunciarlo «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 esta tiene una sesión autenticada activa en la 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 visitara el sitio enviara la solicitud a la aplicación bancaria. De esta manera, si la persona visitante tiene una sesión activa (quizá en otra pestaña del navegador) en esa aplicación bancaria, la solicitud se enviaría dentro de esa sesión. Para atraer visitantes al sitio, probablemente el atacante usaría una campaña de phishing dirigida, con la que intentaría engañar a posibles clientes del banco (y, por lo tanto, posibles usuarios de la aplicación bancaria) para que visitaran 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 sobre 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 reaccionar de inmediato. RASP suele implementarse mediante herramientas de terceros. Estas herramientas normalmente se integran en la aplicación y supervisan no solo las solicitudes entrantes, sino también el comportamiento de la aplicación para detectar y prevenir ataques. Esto se puede hacer mediante paquetes, bibliotecas o complementos que funcionan casi como un filtro delante de la aplicación para inspeccionar las solicitudes y el comportamiento de la aplicación. La principal ventaja de RASP es que garantiza que, aunque existan vulnerabilidades en la aplicación, un atacante no pueda explotarlas con éxito (o que, al menos, se limite 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 la 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 extrema 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 aprovecha una falla en el código, el software del sistema o la infraestructura de red de una aplicación para impedir que otras personas accedan a ella. 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 vulnerabilidad específica que se encuentra comúnmente en aplicaciones JavaScript del lado del servidor, donde un atacante puede hacer que el motor de expresiones regulares consuma grandes cantidades de recursos y deje la aplicación sin respuesta.
9. CSP: política de seguridad de contenido
La política de seguridad de contenido, o 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 indicarle 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 inyectados 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, o 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 permitir que el atacante acceda 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, la seguridad tiene 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 fomentar una mejor colaboración en el proceso de entrega de DevSecOps.