Utilizar un ciclo de vida de desarrollo seguro
Objetivos de aprendizaje
Después de completar esta unidad, podrá:
- Explicar la importancia de asegurar el ciclo de vida de desarrollo.
- Enumerar ataques prominentes (inyección, XSS) que se aprovechan de la falta de depuración y validación.
Proteger el ciclo de vida de desarrollo de software
- Planificar qué requisitos y casos de uso abordará una aplicación.
- Diseñar la aplicación.
- Implementar la aplicación mediante codificación.
- Probar que la aplicación funciona correctamente.
- Implementar la aplicación para el cliente.
- Realizar el mantenimiento de la aplicación.
La lista anterior denota los seis pasos de un ciclo de vida de desarrollo de software (SDLC) típico. Si ha trabajado antes en un equipo de desarrollo de aplicaciones, probablemente esté familiarizado con cada fase de este ciclo. Pero lo que quizá no sepa es dónde encaja el papel de un ingeniero de seguridad de aplicaciones. ¿El ingeniero comprueba principalmente la seguridad de la aplicación antes de que se implemente para el cliente? ¿Se centra en mantener la seguridad de la aplicación mediante la corrección de vulnerabilidades críticas? ¿O sugiere que se incorporen funciones de seguridad en el diseño?
La respuesta es que un ingeniero de seguridad de aplicaciones desempeña un papel fundamental en cada paso del SDLC. Dado que los problemas de seguridad se pueden introducir o descubrir en cualquier fase del ciclo de vida de una aplicación, el ingeniero de seguridad de aplicaciones tiene una función continua que desempeñar para proteger la confidencialidad, integridad y disponibilidad de los datos de la aplicación. A menudo se piensa en la seguridad como un problema del eslabón más débil. Del mismo modo que una cadena de metal sólida se puede romper si un eslabón se ve comprometido, cada fase del SDLC debe estar protegida para asegurar el desarrollo, la implementación y el mantenimiento de la aplicación en su conjunto.
Por ejemplo, durante la fase de implementación del SDLC, se pueden introducir vulnerabilidades en el código si los desarrolladores no ponen en marcha comprobaciones que depuren y validen las entradas. Esto podría permitir a un atacante introducir en la aplicación entradas que le permitan acceder indebidamente a los datos de otro usuario o a una función administrativa.
Además, los equipos de desarrollo suelen utilizar código fuente abierto para desarrollar aplicaciones. El código fuente abierto es desarrollado en colaboración por muchas personas que trabajan juntas en Internet. Aunque este código puede ser más seguro debido al gran número de desarrolladores que trabajan juntos para desarrollarlo y revisarlo, a veces también puede contener vulnerabilidades. Los equipos de desarrollo deben ser conscientes de ello y comprobar estas bibliotecas de código para asegurarse de que no utilizan componentes con vulnerabilidades conocidas.
En el mundo del desarrollo ágil, en el que los equipos de desarrollo de aplicaciones lanzan continuamente nuevos servicios y funciones con plazos más ajustados, la atención a la depuración y al control de cambios puede quedar a menudo relegada a un segundo plano.
Los ingenieros de seguridad de aplicaciones trabajan con los equipos de desarrollo en todas las fases del SDLC. Actúan como defensores, consultores y expertos en la materia para garantizar que las aplicaciones se diseñan de forma segura, que el código se implementa con validaciones de seguridad y que no se introducen vulnerabilidades durante la transición del desarrollo al control de calidad y a la producción.
Protección contra la inyección y la secuencia de comandos de sitio cruzada (XSS)
Asegurar el SDLC es especialmente importante para la protección contra dos riesgos prominentes y fácilmente explotables para la seguridad de las aplicaciones: la inyección y la secuencia de comandos de sitios cruzada (XSS). Piense en la funcionalidad de una aplicación. Una de las características más importantes de casi todas las aplicaciones es la capacidad de almacenar y recuperar datos de un almacén de datos (como una base de datos). Los desarrolladores utilizan lenguajes de codificación para indicar a la aplicación cómo interactuar con la base de datos en función de las entradas del usuario. Por ejemplo, cuando un usuario inicia sesión en una aplicación, introduce su nombre de usuario y contraseña. Al pulsar Intro, lanza una consulta a la base de datos y, si la consulta tiene éxito, el usuario puede acceder al sistema.
Desafortunadamente, cada interacción que un usuario legítimo tiene con una aplicación también puede ser explotada por un atacante con fines maliciosos. Un fallo de inyección se produce cuando un atacante envía datos no fiables como parte de un comando o consulta. Si los desarrolladores no validan o depuran correctamente las entradas, un atacante podría ejecutar comandos no deseados o acceder a datos sin la debida autorización. Esto puede provocar la pérdida, corrupción o divulgación de datos.
¡Esto suena bastante aterrador! Pero los ingenieros de seguridad de aplicaciones tienen la impresionante tarea de garantizar que este tipo de cosas no ocurran. Utilizan diversas herramientas y técnicas para ayudar al equipo de desarrollo a proteger la aplicación y los datos de sus clientes de este tipo de ataques.
- Revisión del código fuente: Un proceso principalmente manual en el que el ingeniero de seguridad de la aplicación lee parte del código fuente para comprobar la correcta validación y depuración de los datos.
- Prueba estática: Un método de prueba de software que examina el código del programa pero no requiere que el programa se ejecute mientras lo hace. Por ejemplo, el análisis estático del código puede comprobar el flujo de datos de una entrada de usuario no fiable en una aplicación web y comprobar si los datos se ejecutan como un comando (que es un resultado no deseado).
- Prueba dinámica: Método de prueba de software que examina el código del programa mientras este se ejecuta.
- Prueba de automatización: Utiliza scripts de prueba para evaluar el software mediante la comparación del resultado real del código con su resultado esperado.
- Separación de comandos y consultas: Mantiene los datos separados de los comandos y las consultas. La idea es que cada método debe ser o bien un comando que realiza una acción o bien una consulta que devuelve datos a quien lo llama, pero nunca ambas cosas. Una consulta nunca debe cambiar el estado de una aplicación o sus datos y un comando puede cambiar el estado, pero nunca debe devolver un valor. Esto impide que un atacante suministre comandos del sistema operativo a través de una interfaz web para ejecutarlos y cargar programas maliciosos u obtener contraseñas.
- Listas permitidas: Implementar listas de caracteres o comandos permitidos puede validar la entrada del usuario y garantizar que los datos de URL y formularios no puedan ejecutar comandos que utilicen estos caracteres o ejecutar comandos no permitidos. Por ejemplo, una lista de elementos permitidos puede escapar o filtrar caracteres especiales como ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , `
- Y mucho más: Enumeración de vulnerabilidades comunes de Mitre (CWE) proporciona un buen recurso sobre otras consideraciones a la hora de protegerse contra la inyección de comandos.
Además de la inyección, otro riesgo de no proteger el SDLC mediante la validación y la depuración de los datos, y la comprobación y revisión del código es que la aplicación puede ser vulnerable a secuencias de comandos de sitio cruzadas (XSS). La XSS se produce cuando una aplicación incluye datos no fiables en una nueva página web sin la validación adecuada.
La imagen ilustra el flujo de cómo se produce la XSS. En primer lugar, un atacante inyecta código malicioso en una página web de confianza para enviarlo a un usuario desprevenido. En segundo lugar, la página web guarda el script malicioso en una base de datos. A continuación, la víctima visita el sitio web y solicita datos al servidor con la idea de que son seguros. Entonces, los datos que contienen el script malicioso vuelven a pasar por el servidor de la página web y llegan al equipo del usuario, y se ejecutan. Por último, devuelve la llamada al atacante, lo que compromete la información del usuario, todo ello mientras el usuario cree que está participando en una sesión en línea segura con un sitio web de confianza.
Mediante la ejecución de scripts maliciosos en el navegador de una víctima que utiliza XSS, un actor malicioso puede apropiarse de la sesión de un usuario, desfigurar un sitio web o redirigir al usuario a un sitio malicioso donde se le puede pedir que descargue malware o que introduzca sus credenciales para que el atacante las robe. El resultado puede ser que el equipo de la víctima se infecte con malware, que le roben información confidencial o que sus equipos pasen a formar parte de redes de bots que los atacantes pueden utilizar para ejecutar ataques distribuidos de denegación de servicio que inundan de tráfico la red de una organización, limitando el acceso de los usuarios legítimos.
Los ingenieros de seguridad de aplicaciones se deben preocupar por la XSS porque es un vector de ataque fácilmente explotable y es una debilidad de seguridad generalizada que los hackers pueden aprovechar con herramientas automatizadas y de libre acceso.
Según una estimación, la vulnerabilidad a las XSS se encuentra en dos tercios de todas las aplicaciones. Aunque esto suena aterrador, también significa que los ingenieros de seguridad de aplicaciones tienen una función emocionante e importante que desempeñar en la protección del SDLC. Al hacerlo, los ingenieros se aseguran de que la aplicación valida la entrada del usuario y no almacena entradas sin depurar que posteriormente otro usuario o administrador puedan ver. Para ello, separan los datos no fiables del contenido activo del navegador, utilizan marcos de codificación que evitan automáticamente las XSS por diseño y aplican una codificación confidencial al contexto.
Resumen
Se han presentado varias consideraciones importantes para ayudar a proteger las aplicaciones y sus datos a lo largo del SDLC. Ahora es el momento de aprender más sobre otra consideración clave para un ingeniero de seguridad de aplicaciones: configurar adecuadamente los componentes de la aplicación.