Vuelta a los Origenes: Seguridad con ASP.NET

VUELTA A LOS ORIGINES:
DESARROLLO SEGURO EN ASP.NET

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

▪ 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.

View Slide

▪ 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.

View Slide

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.

View Slide

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.

View Slide

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..

View Slide

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.

View Slide

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.

View Slide

▪ 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.

View Slide

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.

View Slide

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í.

View Slide

• 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.

View Slide

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?

View Slide

• 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

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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?

View Slide

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é?

View Slide

¡Gracias!
Puedes encontrarme buscando por jmfloreszazo en
https://jmfloreszazo.com

View Slide

Vuelta a los Origenes: Seguridad con ASP.NET

Vuelta a los Origenes: Seguridad con ASP.NET

Jose María Flores Zazo

More Decks by Jose María Flores Zazo

Other Decks in Technology

Featured

Transcript