El Proyecto Abierto de Seguridad de Aplicaciones a Nivel Mundial (OWASP, por sus siglas en inglés) es una organización internacional que proporciona recomendaciones sobre seguridad de software.
OWASP desarrolla y mantiene varias herramientas, como documentación y videos, para concienciar a los desarrolladores y empresas sobre la seguridad de sus aplicaciones web.
Lo que os quiero mostrar de OWASP es el Top 10 de OWASP. El Top 10 de OWASP describe los ataques más extendidos que puede sufrir una aplicación web. Sin entrar en demasiados detalles.
- Autenticación y autorización débiles: Incluso con la autenticación implementada en tu aplicación, tu aplicación sigue siendo vulnerable. Lo más común es el ataque de fuerza bruta, que consiste en intentar combinaciones de usuario/contraseña cientos o miles de veces hasta que se encuentra la combinación correcta. Es muy fácil si la contraseña es fácil de adivinar. Una solución sencilla para protegerse contra este ataque es la autenticación de dos factores.
- Inyección: Particularmente con las bases de datos SQL (pero también NoSQL), existe una forma de obtener información al corromper los datos (que no han sido verificados, ya que un usuario nunca debe ser confiado), desviando así el propósito de la solicitud inicial al servidor. El más conocido es la inyección SQL. Otro tipo de ataque es el Cross-Site Scripting (XSS), que envía datos que contienen código ejecutable. Los datos pueden ser enviados a través de un endpoint que guarda los datos para ser mostrados más adelante. Estos datos pueden contener, por ejemplo, código JavaScript que puede inyectar algún contenido inesperado o, aún peor, robar cookies de autenticación y enviarlas a un destino que robará y utilizará tu identidad.
- Control de acceso roto: La autenticación a menudo es insuficiente para proteger el acceso a datos o acciones sensibles. En una empresa, no todos pueden tener los mismos privilegios en una aplicación, por eso es que a algunas personas, y no a todos los usuarios de la aplicación, se les otorga una autorización adicional para acceder a datos sensibles, como la información bancaria de un cliente.
- Registro y monitoreo insuficientes: El registro y monitoreo pueden ayudar a identificar ataques, como los ataques de fuerza bruta, o detectar un aumento en la actividad en una aplicación web cuando la actividad debería ser baja. Esto se soluciona con la observabilidad, la observabilidad no solo sirve para medir los límites de tu arquitectura o la salud de la misma.
- Integridad de datos insegura: La serialización/deserialización de datos puede llevar a violaciones de seguridad, como permitir a un atacante ejecutar código malicioso en el servidor. Por tanto es obligatorio validar los datos de entrada en los endpoints de tus API.
- Fallos criptográficos: La falta encriptación de ciertos datos puede llevar a vulnerabilidades en una aplicación, convirtiéndola en un objetivo para los hackers. Una forma habitual de solucionar estos problemas son a través de HTTPS.
- Un diseño de aplicación débil: Es un término de seguridad de la información que se refiere a la falta de medidas de seguridad robustas y efectivas en el diseño y la arquitectura de una aplicación. Este problema puede permitir a los atacantes explotar las debilidades en la aplicación para obtener acceso no autorizado, manipular datos o realizar otras actividades maliciosas. Por ejemplo, podría ser una aplicación que permite a los usuarios reutilizar códigos promocionales que deberían ser de un solo uso. Esto podría permitir a los usuarios abusar de la promoción, lo que resultaría en pérdidas para la empresa.
- Configuración de seguridad débil: Una aplicación puede ser vulnerable si, por ejemplo, utiliza cuentas cuyas contraseñas nunca caducan o, peor aún, si las contraseñas son fáciles de adivinar o si un par de login/contraseña no utilizado permanece activo.
- SSRF: Las vulnerabilidades de falsificación de solicitudes del lado del servidor (SSRF) ocurren siempre que una aplicación web recupera un recurso remoto sin validar la URL proporcionada por el usuario, permitiendo a un atacante forzar a la aplicación a enviar una solicitud especialmente diseñada a un destino inapropiado.
- Componente obsoleto: Muchas aplicaciones a menudo no actualizan sus frameworks o bibliotecas. Por ejemplo, Microsoft publica actualizaciones para los frameworks de .NET para cerrar una brecha de seguridad. Aparte de decirte que siempre debes mantener tu aplicación actualizada, no tengo nada más que decir sobre este tema (leer por ejemplo mi anterior artículo sobre MOQ).
Uno de los temas más desconocidos, por mi años de esperiencia en desarrollo de aplicaciones WEB es el gran desconocimiento de los HEADERS. Por ejemplo, OWASP proporciona el proyecto de encabezados seguros de OWASP (OSHP). Este proyecto describe los encabezados de respuesta HTTP que se pueden agregar a tu aplicación para hacerla más segura. Aquí tienes más información: https://owasp.org/www-project-secure-headers/. Por suerte existe un Nuget dedicado a este punto: www.nuget.org/packages/OwaspHeaders.Core
Reflexión
He escrito este artículo de seguridad OWASP y .NET como una reflexión y respuesta a una necesidad crucial en el campo del desarrollo de software. Durante una reunión reciente, un CSO preguntó: «¿Dónde está la parte de seguridad?», y me di cuenta de que, a pesar de ser un aspecto inherente al desarrollo y a la infraestructura de cualquier sistema, la seguridad a menudo se pasa por alto o se minimiza.
En mi experiencia, he observado una falta de conocimiento sobre seguridad en muchos arquitectos y desarrolladores. Esta laguna de conocimiento puede conducir a la creación de sistemas y aplicaciones que son vulnerables a ataques y violaciones de seguridad, lo que puede tener consecuencias graves tanto para las organizaciones como para los usuarios.
Por lo tanto, veo la necesidad de educar y crear conciencia sobre la importancia de la seguridad en todas las etapas del desarrollo de software. A través de este artículo, espero proporcionar una guía sobre el Top 10 de vulnerabilidades de seguridad en ASP.NET, con el objetivo de ayudar a los desarrolladores y arquitectos a investigar soluciones a las vulnerabilidades para construir sistemas más seguros.
En última instancia, creo que la seguridad no es algo que se pueda añadir después, sino que debe ser una consideración esencial desde el principio del proceso de desarrollo. Al integrar la seguridad desde el principio, podemos construir sistemas que no sólo son funcionales y eficientes, sino también seguros y resistentes.
