La Caja de Herramientas de Seguridad para Node

Muy bien, hola a todos. Mi nombre es Milesha McGregor, y soy una defensora del desarrollo en Conducto. Así que creamos esta herramienta realmente genial donde puedes debug tus pipelines y hacer tus despliegues más fáciles y todas esas cosas buenas. Así que asegúrate de seguirme y seguirnos en Twitter. Pero hoy, voy a hablarles sobre una caja de herramientas de seguridad que pueden construir para todas sus aplicaciones Node. Como hemos estado en modo virtual durante tanto tiempo, siempre me gusta dar una visión general. De esa manera, sabes dónde puedes sintonizar, desconectar, adelantar el video más tarde cuando lo vuelvas a ver.

Pero para empezar, voy a comenzar con las 10 principales vulnerabilidades de OWASP. Cubriremos prácticamente todas ellas y algunos de los paquetes y otras herramientas y estrategias que puedes utilizar para asegurar tus aplicaciones Node contra este tipo de ataques. Y luego hablaremos sobre cómo puedes manejar tus paquetes porque como todo ingeniero de JavaScript sabe, usamos un paquete para casi todo. Así que quieres asegurarte de cuidarlos. Y también hablaremos un poco sobre la gestión de tus datos. Todos sabemos en el backend que no queremos que otras personas o personas que no deberían tener acceso a los datos realmente puedan acceder a los datos. Así que vamos a hablar sobre algunas estrategias diferentes que podemos utilizar para asegurarnos de que, ya sabes, nadie que haya sido despedido hace tres meses vuelva y borre todas las bases de datos. Y hablaremos un poco más sobre cómo proteger tu servidor de diferentes ataques, como los que simplemente apagan tu servidor. Sé la palabra para esto, pero la recordaré mucho más tarde de lo que debería. Y luego terminaremos con algunas conclusiones clave y algunas cosas que espero que puedas implementar en el trabajo tan pronto como puedas.

Para empezar, vamos a sumergirnos en las 10 principales vulnerabilidades de OWASP. Hay una aplicación llamada node goat que simplemente existe y te guiará a través de las 10 vulnerabilidades utilizando esta pequeña y genial aplicación Node. Así que si quieres ver algunos ejemplos en vivo desarrollados por algunos de los mejores expertos en seguridad del mundo, echa un vistazo a esta aplicación node goat. Pero una cosa que debes tener en cuenta con estas 10 principales vulnerabilidades de OWASP es que están presentes en, creo que era el 85% de todas las aplicaciones web en línea en este momento. Así que casi todo Internet es vulnerable a algún tipo de ataque. Y esa es la razón por la que quiero darte algunas herramientas y cosas que puedes usar para asegurarte de que no tienes una de esas aplicaciones o que cuando te encuentres con una puedas limpiarla y asegurarte de que sea menos vulnerable a ataques. Así que lo primero de lo que vamos a hablar es del cross-site scripting. Básicamente, esto ocurre cuando alguien inyecta JavaScript en tu aplicación y hace que la aplicación redirija a los usuarios a algún otro lugar, roba cookies para autenticarse como otros usuarios, o básicamente en cualquier lugar donde haya algún tipo de campo de entrada en el que puedan escribir texto, pueden ejecutar alguna declaración de JavaScript. Así que queremos asegurarnos de que alguna persona aleatoria en Internet no esté inyectando o haciendo cross-site scripting de algo realmente loco en nuestra aplicación, así que vamos a prevenir eso. Y para hacerlo, comienza validando todas tus entradas. Sé que ya lo hacemos porque la validación de formularios es lo favorito de todos. Pero solo quiero asegurarme de que realmente todos lo estemos haciendo. Así que valida esas entradas, asegúrate de que los campos numéricos realmente reciban números.

Asegúrate de que las contraseñas cumplan con ciertos requisitos de seguridad, ya sea letras minúsculas y mayúsculas, números, caracteres especiales, lo que desees. Pero asegúrate de validar estas entradas para que un usuario no pueda enviar un formulario si no está en el formato correcto.

Y luego, algo más que puedes hacer para ayudar con el tema del secuestro de sesión con el cross-site scripting, es codificar todos los datos que envías a tus usuarios. Sabemos que necesitamos codificar los datos que nos envían, especialmente cuando estás en una red abierta, para que personas no autorizadas no tengan acceso a ellos. Asegúrate de hacer lo mismo al enviar datos. Así que cifra todo.

Ahora hablaremos sobre los ataques de denegación de servicio. Un ataque de denegación de servicio ocurre cuando una parte malintencionada obtiene acceso a tu servidor y envía tantas solicitudes que hace que el servidor se caiga para todos tus usuarios reales. Esto significa que alguien está enviando suficientes solicitudes que están utilizando todos tus recursos en la nube o en las instalaciones, hasta el punto en que tu aplicación básicamente no está disponible. No quieres que ocurran ataques de denegación de servicio, especialmente cuando tu aplicación es algo muy importante para tus usuarios. Para prevenir eso, realmente queremos implementar comprobaciones para prevenir bucles y creación de datos. No quieres que alguien pueda enviar una consulta a tu back-end que agregue infinitamente usuarios falsos a tu base de datos. Esa es una de las formas en que un ataque de denegación de servicio puede hacer que toda tu aplicación se caiga. Y nuevamente, valida todas esas entradas. Hoy en día, hay formularios en casi todos los sitios, ya sea para obtener tu correo electrónico o de alguna manera convencerte de iniciar sesión con Google. Valida esas entradas. Están ahí, así que asegúrate de hacerlo tanto en el front-end como en el back-end.

Ahora hablemos un poco sobre el ataque de inyección en el servidor. Esto ocurre cuando una parte externa puede inyectar datos como parte de una simple consulta. Esto sucede cuando puedes enviar consultas incorrectas en los formularios. Básicamente, lo que está sucediendo es que alguien está escribiendo una consulta SQL donde debería estar escribiendo un nuevo nombre de usuario. Y ahora tienes tu base de datos eliminada y nadie sabe por qué. Simplemente porque alguien pudo enviar esta solicitud al back-end y no había ningún tipo de comprobación para evitar que eso sucediera. Para prevenir eso, una cosa que debes hacer es analizar cualquier entrada de usuario. Sabes qué tipo de datos esperas del front-end. Sabes qué valores deben almacenarse en la base de datos. Tienes todo un esquema para esto. Entonces, cuando recibas esta entrada de usuario, simplemente analízala en lo que realmente debe estar presente.

Esto ayudará a identificar rápidamente muchas de esas cosas extrañas. Y te ahorrará el pánico extremo de tener algo agregado a tu base de datos sin saber quién lo hizo. Estoy seguro de que ya lo estás entendiendo, pero sigue validando todas esas entradas. Nuevamente, el front-end esperemos que haga algún tipo de validación solo en el lado del cliente, pero en caso de que haya una gran refactorización y se omita la validación del formulario, no es que eso haya sucedido antes, pero en caso de que suceda, ten esa validación en tu aplicación de Node.

Entonces, ahora vamos a lo importante que es JavaScript. ¿Cómo manejamos nuestros paquetes? Uno de los diez principales de OWASP tiene que ver con el uso de componentes que tienen vulnerabilidades conocidas. Y estoy seguro de que cuando ejecutas NPM install o Yarn ves esas tal vez un puñado de vulnerabilidades, algunas de ellas pueden ser graves, muchas pueden ser moderadas, pero simplemente asumes que está bien. Nada va a pasar. Y boom, tienes una puerta trasera en tu aplicación que cualquier persona interesada ya conoce porque probablemente ya se haya corregido y solo necesitas actualizar el número de versión. Por lo general, se lanzan parches de forma rutinaria, cuando el paquete de alguien es atacado o encuentran una vulnerabilidad en él, normalmente el mantenedor o los mantenedores lanzarán un parche para eso, detallando todas las vulnerabilidades que estaban presentes en esa versión. Por eso, al revisar las versiones de tus dependencias, si tienes algo en GitHub, esta es una de las formas en que los atacantes pueden descubrir un punto débil en tu aplicación. Ya saben que hay un informe completo sobre por qué esta versión de este paquete es vulnerable. Así que asegúrate de que cada vez que publiques una nueva versión o hayas hecho una gran refactorización o algo así, verifica tus paquetes. Haz una auditoría rápida de NPM. Esto enumerará todo lo que tiene una vulnerabilidad. Enumerará cualquier cosa que esté desactualizada. Así que simplemente ejecuta NPM audit, y luego está NPM Audit Fix, que actualizará automáticamente esos paquetes por ti. Así que no hay mucho trabajo que hacer de tu parte la mayoría de las veces. A veces hay algunas interdependencias extrañas de versiones, pero NPM Audit Fix generalmente funciona en muchas cosas. Y luego, si quieres asegurarte de que todos tus paquetes estén actualizados, usa NPM Outdated, y esto mostrará una lista de todo en tu proyecto que está desactualizado. Te mostrará en qué número de versión te encuentras actualmente y cuál es el más actual. Estos son solo algunos comandos que puedes ejecutar para hacer una verificación rápida de esa dependencia en componentes que tienen vulnerabilidades.

Y con tus paquetes de NPM, muchos de nosotros publicamos cosas, ya sea de forma privada dentro de nuestra organización o de forma pública para que otros desarrolladores las usen. Asegúrate de que tu acceso a estos paquetes de NPM sea considerado. Usa autenticación de dos factores. Usa tokens de solo lectura. Esta es una forma sorprendente en que las personas obtienen acceso a partes de tu aplicación que realmente no quieres que conozcan. Probablemente no quieras que un atacante conozca tu sistema de autenticación personalizado. No quieres que vean ese código fuente porque sabrán cómo romperlo. Pero estas son dos formas en que obtienen un acceso más fácil.

Cuando solo estás utilizando la contraseña, sabemos que las contraseñas se pueden descifrar. Cuando estás utilizando tokens que proporcionan acceso de lectura y escritura, bueno, si obtienen acceso a ese token, tienen acceso a prácticamente lo que necesitan. Podrían cambiar el código de tu motor de autenticación personalizado y nadie sabría quién lo hizo.

Pero la mayoría de las veces, estos tokens solo se utilizan en tus canalizaciones de CI/CD, o tal vez tienes algún tipo de archivo de entorno que utilizas localmente o en diferentes entornos. Entonces, cuando sabes que solo estás utilizando tu paquete npm en algún lugar, no estás tratando de publicar cambios con este token, simplemente usa el de solo lectura. Te ahorrará tiempo. Te dará un poco más de tranquilidad por la noche y sabrás exactamente quién tiene el acceso correcto a tus aplicaciones.

Bien, ahora pasemos a manejar tus data. Porque data es realmente este vasto y místico fenómeno en nuestro mundo. Pero algo que debes hacer antes de agregar nuevos data a tu database, es asegurarte de que hayas pre-sanitizado estos valores. No quieres agregar una declaración SQL a tu database. Solo sabes qué tipos esperas que se ingresen en cada columna de tu database. Asegúrate de que el valor coincida con eso. No debería haber números intentando escribirse en columnas de texto o correos electrónicos guardados en campos de dirección. Solo realiza una verificación adicional y asegúrate de que estos data coincidan con lo que esperas.

Y una de las formas en que hacemos esto en Node es simplemente tipificar tu esquema. La mayoría de los ORMs que utilizamos, como Mongoose u otros, olvidé el que viene con Postgres, pero da igual. Conoces los tipos exactos. Conoces los nombres de los valores. Conoces todo lo que necesitas saber para hacer que sea imposible guardar un tipo diferente de data en tu database. Y solo necesitas un paquete rápido. Simplemente usa validator.js. Esto facilita agregar esa validation a tus aplicaciones Node sin tener que crear tus propias funciones de validation. Tienen cosas para correos electrónicos, números de teléfono, contraseñas, y todo eso. Y solicitudes y respuestas.

Esto es algo de lo que creo que todos debemos estar definitivamente conscientes. Asegúrate de usar Helmet.js para tus encabezados. Esto agrega diferentes configuraciones de security a tus encabezados que honestamente nunca había pensado hasta que usé esta biblioteca. Pero básicamente ayuda con cualquier problema de CORS, bloquea las diferencias entre las solicitudes GET y POST y se encarga de muchas cosas detrás de escena que no necesariamente piensas mientras escribes tu código.

Y luego, cuando se trata de manejar los datos del usuario, anteriormente estaba hablando de asegurarse de que todo estuviera cifrado, bueno, usa Crypto.js.

Esto tiene SHA 256, tiene el MD5, lo que más te guste, Crypto.js tiene algo que puedes usar para cifrar tus data. Y nuevamente, hacemos esto porque durante esos momentos desde el servidor hasta el cliente, cualquiera puede interceptar esa respuesta o esa solicitud. Y eso significa que si interceptan eso, entonces tienen acceso a cualquier data que estuviéramos enviando o recibiendo. No queremos que puedan verlo fácilmente. Y por eso ciframos las cosas, incluso si obtienen la solicitud o la respuesta, no importa. Estará cifrado para que no puedan hacer nada con él.

Y ahora podemos hablar sobre cómo proteger tu servidor porque este es como tu joya preciada junto a la database. Lo protege. Así que quieres asegurarte de tener un guardia fuerte. Usa HTTPS. No, es algo que sabemos que debemos hacer, que nos han dicho que hagamos, que nos han marcado como sitios web inseguros si no lo hacemos, pero aún sorprende cuántas personas no están usando HTTPS. Solo adelante y úsalo.

Y luego realiza limitación de velocidad. Esto ayudará a manejar esos ataques DDoS y cualquier otra cosa que pueda hacer que tu servidor se bloquee solo por tener algún tipo de bucle en él. Entonces, una de las formas de hacer esto es con el paquete express rate limit. Y solo se asegura de que solo se permita un cierto número de solicitudes durante un determinado período de tiempo. Y luego, para evitar la falsificación de solicitudes entre sitios, no queremos que alguien use la computadora de otra persona para enviar solicitudes a nuestro servidor. Entonces, para hacer eso, simplemente puedes agregar csurfjs. Y esto protege tus puntos finales de este tipo de ataque.

Entonces, solo para resumir rápidamente aquí, hay algunas cosas que quiero que te lleves. En primer lugar, utiliza las herramientas que están disponibles. No tienes que crear tu propio conjunto de herramientas de seguridad. Ya hay muchos paquetes y bibliotecas que hacen todo por ti. Y luego, no esperes a que haya una violación de seguridad para implementar la seguridad. Adelante y haz cosas como instalar helmet.js para una victoria rápida. Y ten en cuenta que Express en sí mismo facilita el manejo de las principales amenazas. Hay muchos paquetes diferentes. Y una vez que estés usando Express, sabrás cuántos métodos y parámetros tienes disponibles para eso. Y por último, mira algunas de las herramientas que utilizan los atacantes. Están en línea. Muchas de ellas son de código abierto. Y no hay razón para no saber contra qué te estás defendiendo si estás interesado. Una cosa en particular que recomiendo es el sistema operativo Kali Linux. Viene con un montón de herramientas de ataque preinstaladas. Así que échale un vistazo si estás realmente, realmente interesado en el hacking. Pero eso es todo lo que tengo para ti hoy.

Gracias por quedarte y estaré aquí para responder preguntas. Bueno, es bueno tenerte de nuevo. ¿Qué opinas de este resultado? La implementación de security, eso es lo más difícil en el desarrollo backend. ¿Estás de acuerdo? ¿Es lo que esperabas? Creo que probablemente es una de las partes más difíciles solo asegurarse de que ninguna persona extraña o atacante tenga acceso a tus data o manipule tu sistema de alguna manera que no deseas. Pero algo más que creo que es un problema difícil es la multi-tenencia. Así que eso es, no sé, es solo un gran problema. Sí, estoy de acuerdo. Bueno, primero tenemos un comentario de uno de nuestros visitantes, Marsau001. Dice: me encanta esta charla sobre mi tema favorito, la ciberseguridad. Así que un poco de amor de Marsau001. Gracias. Tenemos una pregunta, o tengo una pregunta. ¿Dónde puedo obtener más información sobre diferentes vulnerabilidades web? ¿Cuáles son algunos buenos recursos? El más grande es definitivamente el sitio OWASP top 10. Tienen esta herramienta realmente buena. Creo que se llama OWASPnode, node goat, eso es lo que se llama. Y es prácticamente solo esta aplicación que está configurada para mostrarte cómo se ve cuando una aplicación de node tiene ciertas vulnerabilidades. Y tienen un ejemplo para, creo que todos los 10 principales. Bueno. Node goat. ¿Puedes compartir el enlace después de las preguntas y respuestas en el canal de Discord, para que la gente pueda encontrar esto? Genial. Otra pregunta, ¿hay momentos en los que security debería ser manejada solo en el front-end o siempre debería ser manejada en el back-end? Por supuesto, hay cosas que se pueden hacer en el front-end. Sabes, la validación de formularios es importante, asegurarse de tener permisos de usuario y cosas aseguradas. Pero el front-end nunca debería ser la única fuente de security. Entonces la mayoría de las cosas deberían ocurrir en el back-end, la mayoría, si no todo, debería ocurrir en el back-end. Sí, mencionaste, como, validación de formularios. ¿Sueles hacerlo doble, tanto en el front-end como en el back-end? Sí, eso no hace daño en absoluto. Como limpiar esos data antes de que lleguen al back-end ahorra, ya sabes, un poco de tiempo. Tal vez mejora un poco el performance, así que si recibes 800,000 solicitudes en un minuto, no se convierte en un gran problema. Sí, exactamente.

Y, sí, como dijiste, puede, como, la retroalimentación más rápida también es genial para la user experience, pero sí, el front-end puede ser manipulado por personas como tú y yo. Entonces, sí, también es bueno verificar algo en el back-end.

Veo a Juliana sonriendo, y a mí. La siguiente pregunta es de Fried Zoidberg. Podemos hablar. ¿Tienes algún otro ejemplo de herramientas que los atacantes podrían estar utilizando? Y él ya ha echado un vistazo a Kali Linux. Algunas otras herramientas que los atacantes podrían estar utilizando, sé algunas de ellas con las que estoy personalmente familiarizado serían Wireshark, y eso es solo para interceptar cualquier solicitud o data que se envíe a través de una red. Luego está, creo, no recuerdo el nombre de muchas de ellas porque todas están incluidas en ese sistema operativo Kali Linux, pero Wireshark es probablemente, no sé, mi favorita para usar. Te sorprendería lo que la gente accede en redes Wi-Fi públicas.

De acuerdo, genial. Tal vez también sea una buena idea agregar eso a los enlaces compartidos en el discord después. La siguiente pregunta es de Juan González. ¿Cuáles son tus pensamientos relacionados con la seguridad entre Node y Deno? Oh, esa es una buena pregunta. Desafortunadamente, no he tenido la oportunidad de trabajar mucho con Deno, por lo que no tengo una buena comparación. Hmm. Bueno, esperemos que haya un experto en Deno en nuestra audiencia que pueda ayudar a Juan con su pregunta.

La siguiente pregunta es de, bueno, no sé cómo pronunciar esto, 1-L-V-4-N. Es un nombre de usuario, no un nombre real. Buen trabajo. ¿Hay alguna preocupación de seguridad que debamos tener en cuenta cuando se utiliza Node en combinación con Docker? Hmm. Creo que siempre y cuando cubras esas 10 principales, estarás bien, ya sea en Docker o no, pero algo que podrías verificar es quién tiene acceso a los diferentes contenedores que inicias? ¿Están esos contenedores en tu nube? ¿Están en tus instalaciones? ¿Tienes una contraseña que no sea solo admin o 1-2-3-Q-W-E? Tomar esas precauciones ayuda mucho. Pero no creo que haya algo especial que debas considerar con Node y Docker. Mm-hmm, genial.

La siguiente pregunta es de Koniki. ¿Existen herramientas para prevenir ataques desde diferentes IPs? ¿Proxy o Tor? Hmm. Por supuesto, puedes agregar diferentes IPs a una lista negra, pero lo principal es asegurarte de que tu aplicación Node esté configurada de manera que no sea susceptible a ataques DDoS. Por lo tanto, si estableces límites de velocidad para asegurarte de que las personas no intenten enviar solicitudes a tu servidor todo el tiempo. Si agregas diferentes retrasos a las solicitudes, solo algo para asegurarte de que si una persona está usando una VPN o un grupo de VPNs, no importa cuánto intenten atacar, no podrán superar las barreras que has establecido. Eso ya está bloqueado en esa plataforma. Bueno, eso es inteligente. Espero que Konniki esté de acuerdo. Y si no, entonces él o ella puede unirse a ti en tu sala de ponentes para discutir esto más a fondo. Eso es todo por ahora en cuanto a las preguntas. Oh, veo que la gente ya está compartiendo los enlaces que estoy solicitando. Así que estás libre. Ya se compartió un Wireshark y una cabra de Node.js. Así que muchas gracias a las personas por compartir estos enlaces con la comunidad. Eso es todo por las preguntas en este momento. Así que te liberaré de tus deberes por ahora e invitaré a las personas que quieran hacerte más preguntas a ir a tu sala de ponentes. Muy bien. Ha sido un placer tenerte, Melissa. Gracias por unirte. Sí, gracias por tenerme. ♪♪