Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
el 98 % de los ataques, y de nuevo, esto es un número que yo estoy mencionando, digamos lo por ahí, ¿no? 98.7, los ataques que se dan en internet son por bots, son por robots.
Juan (00:05)
98.7
Douglas (00:16)
Y los tips que Juan nos está dando hoy y los que dimos la semana pasada, si implementamos eso, nos quitamos de encima ese...
gran número 98.7 de atacantes que hay y son tips fáciles de implementar. Solamente le dedicamos un poquito de conciencia, un poquito de mente lo que dimos la semana pasada con respecto a infraestructura, lo que Juan nos dio hoy con respecto a código, ya nos dijo Juan, ya hay librerías, ya hay frameworks que lo hacen, solo asegurémonos que está ahí. eso nos quitamos la gran, gran, gran mayoría de ataques.
e intentos de ataques que pasan todos los días en
Juan (00:58)
Bienvenidos sean todos a un nuevo episodio de nuestro podcast Dev & Ops. El día de hoy me acompaña mi buen amigo Douglas para hablar de un tema muy interesante que creo que va a ser muy útil para todos. Es un tema que va a ser una continuación de un episodio anterior. Douglas, ¿cómo has estado? ¿Qué me contas de nuevo?
Douglas (01:17)
Juan, ¿qué tal? Pues yo estoy bien siempre, por gracias a Dios. Pues no mucho nuevo, realmente siempre buscando mejorar en el trabajo, en los proyectos personales, en la vida familiar y por supuesto en la vida espiritual. Pero más allá de eso, también contento de tener estas conversaciones y un poco emocionado de escuchar los tips que nos vas a compartir vos hoy.
Juan (01:45)
que bueno, se dice que las personas necesitamos mejorar tres aspectos lo cual es lo profesional, emocional y lo espiritual que bueno que lo estás haciendo en mi caso sí, bueno, sí, a veces es más difícil, a veces es más fácil depende del momento de cada quien
Douglas (02:00)
o intentando, ¿no?
Juan (02:07)
Para el día de hoy tenemos unos cuantos tips, tengo unos cuantos por aquí, para algunas personas estoy seguro que algunos tips van a ser muy conocidos, para otros tal vez no. La idea aquí es ir compartiendo un poco diferentes consejos que tenemos por ahí para que puedan ir asegurando su página web, ⁓ su aplicación web.
para que no tengamos ciertos, como decíamos en el episodio anterior, para ponérsela más difícil a todos aquellos criminales que quieren atacarnos. Así que bien, vamos a iniciar con el primer tip, un tip muy simple pero muy efectivo Douglas. El primero sería validar lo que son los inputs y también los outputs de nuestra aplicación. ¿Y qué significa esto?
Bueno básicamente cuando tenemos formularios en nuestra aplicación cuando tenemos un sitio web que es interactivo donde podemos llenar formularios o seleccionar diferentes opciones de menú de mucho tipo pues es importante número uno limitar la cantidad de texto que puede ingresar un usuario por ejemplo si un usuario tiene que poner su dirección
pues hoy en día existen muchas maneras para evitar que el usuario escriba, podríamos ponerle que elija una parte del mapa utilizando los APIs de Google Maps o cualquiera como estos o algo más simple sería con drop downs, vamos eligiendo el país, el estado, la provincia, la ciudad y todo eso ¿por qué lo hacemos de esa manera? porque queremos evitar, número uno, que las personas se equivoquen al momento de escribir el
texto y tengamos en nuestra base de datos, perdón, Estados Unidos, otras personas van a escribir United States, otras personas van a escribir USA y bueno se hace un solo relajo.
Pero también otro motivo es para evitar que las personas ingresen código malicioso. Y ya vamos a hablar un poquito más adelante sobre este tipo de ataques que se pueden dar. Pero la idea es evitar que las personas ingresen código que esté malo y que sea perjudicial para nosotros. Así que por eso tenemos que validar todo el tipo de texto que estamos recibiendo. Hoy en día hay muchas librerías Douglas que te permiten
validar ya sea el formato de lo que estás esperando y también escapar el texto. Escapar el texto básicamente es quitarle todos aquellos caracteres que pueden significar que se está ejecutando un código malicioso. Eso es lo más, vamos a decirlo, lo más básico entre comillas, es lo que siempre se habla, pero también algo que muchas veces pasamos por alto es el hecho de también limitar la cantidad de texto
que estamos devolviendo. Cuando en una base de datos estamos haciendo búsquedas, por ejemplo el usuario pidió una lista de, que se yo, vamos a decir, miembros de su equipo. Quiero ver todos los miembros de mi equipo en una aplicación. Bien, pues los podemos ir a buscar a la base de datos y devolvérselo. Pero hay que revisar si realmente es importante que le devolvamos el ID.
hay que ver si es importante qué información no deberíamos devolver y bueno en esencia es básicamente quitar todo lo que no sea esencial y enviar solamente lo que realmente necesita
Esto es muy útil y muy fácil cuando nosotros estamos haciendo todo Douglas, cuando estamos haciendo el endpoint y estamos haciendo los queries directamente, porque a veces estamos utilizando servicios de terceros y pues ahí ya nos envían prácticamente toda la información. Pero cuando se puede eviten enviar todo lo que viene de la base de datos. Hay que buscar enviar solamente la información que necesitamos y así evitamos que los atacantes
tengan información extra que puede darles pistas de cómo atacarnos o cómo encontrar información de los otros usuarios y eso nos puede perjudicar a la larga. Entonces evitar ese tipo de cosas. Así que ese sería el primer punto Douglas, con ese vamos a arrancar el básicamente validar los inputs y los outputs.
Douglas (06:45)
Sí, y fíjate Juan, que los formularios desde mi perspectiva como CISAD, MINU SRE, han sido de los dolores de cabeza más grande que hemos tenido con respecto a vulnerabilidades en sitios, en sistemas.
Juan (06:54)
jajaja
Douglas (06:59)
con respecto a mantener el PCI compliance que hablaba yo el episodio anterior, ¿no? De tantas maneras y tan fácil de vulnerar cuando alguien, cuando un desarrollador solamente agrega los inputs, agrega el botón de Submit y listo, ¿verdad? Es de SQL Injections porque por supuesto, como ya nos explicabas, ¿no? Esos valores cuando es un formulario de Submit, de subir contenido de información,
Juan (07:02)
Ok.
Sí.
Douglas (07:29)
ese contenido va a ir a una base de datos. Entonces si acepta cualquier cosa se puede inyectar a la base de datos código SQL que puede ser dañino. Ya sea para destruir o dañar información o para exponerla. Otra recuerdo yo que vi esto pasar es cuando se acepta un formulario subir archivos.
Porque entonces subís un Simlink, para los que no sepan que es un Simlink en Linux, es como un acceso directo, como un shortcut que conocemos en Windows, que haces un shortcut en tu escritorio para accesar tus aplicaciones favoritas, un acceso directo. Ese es equivalente en Linux, entonces se sube un Simlink a archivos críticos del sistema, uno de ellos en Linux es el de donde están los usuarios, que están en PlayKTC, PlayK Pass, WD.
Y entonces la gente sube el archivo y luego desde el administrador me permite bajar archivos que he subido y entonces cuando lo bajan...
están bajando ahora el archivo real con los usuarios y passwords, aunque están en hash. Eso ya es fácil tratar de comprobar esos hash contra una base de datos de hash que están en internet, ¿verdad? Entonces eso es tan fácil y tan vulnerable, ha sido de los dólares de cabeza más grandes. Y lo que está diciendo es de lo primordial, de lo primero que yo hablo con developers cuando miro que la aplicación que están lanzando, que están publicando, incluye un formulario.
están validando los datos, están validando por SQL Injection, están agregando el CAPTCHA. A mí me gusta mucho el CAPTCHA que tiene Cloudflare.
El servicio se llama TurnStyle, algo así, bien raro el nombre. Pero ellos te reemplazan el Captcha por el Captcha que Cloudflare te muestra en la página de ellos. Y es bien fácil, es bien simple, me gusta mucho, porque ocupas agregarle una protección de ese tipo a los formularios, porque si no, hay bots que te llenan la base de datos con contenido basura, ¿verdad?, en tus formularios. Entonces, ese tip que está dando, yo le doy mi thumbs up también, porque
Juan (09:17)
sí, sí, sí.
Douglas (09:36)
que desde el lado de Systems Engineering ha sido un dolor de cabeza grande.
Juan (09:42)
sí definitivamente es
Bueno es que cuando tenemos un punto de entrada, un punto donde los usuarios pueden interactuar con nosotros y ese va a ser el punto más fácil donde la gente va a querer buscar cualquier vulnerabilidad que encontremos, ¿no? De hecho recuerdo que hace mucho tiempo habían ciertas páginas que te instruían a ser hacker, ¿no? Te daban muchos tips y te daban muchas herramientas y bueno, te instruían, ¿no? Y había muchos challenges que eran de ese
donde te decían bueno anda a una página, revisa el formulario de contacto, el formulario de login, intenta hacer algo, intenta hacer una inyección SQL o intentar revisar el código. La gente se sorprendería la cantidad de comentarios que hay en una página web que nos pueden dar mucha información. Hoy en día es un poco se ha minorado esto y con la llegada de diferentes frameworks para el front-end
este tipo de problemas ha decaído gracias a dios porque pues ahora los mismos frameworks al momento de hacer el build de la aplicación y construyen todo y te generan ya el código final pues quitan muchas cosas quitan comentarios quitan todo o buscan el código pero antes no teníamos eso antes era más difícil si querías minificar el código pues tenías que buscar ciertos servicios extra y bueno era todo un tema
así que antes se podía encontrar ese tipo de cosas y hoy en día ya no está eso pero hay otras vulnerabilidades no sé si te diste cuenta Douglas que hace poco no sé si fue la página la App Store de Apple tuvo un problemita por ahí y es que ellos subieron lo que se le llama los
Ups, olvidé el nombre. Ya hace tiempo que no programo del lado del frontend, pero ¿son los mapas? Si no me equivoco. Básicamente cuando publicamos a producción con estos frameworks, podemos agregar código extra donde tenemos el código tal cual como lo tenemos en nuestro source code y se va a producción. Esto es muy útil porque nos permite revisar cuando está sucediendo algún bug, nos permite revisar qué función es la que está fallando y la lógica de
obviamente al final del día todo lo que está en frontend es visible a los usuarios pero lo ideal es no lanzar esto porque pues tenemos todo el código como viene y bueno se hizo esto en la página de la app store y mucha gente logró identificar muchas cosas enlaces a repositorios internos enlaces a diferentes partes del código que obviamente no querían que saliera la luz
que utilizan ellos, servicios de terceros, que tal como dije se puede encontrar en el código como tal pero los mapas realmente olvido el nombre como cuál es el nombre correcto, Source Maps si no me equivoco incluyen comentarios y como dije los comentarios incluyen mucha información que es muy muy útil pero bueno idealmente no nos va pasar eso a nosotros si le pasó a apple pero a nosotros no nos va a pasar ⁓
bien, tip, otro punto de hecho antes de eso estaba recordando Douglas en lo que estabas hablando sobre los Sim Links no suele ser responsabilidad del developer pero hay ocasiones donde si lo es
y es que a veces nos toca asignar los permisos a diferentes directorios dentro de nuestra aplicación y esos directorios están dentro del servidor. Cuando está en un ambiente dockerizado, contenerizado, probablemente no sea tanto problema, pero como dije, hay ocasiones donde vamos a tener que hacer ese tipo de cosas.
y ahí yo les diría tengan precaución extra con el tipo de permisos que le asignamos a los directorios. Con los tipos de permiso me refiero a que en Linux podemos darle permiso a un grupo de usuarios, un permiso solo para el usuario que es dueño del archivo o los permisos 777 que es a todos.
y a veces es muy fácil dejar todo con permiso 777 de hecho casualmente hoy, hoy en la tarde estuve limpiando muchos directorios en mi HomeLab que pues debido a diferentes pruebas que he hecho los he dejado así idealmente no pasaría nada dentro de mi red pero pues como para ir practicando las buenas prácticas lo he ido mejorando y bueno como dije normalmente no es responsabilidad de los developers pero si en algún momento
se vean involucrados tengan precaución extra. Estoy seguro que en tu caso has visto muchos problemitas como esto, dudas de permisos que no deberían.
Douglas (14:47)
Sí, fíjate que sí, y créeme que problemas serios, para agregar al comentario que acabas de hacer, mí me gustó algo que vos dijiste en el episodio anterior, que es que la seguridad es un trabajo en conjunto con los diferentes departamentos, y lo que decís en efecto normalmente no es el programador el que va asignar permisos a los directorios, a los archivos, pero deberían de sugerir, mira, este es un directorio crítico, dale permiso solo a tal
al usuario o este archivo se va publicar pero que no se exponga.
por el web server, solo es un archivo de configuración. Ese trabajo en colaboración de la misma manera que yo te acabo de mencionar que los formularios han sido un dolor de cabeza y cuando yo miro que se va publicar un formulario, yo voy al developer y hago estas preguntas. ¿Hiciste validación? ¿Le agregaste scatcha? Y empiezo a hacer ese trabajo y ahí se encuentra que a veces dicen, fíjate que no lo hice, mira ve, agregalo antes de publicarlo. Y empieza esa colaboración, ¿no? ¿Vos dijiste ese comentario? ¿Vos hiciste ese comentario?
Juan (15:46)
Sí.
Douglas (15:51)
perdón y a mí me gustó mucho entonces lo voy a hacer eco ahorita es cierto que probablemente el programador no va a ser responsable de asignar los permisos sin embargo involucrense en eso háganle la sugerencia o háganle la petición de ser necesario a su sysadmin a su sre de los diferentes directorios y qué permisos sugieren que tenga
porque por el otro lado lo que decís las experiencias malas que tenido con permisos han sido situaciones donde programadores han definido sus permisos y de hecho yo ya lo comenté en un episodio anterior pero mi primera experiencia con WordPress fue que un programador lo instaló con permisos 777 y entonces recibió un code injection
Juan (16:38)
Ok,
ok.
Douglas (16:39)
Y se llenó de publicidad de un medicamento para hombres adultos y se llenó de redirects y publicidad de esto porque estaba totalmente expuesto entre otros escenarios. sí, trabajemos en conjunto, developers trabajemos en conjunto para definir permisos apropiados a los directorios donde va correr la aplicación.
Juan (17:04)
correcto, correcto. Bien, sí, quería mencionar eso antes de continuar. El siguiente tip que tenía, que lo tengo por acá es el de, parece muy obvio, pero he visto que muchos developers no lo hacen y hoy en día es muy muy fácil, es el de cifrar todo lo que se pueda cifrar.
toda la información sea muy sensitiva cifrarla y la primera que viene a la mente y la más común es la contraseña y de nuevo parece muy obvio y todo lo todos ya lo hemos escuchado anteriormente pero ya he visto código desde código que es de muestra código que viene por ejemplo de me ha tocado revisar código Douglas de aplicantes a la empresa y para aplicar pues tienen que hacer un ejercicio de programación
y ves que no están cifrando los datos y hoy en día es muy fácil, en día todos los lenguajes de programación tienen o ya se ha incorporado en el mismo lenguaje o ya hay librerías de terceros que nos ayudan a hacer esto de manera muy muy fácil así que definitivamente hay que cifrar todas las contraseñas pareciera que no deberíamos decir esto pero sí y con esto de los cifrados hay diferentes tipos de cifrados
Yo lo que aconsejaría es que revisemos cuál es la carga de nuestra aplicación. Normalmente un formulario de registro, el flujo del registro de un usuario no es algo que sucede a cada segundo. Es algo que sucede paulativamente, en el mejor de los casos, si nuestra aplicación está yendo bien.
así que por eso en como es algo que no está sucediendo tan constantemente podríamos tener un cifrado más fuerte y cuál es la desventaja que los cifrados más fuertes utilizan mayor cpu pero de nuevo no es algo que está sucediendo segundo a segundo lo podemos hacer ahora si es algo que estamos haciendo
que estamos cifrando información y es más rápido, se está sucediendo más constantemente pues entonces podríamos utilizar otro tipo de cifrado no recomiendo para nada utilizar cifrados que ya están desfasados por ejemplo B64 no es un cifrado es más como una ofuscación hoy en día porque B64 se puede saber qué es el contenido y luego están otros tipos de algoritmos de cifrado como el
el SHA5 creo, ya he olvidado el nombre pero hay que revisar todos los algoritmos que tenemos disponibles y no utilizar los que ya han sido vulnerados porque ya existen herramientas para identificar este cifrado, este algoritmo perdón y pues hacer la ingeniería inversa y obtener los datos
es muy engorroso a veces pero hoy en día es más fácil hoy en día ciframos los datos, guardamos el hash o sea el texto que nos generó eso es lo que se guarda en la base de datos y luego cuando el usuario quiere iniciar sesión bueno obtenemos el hash de la base de datos y ya por ejemplo en el caso de Go tiene ya una función interna el paquete de BigCrypt se llama que dice comparar hash entonces hacemos eso y listo esa es una de las de nuevo
es de las métodos de seguridad más simples que podemos implementar, sin embargo hay que hacerlo. No porque sea simple significa que no lo tenemos que hacer, hay que hacerlo. Aunque hoy en día Douglas, cuando utilizamos diferentes frameworks y diferentes librerías de terceros, muchas veces todas estas cosas ya vienen dadas.
ya ni siquiera lo pensamos pero si lo estás haciendo todo desde cero pues si hay que tener en cuenta esto y estoy seguro que hay muchas personas que hoy en día lo siguen haciendo desde cero de hecho donde estoy yo tenemos una un flujo de usuarios que es totalmente hecho in house y pues tiene todas las reglas de seguridad que te puedes imaginar pero bueno no hay que menospreciarlo sólo porque sea simple
Douglas (21:28)
Pero es eso es tan positivo como negativo. El hecho de que las librerías modernas ya hagan eso porque hay menos posibilidades que un sitio, una aplicación llegue a producción sin este tipo de seguridad. Pero a la vez es negativo porque programadores nuevos que no le dedican el tiempo de entender estos conceptos y estas cosas no saben que eso está pasando. O ni siquiera saben.
cómo asegurar o proteger una aplicación y eso al momento de que exista un error, es difícil que haga troubleshooting o es difícil que tengan ese pensamiento al momento de hacer su checklist antes de producción, asegurarme, incluir en el checklist, está encriptando, se está hachando el password del usuario, verdad, porque lo que se busca en esto y en esta parte de código, por supuesto, yo no desarrollo, pero sí sé que lo que se busca
Juan (22:13)
Mm-hmm.
Douglas (22:24)
guardar en base de datos cuando tiene que ver con contraseñas es que sea un valor que no se pueda revertir, un encriptado que no se pueda revertir que en este caso es un hash, un hash no es lo mismo que un encriptado, el encriptado se puede encriptar y desencriptar, si la palabra en español es desencriptar no lo sé.
Juan (22:32)
Correcto.
Correcto.
Douglas (22:47)
Pero, descifrar, gracias. Cifrar y descifrar. Así sería, verdad. Gracias, Juan. Sí. Entonces, con un encriptado se puede hacer eso, con un cifrado, con un hash, no. El hash se le dice un one way, hashing. Solo hacia un lado. Y se valida como vos dijiste. Cuando el usuario ingresa su contraseña, básicamente vuelve a hash y compara con hash. Eso es porque si llega un atacante, llega a tener acceso,
Juan (22:47)
descifrar.
Correcto.
Douglas (23:17)
a la base de datos, normalmente no tienen acceso a contraseñas porque son un hash. Por eso cuando han habido eventualidades donde han hackeado compañías grandes, dicen que los usuarios, los correos han sido expuestos, más no necesariamente las contraseñas porque las contraseñas están cifradas. Y también recuerdo muy bien, Juan, que hay una técnica igual, tal vez esto es no necesario con tal que se haga un hash, es lo que se requiere el TIB, ¿verdad? Pero recuerdo que también
hay una técnica donde se le agrega un salt, que es un texto adicional al hash, no solo a la palabra como tal, sino que un texto adicional, porque existen bases de datos en internet que tienen hash de palabras comunes o de passwords comunes.
verdad aunque sólo es un one way ya te dice cómo se encripta cómo se ve hachado abc123 verdad o cómo se ve hachado tu fecha de cumpleaños ya existen bases de datos como esas entonces para agregarles una seguridad más le agregan a ese hash un salt que es otra otra palabra random e incluso cómo se genera ese esos cifrados o esas palabras random ese salt es algo que tiene que ser también de una de algo que lo genere que
sea muy sólido porque si es predecible yo no sé cómo hacen los atacantes pero vos puedes generar un número random y si estás usando un método incorrecto ellos saben predecir
cuando, cuál se va a generar después, ¿verdad? Entonces hay tantas cosas que tener en cuenta y lo que yo quiero animar a los programadores es entiéndanlo, aunque ya su librería lo hace, aunque ya hay muchos conceptos que se abstraen a medida va progresando la tecnología y nosotros queremos sacarle beneficio a eso, dediquenle el tiempo a entender esa parte de la seguridad y entender eso de cómo se maneja información sensitiva, cómo se capta
Juan (24:50)
Mhmm.
Douglas (25:17)
y cómo se guarda porque realmente eso lo va a hacer destacar sobre los demás.
Juan (25:22)
si
es correcto ese es todo un tema que de hecho muchas personas hacen carrera de su vida respecto a la seguridad de los datos y los algoritmos de cifrado como mencionaba hay muchos algoritmos que con el tiempo han sido pues rotos ya los hackers ya saben cómo romper un algoritmo que ya
ya necesitamos pasar a una nueva versión de ese mismo algoritmo o a un algoritmo diferente y si lo del salt que mencionabas básicamente es que le agregas una palabra, un texto extra porque si vos utilizas el mismo algoritmo que yo utilizo y ambos ciframos la palabra océano
pues al final tendríamos, y si utilizamos el mismo salt, tendríamos muy probablemente el mismo texto. Pero si utilizamos un salt diferente, vos y yo, aunque estemos utilizando el mismo algoritmo vamos a tener un resultado diferente. Con eso mi recomendación sería que utilicen un salt lo suficientemente largo para...
para agregarlo y este salt hay que luego guardarlo de una forma segura posiblemente con por ejemplo con un manejador de contraseñas como lo que es el de AWS o un lugar donde podamos obtener este valor sin tenerlo en una notita o en una variable de entorno lo obtenemos de una forma segura
Y bueno, de nuevo, eso nos permite tener más, una mayor seguridad al momento de que estamos cifrando el texto. Yo he suelto utilizar frases, frases para los salt. Por ejemplo, parte de un poema o una frase muy extensa.
suelo utilizar eso como los salts porque entre mayor, mayor, grande, ¿cómo sería la palabra correcta? entre más extenso sea la cantidad de caracteres es más fuerte el cifrado por eso cuando estamos utilizando contraseñas para nosotros mismos utilizan contraseñas, número uno, utilizan un manejador de contraseñas y número dos que genere contraseñas lo suficientemente largas eso es la recomendación básica
Douglas (27:44)
Sí.
Sí, sí.
Juan (27:48)
Bien. ⁓
similar o siguiendo la misma línea de login y registro y todo esto otra recomendación para asegurar nuestro sitio web Douglas creo que hoy en día es casi indispensable es incorporar un multi factor authentication básicamente esto es una autenticación de dos pasos como se le dice donde aparte de nuestra contraseña tenemos que autenticarnos con una aplicación extra o con un servicio extra
recomendaría con un servicio extra, como lo que es el de Google y hay otros. Yo solo utilizo dos que tres, pero no les recomiendo por mensaje de texto porque eso es texto plano totalmente descartable. Es válido como última instancia, supongo, pero no lo recomiendo. Deberíamos utilizar un multi-factor authentication y hoy en día...
Douglas (28:44)
y correo electrónico,
¿recomendás correo electrónico?
Juan (28:47)
Correo electrónico, normalmente lo que se utiliza con correos es como un single one time password. Te genera una contraseña que recibes en tu correo y te manda un enlace. Con ese enlace te permite ingresar, pero eso se va utilizar una sola vez. Ya no es válido.
Douglas (29:05)
pero es que
también puedes hacer por correo el two factor authentication, así como por mensaje de texto, por correo.
Juan (29:10)
te permite sí,
sí, sí, sí sí también, también te permite que recibies un código es la misma dinámica, recibies un código pero por correo también se puede hacer pero creo que hoy en día también es bastante más fácil ya los servicios tienen integraciones muy fáciles que podemos incorporar en nuestros en nuestra página web por ejemplo una que yo suelo utilizar y que los sigo recomendando constantemente que es PocketBase
Este es un servicio que podemos instalar en nuestro servidor y tenemos toda una infraestructura de backend totalmente gratis. Y ya tiene módulos para multifactor authentication y es muy fácil configurarlo dando clics, dos, tres clics, ya lo tenemos.
Entonces, es indispensable tener esto hoy en día porque cada vez los usuarios se están preocupando mucho más por su seguridad. Esto es algo que a mí me agrada mucho. ⁓ me consideraría, me considero un entusiasta de la seguridad. Me gusta el hecho de que tener la posibilidad de asegurar tus datos digitales. Y veo que mucha gente lo está empezando a incorporar en su filosofía digital cada vez más. Entonces, cada vez los usuarios
estas funcionalidades si no lo estás haciendo porque da pereza o que es muy difícil posiblemente están perdiendo usuarios bien ese es un tip que podemos incorporar bastante simple bastante fácil lo podemos hacer y no requiere tanto código
El otro tip que quiero mencionar Douglas y que va relacionado con los primeros que estábamos hablando sobre los formularios y la información que se guarda es el hecho de utilizar cookies seguras. ¿Qué es una cookie segura? Es una cookie primeramente que tiene el header, si no me equivoco es la palabra header, secure y también está marcada como HTTP only.
¿Qué estamos haciendo con eso? El secure indica que ese cookie solamente se puede enviar o enviar y recibir si estamos utilizando una conexión segura o cifrada con SSL y el HTTP only significa que esa cookie solamente la va a poder leer el servidor, el backend. El frontend, aunque el javascript puede acceder a los cookies, no puede acceder a las cookies que están marcadas como HTTP only.
las va a poder ver no las puede leer así que si necesitamos tener información que identifique a un usuario y que es muy importante bueno hay que marcarlos como HTTP only y así pues nos evitamos muchos dolores de cabeza antes era
Recuerdo que para mi el tema de los cookies doulas era bien complejo siempre me costó entender todo este tema pero pero bueno cada vez los lenguajes de programación y los frameworks lo hacen más fácil así que para mí ha sido muy ventajoso eso porque recuerdo cuando empezaba a programar simplemente no entendía no entendía cómo funcionaban las cookies no le encontraba
De hecho recuerdo que yo decía esto ¿para qué lo vamos a utilizar? No sirve para nada decía yo en mi mente y yo sorpresa toda la industria funciona a través de cookies pero bueno
Douglas (32:47)
años ya, ¿no? Como 94 nacieron las cookies, es una cosa así.
Juan (32:52)
Si, creo que si. Bueno yo lo empece a ver allá por el 2010 creo Ya tenían su tiempo pero pues como menciono, yo venia empezando no le entendía Y así, han ido evolucionando, menos mal Pero bueno, de nuevo Y mas si estamos trabajando de full stack Aunque se dice que no existe el verdadero full stack Tal vez solo la AI es full stack, pero cuando estamos haciendo bucket y fronted
hay que tener este cuidado hay que tener este cuidado de tener htp only para los cookies y no mandar información sensitiva siguiente tip siguiente consejo Douglas
este es uno que suelo ver que si cometen mucho este error lo cometen mucho los principiantes porque cuando lo haces de la manera incorrecta te hace la vida más fácil mientras estás desarrollando sin embargo ya cuando está en producción no es recomendable me refiero a enviar errores que sean significativos ya lo hemos visto no yo envío una petición al servidor
y falló de alguna forma.
es muy fácil enviar, bueno, el campo correo no es válido porque tiene un carácter de tal cosa el campo ID está vacío, esperaba que me enviaras un campo ID y empezás a enviar ese tipo de errores al cliente que de nuevo mientras estamos desarrollando son muy útiles pero totalmente malos para el momento en que ya sale a producción ¿por qué son malos? bueno porque
estamos enviando información a cualquier persona que esté escuchando lo que estamos regresando en su momento con ya no lo suelo hacer pero antes yo solía meterme a todas las páginas web y empezaba ver todas las peticiones que hacía mientras estaba navegando ese era como mi hobby, empezaba a ver todos los payloads y las cosas que enviaba muy, si, si, si, muy, se que era un hobby bien
Douglas (35:02)
Qué hobby más interesante.
Juan (35:07)
popular. Yo lo hacía por hobby, me interesaba ver cómo trabajaban otras empresas más grandes, cómo lo hacían, cuáles eran las prácticas que utilizaban.
pero así lo puede hacer cualquier persona que quiera atacar un sitio web y cuando empiezan a ver todos los errores que estamos enviando y vemos que le estamos diciendo el ID tal o peor aún estamos retornando errores que vienen de validaciones de nuestra base de datos a veces enviamos de regreso validaciones donde dice el campo tal de la columna por ejemplo en infamemente el árabe ha tenido
este esta pequeña pequeño problemita donde ingresamos una página hecha con lara bel php y nos lanza el error del y nos dice todo no columna tabla el directorio todo todo todo muy mal muy mal de nuestra parte porque se puede evitar pues está muerto larga vida php sí
Douglas (36:09)
Por eso PSP está muerto, ⁓
Juan (36:17)
Lo ideal es enviar errores muy genéricos. Falló el servidor, petición incorrecta, recursos no encontrados, cosas así.
Douglas (36:27)
consulta y no hay como librerías o un modo de development o un modo de debugging porque me he topado con eso.
todo eso en producción, me he fijado que muchas aplicaciones nuevas si lo pones en modo development o si habilitas los debugging tools, podes ver todo eso pero cuando están deshabilitados, está como listo para producción y no muestra esas cosas. Te hago la pregunta y lo menciono porque me parece útil porque si no es fácil que un programador olvide la información de debugging que iba poniendo, a mi me ocurre muchas veces cuando estoy
haciendo troubleshooting de CI-CD pipelines y me funcionan en local y funcionan en todos pero ya en GitHub Action o en GitHub Fire entonces mientras estoy desarrollando pongo más información de debugging
y voy anotando lo que agrego porque en una ocasión me pasó que lo dejé ahí, voy anotando lo que agrego y cuando termino me toca borrar las ejecuciones porque queda el historial en verdad, borrar las ejecuciones del GUI y el último commit que ves de mi parte dice removiendo el debugging para quitar todo lo que agregué pero en un pipeline, aunque me tomes mi tiempo no va a hacer tantas cosas pero me puedo imaginar
Juan (37:42)
Ok.
Douglas (37:49)
una aplicación pudiera llegar a ser bastante esa información de debugging. Entonces, ¿existen realmente este tipo de librerías que te ayudan con eso o realmente el programador tiene que asegurarse de desarrollar algo como eso?
Juan (38:05)
Cuando estamos utilizando frameworks, normalmente ya traen este tipo de funcionalidades dentro del mismo framework. Por ejemplo, del lado del frontend...
nos dan muchas herramientas como lo que mencionaba de los source maps para react, view o angular te permite ver código que está dentro de tu mismo código fuente en el navegador y cuando momento de que haces el build y pasas todo a producción normalmente lo quita podrías también hacer tweaks en las configuraciones para que lo deje pero pues ya dijimos que no queremos eso en el lado del backend también
podrías utilizar algún framework que ya haga esto internamente pero si no estás haciendo un framework entonces ahí toca hacerlo desde cero lo que se busca es como mencionaba enviar errores genéricos
y lo que podrías hacer es que dependiendo del ambiente en el que estás, digamos estoy en un ambiente de producción o un ambiente de testing, esto lo podríamos detectar por variables de entorno. Esto no hay ningún problema, detectamos cuál es la variable de entorno, si es testing, es producción y en base a eso incluimos código. Podríamos incluir, ok, estoy en testing, ok, entonces sí voy a enviar toda la información necesaria.
o entonces pero si no reviso estoy en producción ahora no ahora sólo envío un mensaje genérico eso en mi caso yo lo he hecho desde cero lo que hago es hacer como ya sea rappers o librerías custom donde pues ya hacen eso ya ya no tengo que hacer ya no tengo que hacer esa validación en cada uno de los logs en cada uno de los de las respuestas sino que ya la librería como tal se encarga de esto
Pero de nuevo, en testing se vale, en producción no, porque estamos dando información que no queremos que los atacantes la tengan.
Douglas (40:07)
Una anécdota Juan, rapidita,
hace muchos años en este trabajo donde vos y yo nos conocimos, había un programador que mientras implementaba una funcionalidad en el sistema de cobros, yo mencioné en el episodio anterior que se manejaba el propio sistema de cobros por tarjetas de crédito, el programador de backend decidió guardar en log
mientras implementaba la información del cliente y el número de tarjetas de crédito en un log, mientras probaba porque él usaba tarjetas de crédito de prueba que eran de la empresa para estar haciendo transacciones. Pues parece que se le olvidó quitar ese log y después de un tiempo, y realmente que yo creo que pasó más de un año, ya no recuerdo, pero fue bastante tiempo,
Por suerte, tenía ese lock fuera del sitio habitual donde se almacenaban los locks. Entonces, una persona que estaba centralizando locks, información, empezó a ver fuera como que, ¿qué más hay que sacar del sistema de tarjetas de crédito?
Y se topó con ese log y dio la impresión. El montón de tarjetas de créditos reales almacenadas en ese log. Nadie sabía, él no se acordaba. Obviamente hubo problemas, ¿verdad? Por eso, eso es algo muy, muy delicado. Pero se corrigió. Nadie, no se hizo nunca con mala intención.
Sin embargo, por eso yo te hacía la pregunta y lo menciono, he visto problemas serios con developers que han olvidado quitar información de debugging de los logs en la parte de backend porque el último concierto que en su ojo caíste fue sobre backend. He visto problemas serios y ese fue uno grave. Ese fue uno grave. Gracias a Dios estaba fuera, nunca se envió a un lugar central de logs, nunca salió de los servidores.
Sin embargo, no dejaba de ser algo muy serio, muy crítico. Guardar el número completo, tarjeta de crédito de un usuario es algo crítico. solo los bancos e entidades autorizadas lo pueden hacer. Entonces, cuento la anécdota. Hubo un problema serio. No pasó nada grave, pero hubo un problema serio. Y entonces procuren usar algo como lo que Juan nos está recomendando ahorita porque créanlo o no, se olvidan las cosas y pudiéramos estar mostrando
demostrando información demasiado crítica para atacantes.
Juan (42:38)
con ese tipo de problemitas específicos con los me estas mencionando que son logs algo que nos puede ayudar es manejar diferentes niveles de logs por ejemplo en producción probablemente tendríamos un log no tan grande tal vez no está todo
Normalmente se deja por ejemplo el log de error, solo vamos a mostrar errores o un nivel un poquito más arriba de error, sería un creo que normalmente se dice debug donde ya nos muestra errores y ciertos mensajes o info o a diferentes librerías lo manejan de diferentes maneras
Douglas (43:14)
info creo que es
Juan (43:20)
y un nivel muy extenso o más profundo normalmente se le dice el nivel de trace y ese sí pues muestra todo idealmente no es así como se manejan los niveles de logs
lo recomendable aquí sería entonces utilizar un nivel de log de trace para este tipo de debugging que normalmente en producción no se va a habilitar eso lo que nos da es tiempo para poder revisar que en testing estamos mostrando información que no queríamos y poder reaccionar a tiempo antes de que en producción pueda ser siquiera visible
porque aunque en producción no está siendo visible pero si está la línea de código que estamos logueando información sensitiva hay que quitarlo, lo ideal es quitarlo de ahí
Douglas (44:13)
perfecto, me gusta, me gusta
Juan (44:16)
Bien, entonces pasemos al siguiente tip que tengo por aquí de Douglas. De nuevo es un tip muy fácil, muy sencillo, pero es un tip que tiene pues un poquito de trampa y a veces se puede llegar a complicar. Me refiero a actualizar las dependencias siempre que sea posible.
Y este siempre que sea posible es la parte difícil porque a veces no podemos actualizar tan rápido pero no podemos dejar de actualizar las dependencias.
Entonces necesitamos encontrar un punto medio. De hecho recuerdo que en episodios anteriores nos has compartido Douglas las estrategias que ustedes han seguido para actualizar donde dejan un año, dejan un cierto tiempo con unas librerías y luego van haciendo, si no me equivoco, iban un año atrasado o una versión atrás de la más reciente, ¿no? Algo así creo que era lo que nos habías compartido. Pero bueno, la idea es básicamente eso, es actualizarlo.
para no estar con código que sea o dependencias que sean vulnerables porque y porque actualizar bueno lo que sucede es que a medida va pasando el tiempo la gente va descubriendo cómo romper las vulnerabilidades de diferentes dependencias entonces cuando encuentran una falla o una puerta trasera o cualquier cosa lo empiezan a utilizarla y los desarrollos
los que están manteniendo la librería pues sacan una nueva versión para corregir estos estos problemitas entonces si bien no es recomendable actualizar el día 1 tampoco es recomendable no actualizar para nada eso no es nada bueno
Douglas (46:06)
Sí, de hecho hay mucho problema con los módulos de Node.js, sobre todo recientemente. De hecho, el último incidente que tuvo Cloudflare hace unos, hace qué, dos días tal vez, al momento en que estamos haciendo la grabación, es porque ellos estaban intentando parchar una de esas librerías vulnerables y pues ahí como que publicaron algo que no era, ¿no? Y comenzaron con una falla en el dashboard y se expandió otro lugar.
pero sobre todo lo que está diciendo los módulos de node o paquetes en el caso con php se usa composer idealmente para manejar paquetes cualquiera que sea en golan es lo mismo
tiene su manager de paquetes, es muy fácil dejar ese código vulnerable y hay que estar pendiente. Entonces hay que implementar estrategias. En un episodio anterior yo he mencionado estrategias que nosotros usábamos, pero traten de tener un flujo de trabajo que les permita estar revisando constantemente para que si hay una vulnerabilidad crítica...
tengan ya un proceso para parcharla de manera inmediata y también tengan un proceso recurrente para cada tres meses, cada seis meses o cada año estar haciendo actualizaciones desde el sistema operativo hasta librerías en su código para que no se queden muy atrás porque puede darse un caso de que sale una vulnerabilidad seria, necesitan parcharla sí o sí.
pero están tan atrás que no la pueden actualizar porque tal vez el lenguaje no la soporta o tal vez otras librerías están muy atrás y no lo soporta. Entonces, por eso es bueno tratar de llevar no más de unos seis meses a un año atrás en una librería mientras no tenga vulnerabilidades.
Juan (47:48)
mmm
Sí. Y bueno, en este momento hemos estado dando muchos tips que son para developers más específicamente, pero actualizar vulnerabilidades o parchar vulnerabilidades. Ese sí es un trabajo en equipo. Tiene que hacerse tanto los sysadmin como los desarrolladores. Todos tenemos que actualizar todo lo que podamos porque, bueno, en el caso de los lenguajes de programación,
Yo diría que el que más he visto que tiene problemas es npm por algún motivo siempre es bueno supongo que es por la popularidad de javascript pero siempre es víctima de ataques a la cadena de suministro y hay muchas muchos casos bueno si no me equivoco la semana pasada creo que hubo un ataque a la cadena de suministro
En PM tiene un problemita, desde mi punto de vista creo que es un problema, pero no sé por qué estar así. Y es que te permite ejecutar ciertos scripts después o en el mismo momento en el que se descarga la dependencia. Lo cual es un poco extraño desde mi punto de vista, pero bueno, tampoco quiero decir que sé más que los desarrolladores de PM, ¿verdad?
hay maneras de solventar esto creo que se puede deshabilitar esa funcionalidad y se puede dejar solo para o hacer solo en caso que sea realmente necesario así que aquí sería un consejo añadido y es revisen bien las dependencias que están utilizando investiguen bien cómo funciona el sistema de paquetes del de la stack que están utilizando porque si no sabemos que npm tiene esto esta funcionalidad pues ni siquiera
nos damos cuenta y estamos descargando paquetes y esos paquetes también por detrás están haciendo cambios en nuestro sistema operativo, en cuenta nos dimos.
también es necesario estar actualizado nosotros y saber que ok hubo un ataque a cierta librería y yo estoy utilizando esa librería entonces hay que tomar cartas en el asunto ya sea bajar una versión o actualizar la versión que ya tiene el parche también revisar como consejo general no revisar qué es lo que estamos descargando yo en episodios anteriores he mencionado que desde mi punto de vista es un gran problema el hecho de la gran dependencia
que
tenemos sobre código de terceros y si bien nos hace la vida más fácil pues también nos hace perezosos para saber qué es lo que realmente hace esa librería así que como consejo general investiguen lean los comentarios revisen cada cuánto se está actualizando dicha librería revisen cuáles son los los issues que tienen abiertos en el github y qué es lo que está diciendo la la la gente en general no solamente vean que hace
que se conecta a la base de datos y ya, revísenlo un poquito más. Y bien, me gustaría entonces pasar Douglas al último consejo porque tenía unos cuantos pero ya los hemos cubierto en lo que hemos hablado sobre la marcha.
y el otro que quiero hablar es orientado al backend es el hecho de no reemplazar valores de un string de un texto para construir queries hay que utilizar los parámetros que nos da el lenguaje me explico
Cuando estamos haciendo queries hacia la base de datos y bueno aquí dependiendo de la filosofía de cada empresa hay empresas que prefieren utilizar Store Procedures en la base de datos o utilizar ORMs o hacemos los queries nosotros. Si estamos haciendo queries directamente en el código lo cual no está mal. ⁓
no es una mala práctica, sin embargo lo que sí puede ser una mala práctica es que nosotros empecemos a construir el query, hay queries que son por ejemplo si enviaste un valor agregó un WHERECLASS, si enviaste otro tipo de valor entonces hago un JOIN, si enviaste un valor que es menor de tal cosa y empezás a construir este tipo de queries que son condicionales y bueno no es
inicialmente puede ser muy fácil empezar a agregar el texto porque al final un query es un texto entonces empezamos a agregar estos valores y lo estamos haciendo así ¿qué sucede? cuando estamos construyendo estos queries lo estamos haciendo con los valores reales directamente en el texto
y si estamos recibiendo código malicioso y por algún motivo la librería o el framework no logró sanitizar correctamente ese valor lo vamos a incluir en la ejecución del query
Así que como último punto de defensa lo que tenemos que hacer es las funcionalidades que ya nos dan los lenguajes de programación donde pasamos el query y aparte enviamos los parámetros que queremos incluir dentro de ese query. Entonces esto es algo que bueno como mencionaba las librerías ya nos dan estas funcionalidades pero es con estos queries que se empiezan a ser más complejos donde muchas veces nos vemos tentados a no seguir las
los patrones que deberíamos porque pues no hacemos una lógica que va por otro lado esto yo lo he visto en código de producción yo lo he visto en aplicaciones que que sí están corriendo y pues no es una buena práctica estamos abriendo las puertas a que suceda algo
algo un comentario que siempre se hace es que el backend no debe confiar en nada que viene del frontend debemos asumir que estamos recibiendo código malicioso y estamos recibiendo información que no es correcta así que por eso debemos agregar estas validaciones de hecho estoy recordando Douglas tengo un último consejo que había olvidado pero pero bueno con este
⁓ no programar, pero estoy seguro que en los scripts que haces normalmente te ha tocado hacer como condicionales de si recibes un valor, haces otra cosa y por ejemplo con Python se puede hacer, se puede construir texto muy fácilmente pero bueno, es una mala práctica así que a cualquiera que nos está escuchando, corrijan eso en caso que lo estén utilizando.
Douglas (54:36)
Sí, sí, absoluto.
Juan (54:39)
Bien, ahora si el ultimo tip que tengo que lo habia olvidado es el hecho de sanitizar los valores va ligado a que habiamos dicho de validar los inputs y los outputs pero me gustaría mas que solamente decirles que los sanitizan es explicar un poco el por que y es que algo que sucedia mucho antes era lo cross side scripting
y era el hecho de que nos incluían código que se podía ejecutar en el navegador ¿y cómo funciona eso? bueno, básicamente una forma que se suele dar no es la única, supongo, pero es la más fácil de explicar digamos que estamos recibiendo texto, ¿no? o un comentario alguien escribió un comentario en nuestra página web dentro de ese comentario
alguien incluye lo que son los tags, los tags de HTML, los tags de script y dentro de ese script podemos incluir código de JavaScript. Eso se guarda y si no tenemos bien asegurado nuestra aplicación, eso se guarda en la base de datos y luego cuando alguien entra a nuestra página y carga todos los comentarios se va a cargar también el script que incluyó esa otra persona.
¿Y qué suelen hacer? Lo que suelen hacer es incluir en ese script, tal vez una URL que envíe los cookies, por ejemplo, a un servidor que ellos están manejando. Eso es un ataque que puede suceder en nuestros sitios web si no lo aseguramos correctamente.
La ventaja Douglas es que hoy en día eso cada vez es un poco más difícil porque cuando utilizamos frameworks como React, como Vue, como Angular automáticamente ya sanitizan ese tipo de texto.
y solamente cuando nosotros ejecutamos código HTML puro es que ahí no lo van a sanitizar pero bueno eso no es una buena práctica normalmente no deberíamos hacer eso pero bueno quería mencionar eso porque muchas veces hablamos de que hay que sanitizar los valores hay que validar el input y validar lo que parámetros que estamos recibiendo en la base de datos pero creo que a veces no queda claro el por qué entonces por eso me quería hacer esta
aclaración y es que puede suceder esto ya que el navegador va a ejecutar todo lo que está recibiendo. No sé si habías escuchado sobre eso Douglas, el cross-site scripting, si te tocó alguna vez agregar ese tipo de validaciones para algún sitio web o...
Douglas (57:22)
Sí, fíjate que sí,
más veces de lo que me gustaría porque también en estos formularios así es como también envían SQL Injection.
que como eso termina en la base de datos, la siguiente vez que alguien ejecuta un query o algo, intentan que tome eso como un comando de SQL y que se ejecute. Y de hecho, recientemente, hace tal vez cuatro meses, tuve un pequeño incidente, bueno, no mío, me tocó lidiar con un incidente, con una aplicación en Next.js que estaba permitiendo code injection por medio
Juan (57:31)
Correcto.
equipo.
Ok
Douglas (58:01)
de formularios. Por suerte no pasó a más y nos dimos cuenta porque el backend tenía validaciones y vimos, empezamos a recibir errores de backend que se quejaba de lo que recibía del frontend y ahí donde vimos...
Juan (58:18)
que
Douglas (58:19)
El Bakken solamente, lo único es que la respuesta no era tan clara del Bakken, pero sí el ingeniero de Bakken que lo hizo, sí lo hizo pensando en evitar code injection, recientemente tuvimos ese problema, no pasó a más porque el ingeniero de Bakken se tomó el tiempo para asegurarse que la información que está recibiendo sea sanitizada.
verdad aunque él no le toma, no es quien tiene que sanitizarla, él se tomó el tiempo de asegurar que venga, de agregar ciertas validaciones. Entonces sí, recientemente con Next.js, no sé si es porque era una versión vieja, la verdad no recuerdo qué versión de Next.js era, no sé si porque era una versión antigua o qué, pero sí pasó con un framework que es de los más utilizados de JavaScript hoy en día en front-end, verdad, entonces es de tener cuidado, es de tener conciencia.
Juan (59:11)
Si, no hay que confiarnos. Como dije, hoy en día es más difícil que suceda, pero pasa. Y bueno, así como el backend no confía en el frontend, la base de datos no debe confiar en el backend y cada quien se va blindando de la manera que considere mejor.
Douglas (59:17)
Sí.
Exacto, exacto.
Mm-hmm.
Juan (59:28)
Bien, hemos llegado al final Douglas de este episodio. No quería extendernos tanto porque cada uno de estos tips que hemos dado son fáciles y creo que los pueden implementar ya en sus sitios web, sus proyectos. Tal vez más adelante podríamos incluir cosas un poco más complejas, pero la realidad Douglas es que con todos estos tips
si lo implementas todo, realmente tu sitio web va a estar muy seguro y si a esto le sumamos los tips que diste en el episodio anterior pues ya tenemos un sistema que es bastante robusto bien
Douglas (1:00:10)
Sí,
es que me gusta lo que decís y bueno, lo que yo puedo compartir a las personas que nos escuchan es de que sepan que el 98 % de los ataques, y de nuevo, esto es un número que yo estoy mencionando, digamos lo por ahí, ¿no? 98.7, los ataques que se dan en internet son por bots, son por robots.
Juan (1:00:28)
98.7
Douglas (1:00:38)
Y los tips que Juan nos está dando hoy y los que dimos la semana pasada, si implementamos eso, nos quitamos de encima ese...
gran número 98.7 que nos inventamos ahorita. Nos quitamos de encima ese gran número de atacantes que hay y son tips fáciles de implementar. Solamente le dedicamos un poquito de conciencia, un poquito de mente lo que dimos la semana pasada con respecto a infraestructura, lo que Juan nos dio hoy con respecto a código, ya nos dijo Juan, ya hay librerías, ya hay frameworks que lo hacen, solo asegurémonos que está ahí. Y implementando eso nos quitamos la gran, gran, gran mayoría de ataques.
e intentos de ataques que pasan todos los días en Internet.
Juan (1:01:22)
es correcto, bien, muchas gracias Douglas por acompañarme nuevamente en este episodio gracias a todas las personas que han llegado hasta aquí sigo esperando que nos comenten si llegaron hasta el final del episodio por favor y alguien lo va a hacer y bueno muchas gracias a todos esto ha sido todo nos vemos a la próxima
Douglas (1:01:38)
alguien lo va a hacer algún día.
Bye.