Tenia esa duda que me comía la cabeza desde que arranque con desarrollo web jajaj y uno de los motivo por los que no me animaba a crear algo profesional mas que proyectos personales sin riesgo alguno. Mas videos así y muchas gracias!
Saludos desde la costa colombiana, m gustó ... y mas por q de cierta forma andaba pensando en esas ciertas buenas practicas a la hora de desarrollar Software, GRACIAS
Parecen recomendaciones básicas, sin embargo no tienes idea de en cuantos proyectos he visto que no se tienen en cuenta, con lo que se hacen muy importantes. Buen vídeo. 👍🏼
Muy buen video, me hace sentir tan bien que antes de informarme tanto yo ya sabía que había algo raro con que pudieras manipular tan fácil cualquier API con postman, actualmente valido con la misma cookie el acceso a las apis, de igual manera que con los controladores pero estoy pensando implementar Jwt aunque me pongo a pensar que si las cookies son tan fáciles de robar y acceder a tu api cuál sería el problema con robar una y acceder a tu sesión, hice unas pruebas con navegadores externos y efectivamente es tan fácil como copiar y pegar mi cookie para tener el acceso como usuario, aquí las soluciones buenas son las cookies que se autoregeneran o que se ligan directamente a una ip, hay un montón de cosas pero yo uso php, probablemente con otras texnolgoias sea más fácil llevar el tema pero mientras me la juego protegiendo mi php
Gracias por estos valiosos consejos 👌, no me pierdo tus videos Estoy manejando arquitecturas serverless, y en esta es dificil el manejo de variables de entorno, algun consejo de seguridad adicional para este tipo de arquitectura?
1. Restringe tu base de datos. 2. Guarda información sensible de forma segura encriptada. 3. Guardar la configuración en variables de entornos. 4. Asegura la información de tus apis, seguridad. 5. Valida del lado del servidor. 6. No guardes información sensible en en front end.
cg1 8.5, el que utilizan en los supermercados, tiendas y similares, tiene todos los problemas de seguridad que te puedas imaginar: carpetas compartidas con todos los permisos, información escrita en texto plano, rutas alternas de acceso, etc, etc, etc y es utilizado en varias ciudades de américa latina
Muy buenos consejos, cómo impides del lado frontend que no guarden datos en los input=text por decir he visto usan un atributo autocomplete=false esa sería una existe otra ?
Yo me he topado con api que manejan sus id con identity consecutivos. Creo también puede set un problema de seguridad ya que es fácil tener uno válido y seguir hasta el infinito en la obtención de datos. Otra cosa que también he visto es demasiados log visibles en el front algunos hasta con información sensible. Guardar también datos sensibles en el front dentro de campos no visibles. Son cosas que he visto.
Excelente contenido como siempre Manuel gracias por compartir tu conocimiento. Manuel espero que a futuro puedas hacer un vídeo explicando la forma correcta de organizar tu solución (que clases deberían en qué que proyecto) y el tema de organizar las librerías externas que se descargan (nuget) el tema de el ambiente de permiso sobre el sistema operativo ( iis, variables de Windows). Ya que este el punto inicial del desarrollo y dónde llega a perderse mucho tiempo y del cual casi no existen videos explicativos.
Hola Enrique, gracias por las recomendaciones! El tema de como se podría organizar el proyecto me parece interesante. Creo que a muchas personas les beneficiaría. Quizá el tema de las librerías externas y los permisos sea demasiado específico para abordar en el canal, pero igual lo anoté en mi backlog de ideas. Saludos!
Muy buen video! Gracias por los consejos 🙌🏻 sobre las cookies, que opinas de la idea de encriptar su contenido para que no llegue como texto plano al cliente? Gracias!
Si no mal me equivoco, si consiguen acceso a la base de datos pueden descubrir que tipo de hash has usado y buscar bibliotecas de ese hash o crearla de forma local o desde botnet para saber que contraseñas tenian esos usuarios. Porque supongo que twitch tenia eso y recomiendan cambiar contraseñas por esto mismo
¡Gracias! Me he encontrado con muchos errores de seguridad, especialmente en aplicaciones legadas: un endpoint DELETE abierto, la lógica de negocio en el cliente, la cadena de conexión en el código, las consultas a la base de datos sin el "where user=xyz", autenticación implementada desde cero, etc. Muchas veces lo más complicado es argumentar el refactoring, porque son "aplicaciones que funcionan".
El mejor argumento que he encontrado es explicar los riesgos legales y de reputación de la empresa en caso de que exista una fuga de datos. La otra alternativa es ir pagando esa deuda técnica de "a pocos". Y sí, la consulta sin WHERE con user pasa. Lo vi una vez. Autenticación desde cero también es para problemas.
Muy buen video Manuel, en algún momento que me pase a frontend me di cuenta que tenia el backend seguro pero en el front me faltaba agregar guards para que no vieran las vistas., saludos
Muy bueno el video, en la universidad nunca me enseñaron estos tips. Consulta, la encriptación por hash con bcryot se hace en el código backend o en el servidor de base de datos se puede hacer directamente? gracias!
Se hace normalmente en el backend, Eze. La idea es que una vez encriptas haces una consulta para ver si el nombre y la contraseña encriptada están en la BD o no.
Al entrar en mis aplicaciones usamos LDAP, pero al estar depurando con F12 se ve el usuario y contraseña por que se manda al LDAP con POST, ahí que puedo hacer??? he visto muchas páginas web en donde estoy dado de alta (Escuela por ejemplo, intranet del trabajo donde también esto ocurre) solo en páginas como google o amazon ahí no ocurre
Excelentes consejos Manuel. Solo quisiera agregar algo al primer punto porque puede no ser tan claro cuál es la ip u origen de la aplicación al que se le debe dar acceso: esto sería, por ejemplo, la ip del servidor en el que se hospeda la aplicación, en caso de una aplicación web.
Excelentes consejos Manuel. Yo he encontrado varios fallos en los proyectos que he estado, incluso yo los he cometido, jejejeje... Por ejemplo quemar las credenciales para conectar a la bd, no realizar validaciones en el back porque asumimos que el front valida, no encriptar datos sencibles al guardar en la base de datos, no eliminar los tokens cuando el usuario cierra sesión, entre otros. Pregunta: Cuando dices que usar variables de entorno, ¿Te refieres a la variables de entorno del servidor?
Errores clásicos! Lo importante es aprender y no volverlos a cometer. En cuanto a tu segunda pregunta, así es Jhon Fredy. Son las variables de entorno del servidor o contenedor sobre el cual corre la aplicación.
Gracias por el aporte. Una consulta, consideras viable y buena practica de seguridad encriptar la data de los request del lado del frontend y desencriptarlo en el backend ? Saludos desde Lima, Perú
Eso depende en parte de las capacidades de los dispositivos, pero como puedes ver, casi todos estos consejos están enfocados al backend, no a los clientes.
Yo me encontré con un dilema al utilizar WepAPI de Google, no encontré como restringir la Key o no me funcionó; las apikey tienes q ponerlas en el front o al menos para c# no ví ejemplos de como mandarla desde el back, no sé si alguien haya usado apimaps desde el back
Buen video, me alegra saber que ya hago implementacion de alguno de estos consejos, una pregunta. Yo implemento un token donde va el id, el rol y el correo del usuario, ¿es necesario validar la veracidad de esta información en la base de datos en cada petición? Hay vistas donde hago peticiones simultáneas y no se que tan óptimo sea validar la información del usuario en cada petición. Muchas gracias por el video, excelente contenido.
La ventaja de utilizar el token (supongo que es un JWT) es que puedes detectar si es modificado. O sea que en teoría no tendrías que validarlo en cada llamado. Saludos Jonathan y muchas gracias por hacerte miembro.
Creo que el más comun que he visto es el uso de frameworks/librerias deprecadas, ya que constantemente las tecnologias más usadas estan arreglando bugs de seguridad, usar versiones antiguas de los mismos siempre es un riesgo, pero si ademas usas versiones que ya ni siquiera tienen soporte de seguridad mucho peor
Seguridad App Web - Resumen Consejo 1: Restringe el acceso a la BD (Solo ip u origenes autorizados) Consejo 2: Guarda de manera segura información sensible (Hashing de contraseñas, bcrypt | PBKDF2) Consejo 3: Usa variables de entorno (Ambientes: Dev | Test | Pro) Consejo 4: Asegura las rutas de tu API (Tokens, Authorization) Consejo 5: Valida del lado del servidor (Entradas de datos, Campos requeridos, Prevenir SQL Injection) Consejo 6: No guardar información sensible del lado del cliente (Cookies, LocalStorage No info que pueda comprometer al usuario). TOP 10 del OWASP
12:51 Yo he visto contraseñas tapadas visiblemente con un display="none" Solo era cuestión de clic derecho ver código fuente y todas las cuentas a tu disposición. Era un concurso de una galleta muy conocida en mi país!
Tenia esa duda que me comía la cabeza desde que arranque con desarrollo web jajaj y uno de los motivo por los que no me animaba a crear algo profesional mas que proyectos personales sin riesgo alguno. Mas videos así y muchas gracias!
Muchas gracias por los consejos! Dios lo bendiga!
Saludos desde la costa colombiana, m gustó ... y mas por q de cierta forma andaba pensando en esas ciertas buenas practicas a la hora de desarrollar Software, GRACIAS
Están muy buenos los consejos Manuel. gracias.
Con gusto Ernesto!
Parecen recomendaciones básicas, sin embargo no tienes idea de en cuantos proyectos he visto que no se tienen en cuenta, con lo que se hacen muy importantes. Buen vídeo. 👍🏼
Gracias Manuel por la información.
El nivel de tu canal es único Manuel, muchas gracias
Gracias por esas palabras, Javier! Se hace lo mejor posible.
Muy buen video, gracias por la información!
Muy buen video, me hace sentir tan bien que antes de informarme tanto yo ya sabía que había algo raro con que pudieras manipular tan fácil cualquier API con postman, actualmente valido con la misma cookie el acceso a las apis, de igual manera que con los controladores pero estoy pensando implementar Jwt aunque me pongo a pensar que si las cookies son tan fáciles de robar y acceder a tu api cuál sería el problema con robar una y acceder a tu sesión, hice unas pruebas con navegadores externos y efectivamente es tan fácil como copiar y pegar mi cookie para tener el acceso como usuario, aquí las soluciones buenas son las cookies que se autoregeneran o que se ligan directamente a una ip, hay un montón de cosas pero yo uso php, probablemente con otras texnolgoias sea más fácil llevar el tema pero mientras me la juego protegiendo mi php
Excelentes consejos, estaría muy bien una segunda parte. Saludos
Genial Hector! Algún problema de seguridad que te hayas encontrado y que sería interesante mencionar en la segunda parte?
Están muy buenos tus videos, te vi en un live de Manuel Gil, pero no había tenido la oportunidad de ver tu contenido y esta excelente
Agrada mucho el gran conocimiento que tienes y la humildad que transmites bro
Gracias por esas palabras, Victor.
Que gran Explicación
Gracias por estos valiosos consejos 👌, no me pierdo tus videos
Estoy manejando arquitecturas serverless, y en esta es dificil el manejo de variables de entorno, algun consejo de seguridad adicional para este tipo de arquitectura?
1. Restringe tu base de datos.
2. Guarda información sensible de forma segura encriptada.
3. Guardar la configuración en variables de entornos.
4. Asegura la información de tus apis, seguridad.
5. Valida del lado del servidor.
6. No guardes información sensible en en front end.
Como siempre, gracias por el aporte Renso!
cg1 8.5, el que utilizan en los supermercados, tiendas y similares, tiene todos los problemas de seguridad que te puedas imaginar: carpetas compartidas con todos los permisos, información escrita en texto plano, rutas alternas de acceso, etc, etc, etc y es utilizado en varias ciudades de américa latina
Muy buenos consejos, cómo impides del lado frontend que no guarden datos en los input=text por decir he visto usan un atributo autocomplete=false esa sería una existe otra ?
Excelentes consejos, me ayudan a mejorar mis APIs
Esa es la idea, Richard! 🙌
Muy buen contenido Manuel. ¡Dios te bendiga!
Gracias Kevin!!
Excelente información, super importante tener buena seguridad en nuestros desarrollos, gracias Manuel.
Buen video, justo aplicaba las recomendaciones mencionadas en el backend
Yo me he topado con api que manejan sus id con identity consecutivos. Creo también puede set un problema de seguridad ya que es fácil tener uno válido y seguir hasta el infinito en la obtención de datos.
Otra cosa que también he visto es demasiados log visibles en el front algunos hasta con información sensible.
Guardar también datos sensibles en el front dentro de campos no visibles. Son cosas que he visto.
Excelentes. consejos como siempre Manuel
Gracias Fran. Saludos!
Cómo recomiendas guardar el secreto OTP en la BD?
Hola, si tengo un proyecto de front que solo es JS, Html y Css donde guardarias el token que te regrese la api por inicio de sesion?
Excelente contenido como siempre Manuel gracias por compartir tu conocimiento. Manuel espero que a futuro puedas hacer un vídeo explicando la forma correcta de organizar tu solución (que clases deberían en qué que proyecto) y el tema de organizar las librerías externas que se descargan (nuget) el tema de el ambiente de permiso sobre el sistema operativo ( iis, variables de Windows). Ya que este el punto inicial del desarrollo y dónde llega a perderse mucho tiempo y del cual casi no existen videos explicativos.
Hola Enrique, gracias por las recomendaciones! El tema de como se podría organizar el proyecto me parece interesante. Creo que a muchas personas les beneficiaría. Quizá el tema de las librerías externas y los permisos sea demasiado específico para abordar en el canal, pero igual lo anoté en mi backlog de ideas. Saludos!
Muy buen video! Gracias por los consejos 🙌🏻 sobre las cookies, que opinas de la idea de encriptar su contenido para que no llegue como texto plano al cliente? Gracias!
Muy buen video deberías hacer un live sobre seguridad y hacer alguna práctica evidenciando estos tips que mencionas
Felipe, dale una mirada a este live sobre seguridad que hicimos hace unas semanas: th-cam.com/video/p9jhzpJJUEQ/w-d-xo.html
Será posible aplicar bcrypt al value que introduce el usuario en la web y a ese mismo aplicarle AES_ENCRYPT de mysql en la bd?
Muy bueno, me toco aprender todo eso con la experiencia
La experiencia es una muy buena maestra
Si no mal me equivoco, si consiguen acceso a la base de datos pueden descubrir que tipo de hash has usado y buscar bibliotecas de ese hash o crearla de forma local o desde botnet para saber que contraseñas tenian esos usuarios. Porque supongo que twitch tenia eso y recomiendan cambiar contraseñas por esto mismo
Buenos datos. Estoy recién inscrito en este canal. Está bueno. 😃
Genial Javier! Bienvenido por estos lados.
@@ManuelZapata 😎👉👉
¡Gracias! Me he encontrado con muchos errores de seguridad, especialmente en aplicaciones legadas: un endpoint DELETE abierto, la lógica de negocio en el cliente, la cadena de conexión en el código, las consultas a la base de datos sin el "where user=xyz", autenticación implementada desde cero, etc. Muchas veces lo más complicado es argumentar el refactoring, porque son "aplicaciones que funcionan".
El mejor argumento que he encontrado es explicar los riesgos legales y de reputación de la empresa en caso de que exista una fuga de datos.
La otra alternativa es ir pagando esa deuda técnica de "a pocos".
Y sí, la consulta sin WHERE con user pasa. Lo vi una vez. Autenticación desde cero también es para problemas.
VIDEASOO .. EXCELENTEEE !!
Muy buen video Manuel, en algún momento que me pase a frontend me di cuenta que tenia el backend seguro pero en el front me faltaba agregar guards para que no vieran las vistas., saludos
Saludos Jesus! Gracias por compartir tu experiencia.
Hola Manu, muy buen canal. Pregunta. En caso de almacenar passwords en una tabla que precauciones y recomendaciones entregarias? Saludos.
Muy bueno el video, en la universidad nunca me enseñaron estos tips.
Consulta, la encriptación por hash con bcryot se hace en el código backend o en el servidor de base de datos se puede hacer directamente? gracias!
Se hace normalmente en el backend, Eze. La idea es que una vez encriptas haces una consulta para ver si el nombre y la contraseña encriptada están en la BD o no.
Al entrar en mis aplicaciones usamos LDAP, pero al estar depurando con F12 se ve el usuario y contraseña por que se manda al LDAP con POST, ahí que puedo hacer??? he visto muchas páginas web en donde estoy dado de alta (Escuela por ejemplo, intranet del trabajo donde también esto ocurre) solo en páginas como google o amazon ahí no ocurre
Excelentes consejos Manuel. Solo quisiera agregar algo al primer punto porque puede no ser tan claro cuál es la ip u origen de la aplicación al que se le debe dar acceso: esto sería, por ejemplo, la ip del servidor en el que se hospeda la aplicación, en caso de una aplicación web.
Así es Jhonny! Gracias por el aporte.
Excelente vídeo!
esta muy bueno los consejos, pero donde puedo conseguir mas informacion sobre las variables de entorno
Empieza por aquí 12factor.net/config
Hola que tal Manuel. Podrías ampliar el tema de variables de entorno por favor
Ese es un tema importante. Lo incluí en mi lista de temas a tratar.
Excelentes consejos Manuel. Yo he encontrado varios fallos en los proyectos que he estado, incluso yo los he cometido, jejejeje... Por ejemplo quemar las credenciales para conectar a la bd, no realizar validaciones en el back porque asumimos que el front valida, no encriptar datos sencibles al guardar en la base de datos, no eliminar los tokens cuando el usuario cierra sesión, entre otros. Pregunta: Cuando dices que usar variables de entorno, ¿Te refieres a la variables de entorno del servidor?
Errores clásicos! Lo importante es aprender y no volverlos a cometer.
En cuanto a tu segunda pregunta, así es Jhon Fredy. Son las variables de entorno del servidor o contenedor sobre el cual corre la aplicación.
Que buenos consejos, saludos
🙌
Una consulta que es mejor usar para la seguridad Jwt u OAuth2
No son excluyentes Jeanpierre. OAuth2 es un estándar para autorización y JWT es un formato para tokens.
Donde almacenar los token de forma segura?
Gracias por el aporte. Una consulta, consideras viable y buena practica de seguridad encriptar la data de los request del lado del frontend y desencriptarlo en el backend ? Saludos desde Lima, Perú
Pero con HTTPS ya resolverías ese problema, no crees?
Muchas gracias Manuel; estos tips se pueden aplicar a una plataforma para el IOT?
Eso depende en parte de las capacidades de los dispositivos, pero como puedes ver, casi todos estos consejos están enfocados al backend, no a los clientes.
Yo me encontré con un dilema al utilizar WepAPI de Google, no encontré como restringir la Key o no me funcionó; las apikey tienes q ponerlas en el front o al menos para c# no ví ejemplos de como mandarla desde el back, no sé si alguien haya usado apimaps desde el back
Buen video, me alegra saber que ya hago implementacion de alguno de estos consejos, una pregunta. Yo implemento un token donde va el id, el rol y el correo del usuario, ¿es necesario validar la veracidad de esta información en la base de datos en cada petición? Hay vistas donde hago peticiones simultáneas y no se que tan óptimo sea validar la información del usuario en cada petición. Muchas gracias por el video, excelente contenido.
La ventaja de utilizar el token (supongo que es un JWT) es que puedes detectar si es modificado. O sea que en teoría no tendrías que validarlo en cada llamado. Saludos Jonathan y muchas gracias por hacerte miembro.
Si guardas el numero de tarjeta de credito en la Base de datos, la encriptacion debe ser reversible
Creo que el más comun que he visto es el uso de frameworks/librerias deprecadas, ya que constantemente las tecnologias más usadas estan arreglando bugs de seguridad, usar versiones antiguas de los mismos siempre es un riesgo, pero si ademas usas versiones que ya ni siquiera tienen soporte de seguridad mucho peor
Buenísimo el aporte. Tienes toda la razón. Saludos!
Seguridad App Web
- Resumen
Consejo 1: Restringe el acceso a la BD (Solo ip u origenes autorizados)
Consejo 2: Guarda de manera segura información sensible (Hashing de contraseñas, bcrypt | PBKDF2)
Consejo 3: Usa variables de entorno (Ambientes: Dev | Test | Pro)
Consejo 4: Asegura las rutas de tu API (Tokens, Authorization)
Consejo 5: Valida del lado del servidor (Entradas de datos, Campos requeridos, Prevenir SQL Injection)
Consejo 6: No guardar información sensible del lado del cliente (Cookies, LocalStorage No info que pueda comprometer al usuario).
TOP 10 del OWASP
Primer comentario del 2021 👏👏👏. Gracias Alejandro por el aporte!
Ese tema de la seguridad muy pocos lo tocan pero es obligatorio en cualquier aplicación
Muy cierto! Muchas aplicaciones tienen deuda técnica en cuanto a seguridad.
Hola Manuel, entonces cuando quiero recuperar la contraseña como se hace con bcrypt?, no se mucho del tema pero me surgió la pregunta
No se puede recuperar la contraseña con bcrypt, Camilo. Es un algoritmo de una sola vía. Es decir, la única opción es cambiarla.
Cómo podría hacer lo de dar acceso a solo ciertas ips en la base de datos con Apache?
Depende de tu base de datos y su ecosistema de herramientas, pero las IPs las configuras en el servidor de bases de datos.
JWT para las API, como mínimo. En mi caso uso spring security y JWT así me cercioro hasta de que usuario me pide algo.
🙌
Master, le sigo hace ratito ya y seguiré aprendido conforme usted siga enseñando. 👏🏼
12:51 Yo he visto contraseñas tapadas visiblemente con un display="none" Solo era cuestión de clic derecho ver código fuente y todas las cuentas a tu disposición. Era un concurso de una galleta muy conocida en mi país!
😨 En serio??? Increíble. Esa no la conocía.
Eres dominicano?
Colombiano!
Hasta que te hackean te preocupas por la seguridad 😣
Como dicen por ahí: “No pasa hasta que te pasa”