Web Fortificado: Mejores Prácticas para la Seguridad de Aplicaciones Web

Ok, esta charla se llama Fortificar o Fortaleza de la Aplicación. Intenta ver tu aplicación como una fortaleza. Y si piensas en las fortalezas, ¿qué hacen normalmente? Bueno, incluso si es como un edificio que ves en el entorno, si viajas o en películas, protegen algo valioso. Y sí, las películas son realmente el lugar donde he visto muchas fortalezas. Y esta pequeña pantalla aquí ha sido tomada de una película que realmente disfruto. Se llama El Señor de los Anillos. Es posible que hayas oído hablar de ella. Se trata de un viaje de un hobbit que necesita destruir un anillo en particular. Y es una trilogía. Así que hay tres películas, y especialmente la segunda parte, la disfruté mucho, ya sea el libro o la película, como la que se llama Las Dos Torres. Y hay una fortaleza llamada Helms Deep en ella. Y está destinada a ser un refugio. Así que está destinada a proteger a todo Ulthuan, que son las personas de Rohan, como una región o país en el sentido más amplio, creo. Deben ser protegidos del asalto de las fuerzas de Zaruman. Y tenían una advertencia de que nunca fue conquistada. Bueno, nunca conquistada, 100% seguridad. Supongo que lo hemos escuchado antes en algún momento, ¿verdad? Bueno, volviendo a la fortaleza. Puedes adivinar, no resultó ser cierto. Al menos una parte de la fortaleza no resistió. Y por supuesto, como es en las películas, es casi un cliché. Es nuevamente el Kilmaryr el Mar, que era un punto débil. Hola, Devstar? Era lo mismo que eso

Y no importa si estamos en El Señor de los Anillos, ya sea en la película o en los medios, el mundo está cambiando mucho. Aparecen más vulnerabilidades. Así que siempre debemos ser escépticos. Como Theodin. Si decimos que una fortaleza o una aplicación nunca ha sido conquistada o atacada o hackeada, debemos ser escépticos y extremadamente cuidadosos. Incluso si lo fue

Y en él, echaremos un vistazo a los tres primeros, porque son los más significativos y más importantes para tener en cuenta, especialmente si queremos aplicar prácticas recomendadas o como algunas pequeñas pero fáciles de aplicar mejores prácticas para mantener segura tu aplicación. Así que aquí va un pequeño spoiler. Uno de esos tres puntos es el más importante para nosotros en el frente, pero los otros también son importantes. Así que el primer lugar, eso es algo que quiero cubrir porque es el primer lugar en el ranking. Es importante y hay algo que nosotros como desarrolladores front-end podemos hacer. Es el control de acceso roto. Este punto trata sobre el riesgo de seguridad en la autorización. Y como autenticación es el primer paso para la autorización porque necesitas saber quién eres, como quiénes son tus usuarios dentro de tu aplicación para saber qué se puede permitir para ella o qué permiso se le puede otorgar. Y sí, hay algunos puntos front-end que debemos tener en cuenta de una manera fácil. No es el enfoque completo de esta charla, pero permítanme mencionar la primera mejora fácil. Es mostrar mensajes de error genéricos para la autenticación. Imagina que tienes un formulario de inicio de sesión. Alguien ingresa credenciales inválidas y dices algo como, oh, tu contraseña es incorrecta. Esto no es una buena idea porque si el atacante ve este mensaje de error, sabe que la contraseña es lo que necesita para realizar un ataque de fuerza bruta. Como si solo necesitara probar algunas otras contraseñas porque sabe que es una contraseña. Así que pensemos en un mensaje de error genérico como que el nombre de usuario o la contraseña son incorrectos. De esta manera, el atacante no sabe qué es exactamente lo que está mal dentro de este formulario de inicio de sesión, lo que nos ayuda a ser un poco más seguros. Y como dije, siendo DDoS, debemos pensar en un límite de velocidad. Entonces, un atacante no podría simplemente enviar spam a tu aplicación con todas las contraseñas posibles, ¿verdad? Tener un pequeño temporizador o un límite de velocidad donde bloqueas tu aplicación te ayudará mucho a mantener seguros a tus usuarios. Si no quieres encargarte completamente de este punto, puedes pensar en usar bibliotecas de terceros como Auth0, por ejemplo. O, por supuesto, podrías construirlo tú mismo si eres lo suficientemente valiente. Hay ejemplos para introducir, por ejemplo, tokens JWT para la autenticación basada en tokens dentro de las aplicaciones, pero hay muchos más. En el contexto del front-end, sin embargo, hay un punto de los tres, como el control de acceso roto, los valores criptográficos y la inyección, que es especialmente importante para nosotros, los desarrolladores front-end. Así que supongo que ya lo viste.

Quiero hablar sobre la inyección. La inyección es en realidad el riesgo de que un atacante suministre datos no confiables a un programa, lo que significa en detalle que la entrada puede ser entregada por un campo de entrada u otros medios y luego procesada por un intérprete como parte de un comando o una consulta. Y esto lleva a que esta entrada maliciosa se ejecute como tu propio programa. Por lo tanto, también es la ejecución de ese problema básicamente. Y esos ataques incluyen cross-site scripting o XSS, y también pueden ser inyecciones SQL donde tienes el ángulo de una consulta o más.

Y esas inyecciones pueden ocurrir si los datos, que son suministrados por el usuario, por ejemplo, un campo de entrada, no se validan, filtran o desinfectan, o si tienes consultas dinámicas o llamadas no parametrizadas sin contexto que estemos escapando. Por lo tanto, se utilizan directamente dentro de tu intérprete. Por lo tanto, es bastante obvio por qué este es un ángulo de ataque importante por parte de un cliente o de las partes front-end de tu aplicación.

Entonces, ¿cómo podemos prevenirlos? Lo más fundamental, y realmente necesito enfatizar esto, es nunca, nunca utilices contenido no confiable como plantilla de tus componentes. Si estás utilizando, por ejemplo, Vue.js, que utilizaré como ejemplo a lo largo de la charla, pero trataré de ser lo más agnóstico posible. Pero si estás utilizando React, Angular, Swift o cualquier otro framework, búscalo. No sería muy diferente, porque si utilizas contenido no confiable o contenido que no puedes controlar como plantilla de tus componentes, será equivalente a permitir la ejecución arbitraria o de JavaScript dentro de tu aplicación. Sé que en el contexto de Vue.js en particular, una plantilla se compilará en JavaScript. Y todas las expresiones dentro de esas plantillas se ejecutarán como parte del proceso de renderizado. Así que por favor, no lo hagas. Simplemente no lo hagas. Solo agrega contenido confiable, que esté controlado y sea confiable por ti.

Y por favor, no esperes que tu framework haga todo el trabajo pesado, porque hay algunas funciones que tu framework, tal vez Vue, React, Angular, te ayudarán a estar protegido. Pero es impráctico, especialmente desde el punto de vista del rendimiento, que tu framework haga todo el trabajo por ti. Sin embargo, tu framework puede ser la primera línea de defensa a la que debes prestar atención. Como dije, usaré Vue.js como ejemplo, porque soy desarrollador de Vue, pero puedes buscar fácilmente para React o Angular qué funciones de seguridad te proporcionan. Entonces, ¿qué medidas puede proporcionar un framework por sí mismo? En el ejemplo de Vue en este momento. Echemos un vistazo. Entonces, la inyección se previene fácilmente mediante el escape adecuado del contenido, por ejemplo. Por lo tanto, se escapan las cadenas de script, los caracteres especiales. Entonces, las etiquetas de script, como la que tengo aquí, como debajo de este fragmento de código, no se pueden ejecutar de ninguna manera. Y si usas una cadena proporcionada por el usuario en Vue, que contiene el script mencionado al respecto, se escapará a esto. Entonces, el script ya no está ahí, está escapado. Y esto evitará la inyección de script. En el caso de Vue, el escape se realiza utilizando API nativas, como TextContext. Y se hace algo similar con la vinculación de atributos en Vue. En resumen, si tu framework te proporciona funcionalidad para escapar la entrada de datos proporcionada por el usuario, úsala. Como dije, tu framework puede proporcionar muchas funciones de seguridad, pero no puede ser lo único en lo que confíes, ya que es demasiado pedir. Por lo tanto, siempre será el caso de que la protección más importante eres tú mismo. Así que me enfoco en cómo construyes tu aplicación o cómo aplicas estándares y algunas mejores prácticas. Echemos un vistazo a algunas prácticas y cosas a considerar que te ayudarán a aumentar la seguridad dentro de tu aplicación rápidamente.

Consideremos agregar enlaces mediante la vinculación del atributo href. Así que en realidad estoy hablando de las URL proporcionadas por el usuario, que podrían contener direcciones incorrectas de Vue o incrustaciones de JavaScript, como aquí. Los casos que puedo pensar en este sentido podrían estar relacionados con el phishing, al construir e ingresar una URL dentro de tu aplicación que dirija a un sitio web malicioso, o una suscripción de curso reflejada.

Entonces, hay una URL que se muestra en la aplicación web. Pero un atacante agregará algo de JavaScript a la URL. Nuevamente, la sanitización te ayudará mucho a evitarlo. Por lo tanto, podrías considerar usar bibliotecas como sanitizeURL para ayudarte. Supongo que lo pondré en un tuit, para que puedas encontrarlo aún más fácilmente, porque veo que no agregué un código QR. Pero no olvides tu backend, ya que tu backend siempre debe sanear las URL proporcionadas por el usuario antes de guardarlas en una base de datos. Y lo último, pero aún importante, ten en cuenta que las URL siempre pueden dirigir a destinos inseguros, incluso si al principio son destinos seguros. Por lo tanto, es el punto en el que pierdes el control.

Bueno, el siguiente tipo de inyección es la inyección de estilos, un tipo que me sorprendió al principio, porque pensé, ¿estilizar con CSS, verdad? ¿Cómo puede ser un ángulo de ataque? Pero hay un punto. Existe una técnica llamada ataque de redireccionamiento de la interfaz de usuario (UI redress). Imagina que tienes un control oculto de la interfaz de usuario. Entonces, un atacante lo estilizará. Ok, comencemos con un ejemplo. Tienes un formulario de inicio de sesión con un botón de inicio de sesión para enviar tus credenciales, y el atacante estilizará este botón de inicio de sesión como otra caja transparente que cubre este botón de inicio de sesión. Y luego, estilizará un enlace sobre él. Así que no enviarás tus credenciales de inicio de sesión a la página que esperas, sino que te llevará a una página de inicio de sesión falsa al tener una caja transparente encima o cubriendo tu botón de inicio de sesión. Redireccionamiento, en realidad. Entonces, con estos estilos proporcionados por el usuario aquí, los usuarios malintencionados podrían proporcionar CSS para hacer clic en la verificación. ¿Cómo podemos evitar eso? Bueno, deberíamos permitir que el usuario ajuste el estilo solo de manera segura, como tener un iframe en un entorno seguro o permitir el control total de CSS de manera segura. Es decir, en este sentido, el usuario solo puede establecer un color determinado o solo un fondo determinado, todos esos cambios que no son tan peligrosos, ¿verdad? Entonces, hay muchas formas de mantenerlos seguros limitando el alcance donde un usuario puede proporcionar estilos.

Por supuesto, también hay un ángulo de ataque en el propio JavaScript, que se llama inyecciones de JavaScript. Y hay algunas cosas que no deberías hacer en Vue, al menos, pero también cuando se trata de otros frameworks. Porque desde un punto de vista de código limpio o de mantenibilidad, las plantillas y las funciones de renderizado no deben tener efectos secundarios, ya que dificulta mucho la depuración. Por lo tanto, debes evitar tener atributos que acepten Strings.js. Es decir, no se deben utilizar eventos como unclick o unfocus, ni atributos. Y los scripts, por supuesto, no deben usarse en ningún complemento. Por lo tanto, se deben evitar estos elementos.

Bien, otro punto, que se mencionó, supongo, en el séptimo lugar. Así que no lo marqué en el ranking más antiguo, pero es una buena práctica tener siempre en cuenta. Si tienes un proyecto que se vea así, como el pequeño proyecto de prueba que configuré. Normalmente, no está en producción. Pero no importa si tu proyecto ya está en producción o solo está en modo de desarrollo, nunca debería verse así. Desactualizado, con tantas vulnerabilidades, incluso dos críticas. Por favor, siempre intenta mantener tus paquetes NPM o los paquetes de cualquier administrador de paquetes que uses y tu framework actualizados a la última versión. Y hay algunas cosas que puedes hacer para asegurarte sin poner tanto esfuerzo en ello. Como usar Dependabot si alojas tu proyecto en GitHub o usar NPM audit u otros comandos similares. Echar un vistazo a las bases de datos de CWA donde se mencionarán las vulnerabilidades divulgadas públicamente. Así que por favor mantén tus proyectos actualizados y no esperes demasiado tiempo para aplicar parches de seguridad.

De acuerdo. Cuando se trata de mantener seguras tus aplicaciones web, cuando se trata de tener tu aplicación como una fortaleza, cuando se trata de mi charla, hay algunas cosas que quiero que recuerdes. En realidad, cuatro cosas para recordar. Primero, ya sea Vue, ya sea React, ya sea Angular. Tu framework es la primera línea de defensa y tú eres la segunda línea más importante, pero eres la segunda que marca la mayor diferencia. Por favor, nunca uses plantillas no confiables o plantillas. No puedes controlar las plantillas que no son tuyas. Plantillas en las que no confías. Puedes aplicar muchas pequeñas mejores prácticas como sanitizar, escapar, limitar el alcance de las cosas que un usuario puede proporcionar. Muchas de esas cosas. Y por último, pero no menos importante, ten en cuenta tus dependencias. Mantén tus proyectos actualizados.

Aquí puse algunos códigos QR para obtener más mejores prácticas que me ayudaron mucho, que realmente utilicé las mejores prácticas agnósticas al framework como las de HTML5 de una página completa de OWASP. Siempre tiene sentido echar un vistazo aquí. Y buscaré más recursos yo mismo y los publicaré en Twitter, para no consumir demasiado de tu tiempo porque, sí, hay muchas cosas que puedes hacer. Bueno, ¿qué queda por decir entonces? Gracias por escucharme, por estar aquí, por estar interesado en temas de seguridad y por intentar hacer de la web un lugar más seguro para nosotros, para los desarrolladores y para los usuarios. Si tienes alguna pregunta, solo pregúntala. Encuéntrame en todas las plataformas conocidas como Twitter, Mastodon, LinkedIn y, sí, nos vemos. Hasta pronto. Adiós.