Desde la Cripta al Código: Seguridad Web Explorada a Través de Películas de Terror

No es la primera vez, como la primera vez en los Estados Unidos, la primera vez dando una charla en el Planetarium. ¿Qué tan genial es eso? Y puedo compartirlo con todos ustedes. Así que esto es simplemente maravilloso.

Pero aunque tener un tono maravilloso en esta charla es un poco difícil porque aunque Halloween ha terminado, hay algunas cosas espeluznantes, cosas aterradoras, temores, pesadillas que aún están ahí, que no desaparecerán solo porque Halloween ha terminado, ¿verdad? Así que no tengan miedo. Estamos juntos en esto. Están aquí conmigo en mi primera vez en el Planetarium. Así que son mis compañeros. Y déjenme llevarlos en un viaje desde la cripta hasta el código para explorar la seguridad web para películas de terror.

Y antes de comenzar rápidamente, tendré dos pequeños avisos para ustedes. El primero será una leve alerta de spoiler porque, por supuesto, si intento enseñar seguridad web para películas de terror, podría necesitar tocar la trama de alguna película de terror. Así que no se preocupen. No les arruinaré las películas completas. Pero me aseguraré de que entiendan de qué estoy hablando. Aunque, incluso cuando las películas de terror no sean de su agrado. Y el otro, por supuesto, las tramas de películas de terror a veces no son tan amigables por decirlo de esa manera. Así que intentaré ser lo más amable e inofensivo posible cuando se trate de mi redacción. Pero si me equivoco a veces, por favor tengan paciencia conmigo porque las películas de terror a veces son intensas. Y sí, podría mencionar algunos puntos de la trama. Así que una leve advertencia de contenido solo para que lo sepan.

Bueno, no sé si puedo ver a la audiencia tan bien. Pero tal vez pueda tener algo de luz porque tengo una pregunta para ustedes. Si ves películas o Halloween o básicamente películas de terror durante todo el año, ¿alguna vez escuchaste esta cita, "I'll be right back"? Y una persona se va. Sí, me alegra no estar solo. Espero que al menos estén un poco molestos porque si veo esto, realmente me molesta porque ¿por qué deberías separarte en absoluto? Es un mal presagio. No hagas esto. No hagas esto en películas de terror. Es tan famoso. Se convirtió en un meme y supongo que eso te dice todo sobre este plan inteligente de separarse. ¿Verdad?

Hay muchas personas en películas de terror tomando decisiones extrañas o incluso estúpidas. Y estamos justo detrás de nuestro televisor diciendo como, ja-ja, yo lo haría mejor. Pero realmente, realmente espero que nunca te encuentres en una situación como de película de terror. Pero no necesitamos ir tan lejos porque hay situaciones aterradoras e importantes en nuestra vida diaria como desarrollador de software, que pueden convertirse en una película de terror. ¿Verdad? Sí.

Creo que hay muchos paralelismos entre la seguridad web, los problemas de seguridad y las películas de terror. No solo personas haciendo cosas extrañas, no escuchan las advertencias, incluso si son claras y están justo en su cara, cosas así. Así que, por supuesto, no son completamente iguales. Pero hay muchos paralelismos que descubriremos más adelante. E incluso puntos polares completos de películas de terror, reflejando incidentes completos, lo cual es realmente genial. Estos títulos aquí son, algunos podrían sonar como películas pero no lo son. Son tomados de los medios porque estos son problemas de seguridad reales. Y son bastante famosos y bastante peligrosos. Por ejemplo, Heartbleed es una vulnerabilidad en el popular OpenSSL, ¿verdad? Así que, sí, están aquí. Son reales y causan mucho daño.

Pero hay algo positivo, que es que están en el mundo real, lo que nos ayudará en escenarios de terror también, así como ayuda a las personas en las películas de terror. El maravilloso profesor amigable, un equipo, un nerd, un grupo de personas, personas útiles y capaces ayudando al protagonista a sobrevivir. Como este profesor que intenté dibujar por la película Sinister. No sé si lo logré, pero entiendes el punto. Así que hay muchas personas ayudándonos, ya sea dentro de una película de terror o en el mundo real.

Bien. Supongo que nunca se lo dices a nadie. {{^}}Bien. El equipo que nos ayudará se llama OWASP. OWASP es el término corto para Open Worldwide Application Security Project, y es un grupo de personas que tienen como objetivo aumentar la seguridad en la web. Así que están tratando de empujarnos a saber cuáles son los riesgos más peligrosos en la web. Y hacen un ranking, o supongo que cada cuatro años? No está mal. Así que el ranking de los riesgos de seguridad más importantes a tener en cuenta. Y supongo que el último ranking fue en 2021, si no me equivoco. Y los usé como base, porque son realmente útiles, para elaborar nuestro manual de supervivencia de seguridad. Al igual que otras películas de terror un poco irónicas como Scream o Zombieland lo hacen, tratando de darnos raíces a las que adherirnos si estamos dentro de una situación de película de terror.

Así que bien. No queda mucho por hablar. Vamos a entrar en la primera película de terror. Bien. Esta es la primera. Y al menos la película original es la más antigua. Es de 1933, supongo. Pero hubo un remake en 2020. Es sobre el hombre invisible. Y como el título ya te dijo, se trata de Griffin, que es un científico haciendo un experimento y fallando miserablemente y resultando ser invisible. Al principio quiere esconderse porque es una mala condición, ¿verdad? Si nadie puede verte. Pero por supuesto, la invisibilidad tiene algunas ventajas. Así que rápidamente hace uso de ella. Primero haciendo bromas, pero luego siendo tentado a cometer crímenes o incluso peores cosas como asesinato. Así que no es tan amable con otras personas, ¿verdad? Así que sí. Este es el resumen rápido de la trama, básicamente. Y creo que esta trama es una maravillosa alegoría, un ejemplo maravilloso del riesgo más importante para nosotros. Esto se llama control de acceso roto.

El control de acceso generalmente significa que un usuario no puede actuar fuera de sus permisos previstos. Y una falla obviamente significa que un usuario es perfectamente capaz de hacerlo, como un hombre invisible que no puede ser visto y puede hacer lo que quiera. Así que sí. Esto puede llevar a muchas cosas, como la divulgación no autorizada de información, personas que pueden modificar cosas que no deberían poder, o incluso distracciones. Sí. Estoy mirando a ti, curso, o tomé una manipulación. Esto podría suceder.

Así que bien. Vamos a profundizar un poco más en los paralelismos. La invisibilidad puede insinuar acceso no autorizado. Porque un atacante puede operar sin ser visto, como puede Griffin. Pueden entrar, no serán vistos, pueden destrozar Harvard, leer cosas, acceder a datos sensibles, cosas así. Y como Griffin hizo al cometer crímenes y cosas. Es abuso del poder de la incapacidad. O en términos de seguridad, abuso de poder más allá de lo que debería permitirse. Bastante buen paralelo.

Otro es una falsa sensación de seguridad. Si puedes ver a un perpetrador, te sientes seguro, ¿verdad? Porque no hay nada. Y esas personas que no se ven, ya sea un hombre invisible o un atacante, no pueden ser detenidas. Porque los guardias y las cerraduras no pueden detener lo que no pueden detectar, ¿verdad? Bastante malo. Así que un acceso mal implementado puede llevar a una falsa sensación de seguridad. Y aún peor, si no lo bloqueas, no puedes saber que hay una brecha, tal vez. Y por último, pero no menos importante, un atacante invisible no dejará rastros. Como se dijo, cuando se trata de sin bloqueo púrpura, no pasa nada. Puedes explotar tus datos. Y tienes un desastre.

Entonces, ¿qué podemos hacer para sobrevivir al hombre invisible? ¿O al control de acceso roto? Tu modo de operación por defecto debería ser negar por defecto. Si tienes, por ejemplo, un usuario por defecto sin ninguna asignación, por ejemplo, no deberían poder hacer nada, a menos que el usuario o el punto final sea un recurso público. Deberías intentar minimizar el daño usando limitadores de tasa en tu API y en tus controladores. Así que si las personas pueden hacer más de lo que pretendían hacer, es solo un área pequeña de daño.

Si tienes identificadores de sesión con estado, deberías invalidarlos regularmente. Tan pronto como sea posible y cuanto más rápido, mejor. Cuando pienso en un token JWT, deberías tenerlos de corta duración. Y si no es posible, quieres tener más conveniencia para tu usuario, intenta pensar en usar el estándar OAuth. Esto hace que la ventana de ataque sea un poco más pequeña. Por último, pero no menos importante, puedes pensar en implementar y reutilizar mecanismos de control de acceso. Y hay muchos que podrías considerar. Esto puede llevar a minimizar costos, sin compartir en otras cosas. Una pequeña recomendación que quiero mencionar aquí rápidamente es OpenFGA, que está inspirado en Google Sansibar, un control de acceso basado en reglas, pero también tiene algunos casos de uso de RBAC y ABAC. Y es de código abierto, lo cual me gusta mucho. Y hasta donde sé, es un proyecto de la Cloud Native Computing Foundation. Así que es una fuente confiable en la que puedes confiar.

Bien. ¿Estás listo para la segunda película? Whoo-hoo. Bueno, no estaría tan feliz de ver a este tipo, ¿verdad? Estoy hablando de Hellraiser. Es una película de 1987. ¿Perdón? Pinhead es bastante famoso, creo. Pero la trama, y especialmente para la seguridad, quiero echar un vistazo más de cerca a cierta caja que tienen, la caja de rompecabezas, que es básicamente la configuración Norman.

En la película, hay una persona, creo que se llama Peter o Frank, Frank, creo que Frank era su nombre. Está encontrando esta caja y básicamente la está resolviendo. La cuestión es que si resuelves el rompecabezas, abrirás una puerta al reino infernal de los Cenobites. Y los Cenobites no son tan amigables. No vienen solo a cenar o a tomar una taza de té o algo así. Quieren cazar personas para experimentar. Y supongo que nadie estaba dispuesto a ser un conejillo de indias, ¿verdad? Y hay una mujer, la amante de Frank, creo, que intenta resucitarlo, quien resolvió el rompecabezas y se convirtió en víctima.

Esta película es una maravillosa alegoría sobre los fallos criptográficos. Así que básicamente todos los fallos relacionados con la criptografía, toda la falta de ella. Este punto antes, cuando se trata de toda la sobreexposición, anteriormente se conocía como exposición de datos sensibles, que es el síntoma más prominente. Pero como no es la causa, lo renombraron. La película Peril, como ya se insinuó, alude a esta caja de rompecabezas, a la configuración LEMON, siendo un sistema de cifrado que es fácil o más fácil de romper. Los Cenobites son las consecuencias del fallo. Así que vendrán y te perseguirán porque tienen tus datos, por ejemplo, o pudieron acceder a ellos. Y la resurrección de Frank, es una recuperación de datos fallida. Así que incluso si intentas recuperar tus medidas, nunca puedes saber si todo está en orden, ¿verdad?

Bien, ¿cómo podemos sobrevivir a un problema de seguridad tipo hell-wager? Lo primero es cifrar todos los datos sensibles. Bastante fácil, ¿verdad? Usa algoritmos de cifrado y sé realmente cuidadoso y completamente consistente. Intenta clasificar los datos que procesas, almacenas o transmites. Porque de esta manera puedes identificar qué datos son sensibles. No deberías almacenar datos sensibles innecesariamente, así que descártalos si ya no están en uso. Usa PCI DS como tokenización de componentes o concrétalo, y como dije, descártalo tan pronto como lo necesites. Ya no lo necesitas.

El punto que me gustaría que tuvieras en tu caja de herramientas es que intentes no almacenar en caché respuestas sensibles. Porque si no están en caché, nadie puede tomarlas, ¿verdad? Y por último, pero no menos importante, utiliza protocolos seguros, fuertes y actualizados como TLS e intenta evitar FTP o SMTP porque son un poco antiguos.

Bien. Bien. Ahora llegamos a mi alegoría favorita. No pude resistirme a incluirla aunque la película es un poco explícita para decirlo de alguna manera. Supongo que ya la viste alguna vez o has oído hablar de ella. Está en Alien. Es una película, supongo. Su original, la primera parte, fue en 1988, y trata sobre la tripulación de una nave espacial que investiga una nave espacial abandonada. Fueron un poco demasiado curiosos, supongo. Lo que los llevó a ser cazados por una criatura extraterrestre mortal llamada Xenomorph. Y sí, el aviso está en su lugar. La trama es explícita. Intenté cuidar mi redacción.

Si no, lo siento. Lo que los hizo un poco curiosos fue este pequeño amigo lindo que solo quiere abrazar a la gente. Supongo que si no estás dispuesto a llevarte un recuerdo especial, deberías abstenerte, supongo, a diferencia de la tripulación, que no fue tan cuidadosa. Exploraron un poco demasiado y trajeron de vuelta un pequeño recuerdo. Creo que Alien es un maravilloso ejemplo de alegoría sobre la inyección porque, sí, el abrazacaras, hace que las personas sean anfitrionas. Podría ser un maravilloso ejemplo de omisión de validación de entrada y la penetración inicial del sistema si un atacante logra que su código se implemente o compile dentro de tu programa. Si fuiste abrazado por el abrazacaras, la inyección de código tiene lugar.

Si fuiste abrazado por el face hugger, la inyección de código tiene lugar. Solo mencionaré el nombre chestburster. Las personas que vieron la película saben de qué estoy hablando. Cuando te conviertes en anfitrión, hay un alienígena adherido a ti. En algún momento, el alienígena es lo suficientemente grande como para vivir por sí mismo. No entro en detalles, pero tal vez puedas ver de qué estoy hablando. Porque el alienígena dejará al anfitrión. Y este es un maravilloso ejemplo de ejecución de código y compromiso del sistema, porque el alienígena está fuera. Puede causar estragos, ¿verdad?

Hola ahí. No te hemos visto más. Y supongo que no es tan amigable como el face hugger, ¿verdad? Como un acceso completo al sistema. Y el consumo de recursos, también podría ser. Así que sí, creo que Alien es perfecto para explicar la inyección. Y este es el tercer lugar en el ranking. Así que realmente importante, especialmente para nosotros los desarrolladores frontend.

Entonces, ¿qué podemos hacer? Deberíamos usar solo fuentes confiables, una API segura, que tal vez incluso evite intérpretes o ORMs. Así que hay vectores de inyección menos grandes, por así decirlo. Deberíamos intentar pensar en la validación de entrada del lado del servidor. Deberíamos usar características de SQL como limit u otros controles para que no haya tantos datos que ingresen a un compilador y escapen caracteres especiales. Y sé, sí, necesitamos tener cuidado cuando se trata de estructuras SQL, porque los nombres de estructuras proporcionados por el usuario podrían ser peligrosos y podrían romper algunas cosas. Así que debería ser una combinación de todas esas medidas. Lo más importante es el saneamiento. Este es un ejemplo simplificado que se me ocurrió para básicamente referirlo de nuevo a Alien, ¿verdad? Es como una defensa contra la inyección, que básicamente está haciendo tiempo actual y decombination. Así que tendremos un punto, esta declaración if, donde intentamos detectar patrones o anfitriones. Y lanzaremos un error si vemos algunos, por lo que la entrada se descarta. Y si no, haremos una decombination, como intentar desechar todos los caracteres especiales que tenemos. Podemos hacerlo con bibliotecas. Podemos construirlo por nuestra cuenta. Podemos hacer una combinación de ambos, que es lo que estoy haciendo aquí. Como usar DOM purifier para tener un saneamiento HTML, pensando en un saneamiento SQL con la advertencia de estos nombres de usuario.

Y una inyección de comandos. Me gusta usar Regex para eso. Tengo un pequeño resumen, pero como no tenemos mucho tiempo, espero que puedan tomar una foto o compartiré mis diapositivas después para que puedan simplemente verlas. Pero puedes atrapar cosas como XSS, cosas como etiquetas de script, inyecciones de SQL, comandos, y incluso más.

Bien. Avancemos rápido por el tiempo, porque tengo un rango más, que no está en el rango 4. Pero en mi opinión, es realmente importante. Y quiero presentártelo con esta pequeña película. Se llama The Blob. Es de 1958. Y es nuevamente un alienígena, pero hace cosas diferentes a un xenomorfo. Y se estrella en la tierra. Y es como un gran, no sé cómo llamarlo, blob, cosa. No sé cómo describirlo, pero puedes verlo en este póster. Está creciendo porque consume cosas y seres vivos y se hace más grande, más grande, más grande. Se vuelve más rojo, agresivo y más grande. Y esto es malo, ¿verdad?

Es mi alegoría favorita sobre dependencias vulnerables y obsoletas. Un gran blob de deuda técnica. Un gran blob de dependencias que no sabes por qué las elegiste. No sabes cuándo las actualizaste por última vez. Y sí, se vuelve más y más grande y aterrador y difícil de probar y difícil de arreglar. El paralelo obvio es el crecimiento del blob, que son las dependencias o la deuda técnica. El consumo de las víctimas por el blob es cómo las vulnerabilidades y como la deuda técnica podrían extenderse a aún más problemas o riesgos de seguridad potenciales. Porque tal vez te perdiste una corrección de seguridad, ¿verdad? Y el crecimiento es imparable del blob, como cuando se trata de dependencias no gestionadas.

Así que sí. ¿Qué puedes hacer? Seré un poco más rápido ahora. Deberías eliminar todas las dependencias que ya no necesitas. Deberías tener un inventario de todos los números de versión. O al menos intentar seguir las redes sociales o los registros de cambios para saber si hay más actualizaciones. Deberías intentar obtener todos tus paquetes de fuentes confiables y enlaces seguros y no solo de cualquier lugar en internet.

Y trata de monitorear si tienes bibliotecas en su lugar o herramientas que ya no se mantienen. Porque si no se mantiene, por supuesto, no obtendrás correcciones de seguridad. Y por último, pero no menos importante, nunca ignores dependabot. Siempre actualiza tus dependencias.

Aquí hay algunos scripts que podrías considerar, como hacer el script de auditoría, que básicamente pedirá un informe de vulnerabilidades conocidas. Puedes solucionarlo, cosas desactualizadas. Si algo está desactualizado, podrías usar SNICK, que es una herramienta útil para probar y tener para problemas de seguridad. Y básicamente actualizas de forma segura. Esto es NPM check updates, ayudándote a actualizar todos tus paquetes y dependencias a las últimas versiones.

Hay una nueva ramificación de OS que viene el próximo año. Hasta donde sé, están recopilando nuevos datos ahora mismo. Así que noviembre, diciembre de este año. Bien.

Ahora voy a cerrar. Permíteme resumirlo con reglas generales de películas de terror de seguridad. Como pantalla, básicamente. Primero, mantente junto como equipo. No te separes. Ni siquiera si piensas que es un trato astuto. Para el desarrollo, no te sientas solo. Aborda los problemas con las comunidades. No tengas miedo de pedir ayuda. Y todos estamos juntos en esto cuando se trata de combatir problemas de seguridad. Cuida tus baterías.

En una película de terror, no es tan bueno tener una linterna vacía o una batería de teléfono vacía, solo pregunta a tus herramientas. Intenta verificar si están actualizadas, si hay un nuevo problema de seguridad o un parche, y simplemente ten un maravilloso jardín de herramientas y cuídalo. Verifica dos veces si el asesino realmente ha sido derrotado. Así que en una película de terror, a veces la gente no verifica si el asesino está muerto. Y luego están súper sorprendidos de que esté resurgiendo. Lo mismo con tu código.

Revisa tu inicio de sesión, prueba tu código, prueba tus correcciones y verifica si realmente está hecho. Y por último, pero no menos importante, toma en serio tus consejos. Si hay una advertencia, podría haber una razón para ello, especialmente si es clara y está justo frente a ti.

Bien. Bueno, muchas gracias por estar conmigo como compañero en mi viaje a través de películas de terror. Me hizo mucho menos miedo. Mi nombre es Ramona, trabajo como defensora de desarrolladores para Auth0, y espero verte en un momento.

Muchas gracias por escuchar.

Bien. Así que tenemos algunas preguntas aquí para ti. Por favor. Alguien está preguntando, ¿cómo te proteges contra la ingeniería social? Esa es una buena pregunta. ¿Es esto virtualmente imposible? Bueno, por supuesto, podrías verificar si hay algunas herramientas en el mercado para ayudarte, pero por supuesto la gente es gente, ¿verdad? Aconsejaría pensar, por ejemplo, por supuesto es otra discusión si es efectivo o eficiente o no, pero siempre podrías optar por pruebas de extremo a extremo, imitando a un usuario. Así que tal vez sea una buena idea. Hay algunas herramientas de prueba de IA por ahí, eso podría ser una idea. Y algunas predicen cosas. Olvidé el nombre, lo buscaré, pero estas son las cosas espontáneas que revisaría. Pero por supuesto, la gente es gente. La gente a veces no es racional. Incluso yo mismo, no siempre soy racional, así que siempre hay un poco de incertidumbre en ello.

Sí, definitivamente. Definitivamente he caído en esos intentos de phishing internos. Hace que sea aún más importante capacitar a las personas y educarlas.

Oh, wow. La siguiente es una pregunta popular, y es, ¿cuál es tu película de terror favorita? Ooh, esa es interesante. Bueno, me encantan las películas de A24. Así que si te gustan las películas de terror psicológico, échales un vistazo. No soy tan fanático de Splatter o Gore, porque creo que no tienen mejores argumentos para ser impactantes. Así que tal vez Hereditary o Midsommar. Oh, esas son realmente buenas. Amo A24 y lo que hacen. Mi primera película de terror fue The Ring. ¿Oh sí? Definitivamente tengo que verla.

Bien, la siguiente es de Matt. ¿Cuál fue la herramienta de código abierto que recomiendas para el control de acceso? Se llama OpenFGA. De hecho, olvidé incluir un código QR, así que solo busca OpenFGA, o supongo que lo agregaré rápidamente a mis diapositivas cuando las comparta. Oh sí, suena bien.

Gracias por hacer eso.

Bien, tenemos preguntas de alguien anónimo. Espeluznante. ¿Cómo pruebas que algo es seguro? Bueno, hay algunas herramientas. Supongo que se llama ZAP de Ovaas, que podrías echar un vistazo. No estoy tan seguro de cuántas versiones de código abierto hay afuera, pero definitivamente hay algunas herramientas de pago. Y de hecho vi un Cypress Hybrid con ZAP. Es bastante antiguo. Con suerte, tal vez pueda encontrar algo de tiempo para intentar actualizarlo o cualquier otra persona en la comunidad de código abierto. Combinar la automatización de pruebas es una buena idea, porque con suerte ya he tenido algunas pruebas.

Sí, ¿fue eso un llamado a la acción para que las personas aquí lo actualicen? Oh sí, hagan sus pruebas, por favor. Suena bien.

Bueno, eso es todo el tiempo que tenemos. Qué charla tan encantadora. Encantadora como en espeluznante, supongo que eso es un cumplido para la charla. Muchas gracias.

Sí, gracias por tu tiempo. Y puedes encontrar a Ramona afuera, ¿o tienes una sala de discusión próximamente? ¿Es correcto? No, no hay sala de discusión. Así que deberías encontrarme en el Q&A.

Bien. Cada sala con Ramona será una sala de discusión. Así que está bien. Gracias. Muchas gracias.