Vuelta a los Origenes: Seguridad con ASP.NET

Parejo a las decisiones que han de tomarse en cuenta cuando se diseña e implementa una arquitectura de la solución,
necesitamos pensar en la seguridad. ¿Por qué es necesario? Porqué crear una solución de software robusta e innovadora requiere planificar varios aspectos y considerar diferentes atributos para equilibrar a corto plazo y objetivos y prioridades a largo plazo. El siguiente documento es una guia para que tengas lo esencial y puedas trabajar con cierta seguridad. Nunca estamos a salvo de los malos.

Transcript

1. VUELTA A LOS ORIGINES: DESARROLLO SEGURO EN ASP.NET
2. Bienvenidos Acerca de… ¡Hola! Gracias por entrar en “Vuelta a los orígenes: desarrollo seguro con ASP.NET”. Espero poder aportarte los conocimientos mínimos y necesarios con este curso para que puedas ponerlo en práctica. Jose María Flores Zazo, autor
3. Crear una solución robusta (1/2) Introducción Parejo a las decisiones que han de tomarse en cuenta cuando se diseña e implementa una arquitectura de la solución, necesitamos pensar en la seguridad. ¿Por qué es necesario? Porqué crear una solución de software robusta e innovadora requiere planificar varios aspectos y considerar diferentes atributos para equilibrar a corto plazo y objetivos y prioridades a largo plazo. Prestando atención a la calidad de los atributos, el registro y el seguimiento, junto con la estrategia de implementación adecuada, nos ayudará a entregar un producto de buena calidad que sea escalable, fácil de manejar y seguro. Como arquitecto de software siempre es emocionante diseñar y construir soluciones sofisticadas; sin embargo, esto puede ser un fiasco si no presentamos atención a los riesgos de seguridad implicados. La seguridad es una parte integral de cualquier solución de software, especialmente las aplicaciones WEB y concretamente las de ASP.NET, en la que nos vamos a basar. Por naturaleza, las aplicaciones web, están expuestas a una gran cantidad de usuarios, por lo que que la seguridad no es un lujo y no debe implementarse de forma tardía, es una necesidad desde el principio, cosa que muchos clientes no entienden. No es para después – Pensar en seguridad es intrínseco
4. Crear una solución robusta (2/2) Introducción El framework .NET Core nos proporciona una serie de características y funcionalidades para asegurar nuestra aplicación si las implementamos y configuramos de forma correcta. Sin embargo, esto no es suficiente ya que todavía necesitamos aplicar un conjunto de medidas de seguridad y escribir de forma segura código para proteger nuestra aplicación de amenazas y vulnerabilidades. A lo largo de este documento vamos a tratar los siguientes temas: ▪ Protección de aplicaciones ASP.NET Core. ▪ Recomendaciones de seguridad para APIs. ▪ Protecciones de aplicaciones Web alojadas en Azure. Cuando terminemos tendrás una serie de medidas de seguridad y consejos, que nos ayudará a crear aplicaciones web ASP.NET seguras. Además, conoceremos algunas recomendaciones de seguridad para proteger nuestras RESTful API, y algunos consejos para alojar de forma segura nuestra solución en Azure. Básicamente, pretendo daros una hoja de ruta para asegurar nuestra aplicación. Con este conocimiento podrás incorporar la seguridad a la arquitectura1 de la aplicación y que veas cuales son los factores más importantes a la hora de crear software seguro. 1. Cualquier desarrolladora/r debe implicarse y si ve que arquitectura no incluye esto, avisar y empezar a dar visibilidad. No se debe permitir trabajar sin un mínimo de seguridad.
5. Introduciéndonos en … (1/17) Prácticas clave de seguridad Vamos a explorar que medidas clave de seguridad debes tener en cuenta mientras construyes una aplicación web ASP.NET. A continuación, las medidas de seguridad: Autenticación / Authentication Aun me encuentro en entrevistas que muchas personas no saben que es el binomio: autenticar y autorizar. Autenticar es validar la identidad de un usuario que esta intentando acceder a nuestra aplicación. Comienza obteniendo las credenciales del usuario y luego validándolas con el proveedor de identidades, como por ejemplo Windows Active Directory o Azure Active Directory. El usuario se considera autenticado si el proceso de validación de las credenciales se produce con éxito (evidente). Después de autenticarse, el sistema debe iniciar el proceso de autorización para comprobar el nivel de acceso del usuario y decidir que datos y recursos son accesibles para ese usuario. Sin saber quien es el usuario, la autorización no puede llevase a cabo. Existen 4 formas diferentes de autenticarse en ASP.NET Core y que debemos conocer: Un mínimo y necesarios – Sin tener en consideración esto, tu aplicación no debe salir
6. Introduciéndonos en … (2/17) Prácticas clave de seguridad ▪ Cuentas Individuales / Individual Accounts Se utiliza cuando queremos hacer uso del modulo de identidad integrado en ASP.NET. Este módulo crea automáticamente las tablas de autenticación y autorización de SQL, junto con la interface de usuario que incluye: registro, incido de sesión, cierre de sesión y vista de confirmación del registro, a traves de la plantilla de Visual Studio. En este enlace: Introducción a Identity en ASP.NET Core, tienes una explicación desde 0 de esto que os estoy contando. No obstante, la captura es de esa página de Microsoft. A grandes rasgos cuando usas este sistema, los usuarios llegarán a una página para proporcionar sus credenciales, que se envían al servidor. Si procede, se emite una cookie que contine un token de identificación de usuario, que se adjunta a todas las solicitudes en el encabezado.
7. Introduciéndonos en … (3/17) Prácticas clave de seguridad ▪ Plataforma de identificación de Microsoft / Microsoft Identity Platform En este caso se usa cuando queremos autenticar contra, por ejemplo, Azure Active Directory (AAD). Tendremos que registrar nuestra aplicación en AAD y luego configurar nuestro proyecto. Aquí os muestro lo quedemos poner en un appSetting.json, este valor se obtiene tras registrar la aplicación, nos lo proporcionan. Puedes investigar más en este enlace: Ficheros de Configuración.
8. Introduciéndonos en … (4/17) Prácticas clave de seguridad Como podrás observar, lo usuario serán redirigidos al inicio de sesión de Microsoft, lugar donde se les pide que pongan las credenciales, y luego se le proporcionan un token si son validas las credenciales. Tras este paso, el usuario se redirige a la pagina de destino o una url que nosotros indiquemos en la respuesta devuelta por el proveedor de identidad. ▪ Windows O también conocido como Negotiate Kerberos o New Technology LAN Manager (NTLM). Este modo de autenticación es el más adecuado para aplicaciones ejecutándose en entornos de intranet bajo el mismo dominio de Windows. Puedes configurarlo para aplicaciones alojadas en IIS (Internet Information Server) o Krestel mientras ejecuta en una rede corporativa usando el dominio de Active Directory. Este proceso de autenticación se basa en el sistema operativo para obtener la identificación del usuario y confirmar la autenticación. Os dejo un enlace donde se explica detalladamente: Configurar la autenticación de Windows en ASP.NET Core. ▪ Ninguna Este caso se usa o bien cuando no necesitas identidad de usuarios, la aplicación es pública o bien cuando deseamos montar nuestro propio módulo de autenticación.
9. Introduciéndonos en … (4/17) Prácticas clave de seguridad A continuación, os dejo algunos consejos que debes tener en cuenta cuando implementamos un proceso de autenticación personalizado (o no): • Que el usuario use una contraseña compleja y crea un hash antes de guardarla en la tabla. • Nunca almacenes contraseñas en un campo oculto o un objeto tipo administración. Por más veces que lo recuerdo, vuelvo a ver esto y es bochornoso. • Encriptar el campo de entrada de la clave en el lado del cliente antes de enviarlo al servidor. En el servidor, cuando recibes la contraseña, la desencriptas, crea el hash, este lo comparas con el hash almacenado en la base de datos, si coincide, considera al usuario autenticado. • Si usas sesiones, asegúrate de borrarlas al cerrar la sesión y modifica el ID de la sesión; al iniciar una sesión debes generar un nuevo ID de sesión. • Hoy en día, intentaría exigir un doble factor (2FA). No es obligatorio tener un teléfono, puedes enviar ese valor via correo electrónico o una extensión del navegador que genere los números aleatorios de doble factor. Lo del teléfono u obliga a tu organización a que los empleados usen el propio o bien debes proporcionarlo, por eso te cuento que existen alternativas. Incluso se me ocurre que puedes proporcionar una tarjeta codificada como hacen los bancos. • Un clásico: nunca otorgues a ningun usuario acceso db_owner a la base de datos de SQL, extrapólalo a tu sistema de persistencia. Esto lo extendiéndolo incluso a la cadena de conexión de tu aplicación, sin querer tus aplicaciones db_owner… supongo que ya me entiendes. • Y el que te debería llevaría a la cárcel: nunca, repito nunca, pongas una puerta trasera con las claves en tu código. Es un clásico en cualquier programa legacy, pero que los dinosaurios en desarrollo continúan aplicando sin ton ni son.
10. Introduciéndonos en … (5/17) Prácticas clave de seguridad Autorización / Authorization Es el proceso de decidir si se debe otorgar un acceso a un ID de usuario a un recurso concreto de la aplicación. En general, la autorización comienza inmediatamente después de la autenticación, y existen diferentes tipos de autorizaciones que se pueden otorgar a un usuario: ▪ Autorización de URL / URL Authorization Otorga selectivamente a los usuarios y roles acceso a un URL particular de la aplicación. ▪ Autorización de archivos / File Authorization Se usa para proteger activos (assets) de una aplicación y evitar que usuarios no autorizados naveguen por esos directorios. ▪ Autorización de UI / UI Authorization Tambien llamado UI trimming (recorte). Este proceso permite o deniega de forma selectiva el acceso a partes arbitrarias de una pagina de la aplicación según el rol o usuario. Esta técnica elimina incluso páginas completas si el usuario no tiene acceso a ellas..
11. Introduciéndonos en … (6/17) Prácticas clave de seguridad Es muy facil de implementar en MVC agregando el atributo [Authorize] en la clase del controlador o acciones que no son anónimas: Si permites acceso anónimo a una acción en particular de una clase del controlador con atributo [Authorize], ten en cuenta que debes usar también [AllowAnonymous]. El atributo de autorización vale tanto para roles como para usuarios o politicas.
12. Introduciéndonos en … (7/17) Prácticas clave de seguridad Anti-XSS XSS es considerada la vulnerabilidad de seguridad numero uno en el mundo web, y desafortunadamente, muchos desarrolladores no están familiarizados con este riesgo. XSS es un tipo de ataque de inyección, el que el atacante ejecuta en el lado del cliente un script malicioso en el navegador del usuario final. Existen dos escenarios en el ataque XSS. ▪ Inyección pasiva Este tipo de ataque ocurre cuando una pagina web acepta una entra de texto unsanitized que pueden ser aprovechado maliciosamente. Supongamos que tenemos un lugar donde los usuarios pueden añadir comentarios en los artículos tras su compra y además permite interactuar a los usuarios entre sí, a modo pregunta/respuesta. Si el campo de entrada, donde debemos introducir el comentario, acepta el texto sin validación o desinfección, el atacante puede inyectar un script en el campo del comentario que se activará cada vez que un usuario acceda a ese articulo para ver los comentarios.
13. Introduciéndonos en … (8/17) Prácticas clave de seguridad ▪ Inyección activa En este caso se ejecuta inmediatamente cuando se carga la pagina en el cliente. Supongamos que tenemos una web que lee metadato de un query string de la URL, y muestra un mensaje de bienvenida cuando entramos en la página. Si el atacante manipula la cadena de conexión podría llegar a ejecutar un script. Veamos algunas recomendaciones para protegernos del ataque XSS: • Nunca confíes en una entrada de usuario, incluso si el usuario esta autenticado. Siempre se debe validar la entrada. Además, debes tener cuidado con las comillas simples o dobles, ya que es un punto de entrada para scripts. • Asegúrate de que el query string este bien codificado y siempre se validen los valores antes de usarlos. • Realizar una sanitización antes de almacenar contenido que no sea de confianza en una base de datos. La desinfección de HTML es el proceso de verificar el contenido que es dinámico y solo conserva tags de HTML que coincidan con una lista blanca. • Siempre debes usar @Html.Raw para renderizar contenido que no sea de confianza. • Debes codificar datos que no son de confianza antes de mostrarlos en HTML. De esta forma te evitas que no inyecten script en tu codigo, usa mecanismos para convertir < a @lt; que se tratan como un texto regular y no un tag. • Asegúrate de poner HttpOnly para evitar que nuestras cookies sean accesibles a través de codigo en el lado del cliente.
14. Introduciéndonos en … (9/17) Prácticas clave de seguridad Cross-Site Request Forgery (CSRF) / Falsificación de solicitudes entre sitios Tambien conocido como XSRF, y se pronuncia sea-surf o c-surf, es un tipo de ataque realizado por un sitio web malintencionado que fuerza a un sitio a realizar una tarea no deseada cuando el usuario esta todavía autenticado. Un ataque de este tipo es posible debido a que las request del navegador incluyen cookies que encapsulan tokens de autenticación. En este aso, el atacante se está aprovechando de una cookie de autenticación para engañar al sitio web de confianza, que no podrá distinguir entre solicitudes legitimas e ilegitimas, mediante la ejecución maliciosa usando una cookie de autenticación desde el sitio web de confianza. Este tipo de ataque también se conoce como on-click attack o session riding. La forma más sencilla de hacer un ataque CSRF es atraer la atención de un usuario via envio masivo de emails de phishing que afirman que el usuario tiene pendiente el cobro de una herencia de un tío rico o un teléfono de ultima generación o tu banco solicita que cambies la password o que te han congelado la cuenta bancaria. Por regla general, hay un enlace incluido que nos llevará al sitio malicioso con un botón. Por supuesto, muchos usuarios con cierto desconocimiento de la web no dudarán en hacer clic. Una vez pulsado el botón se envia una request al sitio de confianza mientras adjunta una cookie. Si el sitio es vulnerable, el atacante tendrá éxito y consigue poner en marcha CSRF.
15. Introduciéndonos en … (10/17) Prácticas clave de seguridad Un ataque de este tipo es posible debido a que las request del navegador incluyen cookies que encapsulan tokens de autenticación. En este aso, el atacante se está aprovechando de una cookie de autenticación para engañar al sitio web de confianza, que no podrá distinguir entre solicitudes legitimas e ilegitimas, mediante la ejecución maliciosa usando una cookie de autenticación desde el sitio web de confianza. Este tipo de ataque también se conoce como on-click attack o session riding. La forma más sencilla de hacer un ataque CSRF es atraer la atención de un usuario via envio masivo de emails de phishing que afirman que el usuario tiene pendiente el cobro de una herencia de un tío rico o un teléfono de ultima generación o tu banco solicita que cambies la password o que te han congelado la cuenta bancaria. Por regla general, hay un enlace incluido que nos llevará al sitio malicioso con un botón. Por supuesto, muchos usuarios con cierto desconocimiento de la web no dudarán en hacer clic. Una vez pulsado el botón se envia una request al sitio de confianza mientras adjunta una cookie. Si el sitio es vulnerable, el atacante tendrá éxito y consigue poner en marcha CSRF. Algunas recomendaciones para prevenir un ataque CSRF: • Genera un token y guárdalo en un campo oculto. Este token se envia en cada solicitud y debe validarse en todas las solicitudes. El token debe generarse en cada solicitud par evitar que un atacante simule esos tokens y engañen al proceso. En MVC podemos generar un token anti-forgery y aquí.
16. Introduciéndonos en … (11/17) Prácticas clave de seguridad • Verifica en header de la request entrante. Deben hacer referencia al mismo dominio del sitio web de confianza. Esto evitará o cancelará las solicitudes enviadas desde un dominio diferente. Robar Cookies / Cookies stealing Las cookies son parte esencial de un sitio web porque generalmente contienen detalles de la sesión del usuario. Una cookie es un objeto que se transmite entre el navegador y el servidor. Por lo tanto, en vez de autenticar por cada request al usuario, el token de autenticación almacenado en la cookie es nuestra opción, es decir, que sin una cookie con token el usuario debería una y otra vez autenticarse en la aplicación. Un robo de cookie o también llamado secuestro de cookie (cookie hijacking) es un tipo de ataque que permite robar la cookie de un usuario con sesión iniciada, tras suplantar a ese usuario se enviarán solicitudes en su nombre. Este caso, el servidor es engañado porque las solicitudes son de una autenticación valida. Para evitar el robo, os dejo estas recomendaciones: • Usa SSL y por tanto HTTPS. Para tender cifradas las comunicaciones entre cliente y servidor. • Intenta usar HttpOnly en el archivo web.config para asegurarte que las cookies se envían a través de SSL. • Regenera los Ids de sesión. • Piensa si puede borrar las cookies al cerrar la sesión de usuario. Es una medida a tener en cuenta.
17. Introduciéndonos en … (12/17) Prácticas clave de seguridad Overposting El Model Binding de ASP.NET maneja la asignación de datos entre solicitudes y el modelo de aplicación .NET. Es una característica muy buena que simplifica el proceso de rellenar propiedades del modelo de datos de entrada del usuario, según una convención de nomenclatura. Sin embargo, esto puede causar otro problema de seguridad al permitir al atacante completar algunas propiedades en el modelo que no se presentan en el formulario. Este tipo de ataque se llama también mass assigment. En el blog de Scott Hanselman tenéis un buen ejemplo: https://www.hanselman.com/blog/aspnet-overpostingmass-assignment-model-binding-security Como veis es de 2017, pero os aseguro que muchos arquitectos y desarrolladores en 2021 aun no conocen este problema. ¿Cómo podemos prevenir este tipo de ataque?
18. Introduciéndonos en … (13/17) Prácticas clave de seguridad • Hacer coincidir los parámetros entrantes, es decir, en lugar de usar un modelo completo como entrada, simplemente declara los campos que necesites pasar. En vez de usar IActionResult (modelo de usuario), usa IActionResult (string firstName, string lastName) y en la implementación luego mapeamos. En este caso las adiciones se ignoran. • Usa un View Model, en lugar de usar el modelo completo uso uno nuevo personalizado para la vista. Este nuevo modelo, solo dejamos las propiedades necesarias, y luego mapeas. Esta práctica es mejor que la anterior y es la que más uso. • Parámetro de una lista blanca, podemos usar la clase BindAttribute. Esto nos permite obviar algunos parámetros. • Y como colofón, nunca uses el modelo de entidades de la base de datos en las acciones de vista de MVC. Prevenir ataques de redirección abierta Veamos que quiero decir con esto. Digamos que tienes una aplicación web que redirige a los usuarios a un URL que se especifica en una query string o via request de HTTP, potencialmente esto puede ser alterado para redirigir a una URL maliciosa, para robarte credenciales. Supongamos que un atacante envió un mail con un enlace de redirección, como por ejemplo: http://www.tusitioweb.com?ReturnUrl=www.tusitioweb2.com/login
19. Introduciéndonos en … (14/17) Prácticas clave de seguridad Generalmente los usuarios no miran las cadenas y mucho menos verifican los dominios. Cuando cliques en la URL, serás redirigido a una pagina de inicio de sesión proporcionada por el atacante. Esta pagina suele ser un clon del aspecto de la original. En este caso, los usuarios proporcionan las credenciales pensado que son las del sitio bueno. Sin embargo, el atacante roba estas credenciales y te redirige al sitio web original y (ver la diferencia con CSRF, es más sofisticado) el usuario pensará que entro unas credenciales incorrectas, vuele a intentarlo y entra, logicamente. Ahora que sabes como se origina, ¿cómo podemos prevenir esto?. Lo primero es solo permitir redirecciones en URL locales dentro de nuestra aplicación y usar el método de ASP.NET llamado LocalRedirect. Esto se usa para redirigir a una URL local dentro de la propia aplicación: valida la URL antes de activarla y si no es local lanza una excepción. Además, existe un método que nos ayuda a validar si es local o no: Url.IsLocalUrl(…). Bloqueo por ataque de fuerza bruta En criptografía, un viejo conocido, intenta adivinar la contraseña probando combinaciones. En muchos casos el atacante usa un bot personalizado.
20. Introduciéndonos en … (15/17) Prácticas clave de seguridad Para prevenir esto podemos hacer lo siguiente: • Bloquea la cuenta tras una serie de reintentos. Ya sea temporal o completa y avisando al usuario para que contacte con el servicio técnico (esto depende mucho del target de tu aplicación y lo potente que sea el SAT). • Implementa una máquina de Turing, en ingles es: Complety Automated Public Turing test to tell Computer and Humans Apart (CAPTCHA), por si tenía curiosidad, aquí tienes el significado. Es buena idea contar con un servicio que lo implemente, evita crearte el tipico 2+2 = ?, esto es fácil de saltarlo con un script. • Considera permitir que se realicen logins con ciertas IPs y restringir el resto. No bloquees una IP, los malos pueden intentar entrar desde otro sitio. • Fuerza el uso de password complejos. • Considera el uso de 2FA, como creo haber contado, via mail, por ejemplo, para evitar el uso de móviles si no se dispusieran de ellos. Existen opciones sin tener que llegar a instalar una aplicación. • Considera usar reglas para los nombres de usuario, para evitar el los típicos admin, administrator, o nombre “fáciles” sean rechazados en el sistema. Que se usen nombres más complejos. Por ejemplo, aquí tienes mucha información sobre el doble factor: https://docs.microsoft.com/es-es/aspnet/core/security/authentication/mfa?view=aspnetcore-5.0
21. Introduciéndonos en … (16/17) Prácticas clave de seguridad Proteger la carga de archivos Una practica habitual es permitir subir archivos en un formulario, por ejemplo, la autorización para una prueba médica o subir un CV. Los atacantes puedes hacer uso de esta casuística para cargar archivos maliciosos. Aquí tienes algunos pasos de seguridad que deberías introducir cuando cargas archivos: • Deshabilita los permisos de ejecución en la carpeta donde almacenas los archivos. • Asegúrate de usar una lista blanca de extensiones, ya sabemos que esto no es gran cosa, pero ayuda. Y que primero lo valide el cliente web, luego el servidor. • Los tamaños de archivos debes restringirlos. • Verifica el encabezado del archivo cargado desde el servidor con cualquier librería que existe en .NET. • Si puedes introducir escaneo de un antivirus via un servicio de terceros. Esto dependerá de tu negocio, proponlo siempre que veas que el negocio podría adaptarse, por ejemplo, una aseguradora. Inyección de SQL Me da hasta vergüenza insistir en esto, pero es que aun lo veo y lo sigo viendo. Prevenir la inyección de SQL en ADO.NET y Entity Framework (si aquí también pasa) es una de esas vulnerabilidades que todo el mundo debería conocer.
22. Introduciéndonos en … (17/17) Prácticas clave de seguridad Una inyección es una vulnerabilidad que permite al atacante eludir la seguridad tomada en la aplicación para poder ejecutar comando SQL maliciosos. Con esos comandos, los atacantes pueden hacer el CRUD que quieran en la BBDD (normalmente). Vamos que pueden bórrate la base de datos y más te vale tener un sistema de backup, que, si no, ya rizas el rizo. Además, pueden escalar un ataque para comprometer a otros servidores SQL, no solo en el que llegó esa inyección. Os cuento como prevenir los ataques: • Comprueba, verifica, desinfecta, etc. Los datos de entra. • Evita concatenaciones en la ejecución de SQL, una sola ejecución permitida. • Nunca otorgues privilegios de administrador, lectura y escritura deberían ser suficientes. • Nunca envíes errores directos de la BBDD al usuario, crea errores personalizados para ellos y los reales lleva un log interno. Un error muestra mucha información que puede ser sensible. • Cifrar las conexiones con SQL via web.config. Y recuerda, estas vulnerabilidades no son solo para SQL, ocurren de igual forma en NoSQL como CosmosDB o MongoDB. Por tanto, las anteriores recomendaciones continúan siendo validas.
23. Algunas recomendaciones … Seguridad en General Antes os he contado las principales vulnerabilidades, ahora os destaco algunas recomendaciones que podrán aumentar la seguridad de tu solución: • Si puedes habilita las auditorias, loggins y trazabilidades en las request más importantes. • Por su puesto, mantén actualizado su framework de .NET para beneficiarte de mejoras. • Encripta las contraseñas antes de enviarlas al servidor para evitar ataques de sniffing. • Un paso habitual de seguridad es habilitar en los headers: - Content-Security-Policy: nos permite espeficiar una lista blacna de origen de contenido que se puede cargar en nuestra web. Ayuda con el atque XSS clic kjacking y otros tipos de inyección. - X-Content-Type-Options: ayuda a prevenir un ataque de sniffing, también llamado MIME-Sniffing. - X-XSS-Protection: habilita el filtro XSS. • Bloquea el ataque cross-frame scripting (XFS) habilitando X-Frame-Options en el header. • Evita divulgación de datos confidenciales de forma accidental, no creo que nadie quiera hacerlo a propósito, eliminado encabezados de respuesta del servidor: - Server: nos daría la versión del IIS, por ejemplo. - X-Powered-By: le dices que estas usando ASP.NET. - X-AspNet-Version: le das la información de la version de ASP.NET • Escanea y revisa las vulnerabilidades de librerias de terceros que estes usando. O usar por ejemplo SonarCloud que te lo mira en las fuentes. Y considera tener siempre una tarea de actualización periódica para los NuGet. • Si usas IIS, asegúrate de cifrar la cadena de conexión, tiene credenciales para acceder a la base de datos. Si usas Azure WebApp o Functions, usa variables de entorno o ficheros locales de configuración, pero evita el web.config. Cosa que son obvias – Pero que a veces se olvidan
24. Algunas recomendaciones … Web API Son esenciales ya que han logrado que la comunicación sea sencilla. Y esta sencillez debe ir a acompañada con medidas de seguridad igualmente sencillas para proteger nuestra Web API. Además de todo lo anterior, aquí van algunas cosas un poco desordenadas: • Usa TLS (Transport Layer Security) para cifrar comunicación entre aplicación y servidor. • Autentica a los usuarios que consumen las APIs. • Habilita auditorias, ya lo he dicho antes, con loggins, tras, herramienta de monitorización, etc. • Aplica si puedes, cuotas y limitaciones de uso a tu API, es importante controlar el ancho de banda y mantener el SLA del servidor. Lo puedes hacer con Azure API Management de forma muy sencilla, en mi blog si no esta ya, será en breve explico como moneterizar una API. • Valida los JSON para evitar inyecciones de SQL, por ejemplo. • Establece un firewall para el servidor donde alojamos el API • Considera tener un API Gateway para que este middleware entre cliente y servidor proteja, controle y monitorice el API, ya os comentado antes Azure APIM. • Y otro clásico, intentar que no tengamos un DDoS (ataque de denegación de servicios), ese que lanza gran cantidad de solicitudes para saturar la memoria y capacidad del servidor lanzando peticiones simultaneas. Si usas Azure existen recurso que hacen ese trabajo por nosotros a cambio de un importe economico, aunque algunas cosas son gratuitas, las más básicas, dale un vistazo a Azure y decide. • Por ultimo, yo podría un timestamp en cada header del request que se valida contra el servidor par aceptar solicitudes en base a una marca de tiempo particular. Por ejemplo, aunque más extenso, tienes este articulo. Las API son esenciales – Hoy en día, ¿quién no consume API?
25. Algunas recomendaciones … Azure Azure se preocupa por la seguridad a pesar del problemón que han tenido con CosmosDB, y muchas cosas nos las da out-the-box: • Dale un vistazo a Azure Defender y mira si se adapta a tu aplicación. • Pasa el scanner de evaluación de vulnerabilidades integrado en Azure Defender para servidores SQL, así amplias la protección de tus datos. • Si puedes usa PaaS en vez de IaaS, olvídate de actualizar la infraestructura subyacente. • Deshabilita el acceso anónimo a los blogs Storages, si es necesario, solo lo dejas en las carpetas necesarias. • Con Azure Functions, intenta usarlo conjuntamente con Azure APIM o usa bien CorS, … • Por supuesto usa SSL/TSL para proporcionar seguridad. • Deshabilita el modo de transferencia FTP y en su lugar usa FTPS. Yo con una Azure Function ni uno ni otro, pero cada uno debe decidir por si mismo. • Usa variables de entorno para credenciales y si puede Azure Key Vault, mucho mejor. • Usa un Firewall tipo WAF para prevenir ataques tipo DDoS, Inyección de SQL y XSS, ellos actualizando esto por ti y están más pendiente de lo que tu estarías o tu equipo. Mucha cosa nos las da Azure – Pero debes conocerlas, si no, ¿para qué?
26. ¡Gracias! Puedes encontrarme buscando por jmfloreszazo en https://jmfloreszazo.com