
Las 10 mejores API de la serie OWASP de Coders Conquer Security: autenticación rota
No es de extrañar que la autenticación fallida haya figurado en la lista OWASP de problemas de API; los mecanismos de autenticación son notoriamente difíciles de implementar correctamente. Además, los atacantes tienen una pequeña ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben estar expuestos a los usuarios, lo que les da la oportunidad de estudiarlos y buscar patrones o vulnerabilidades que puedan aprovechar.
Por último, dado que la autenticación suele actuar como puerta de entrada tanto a una aplicación como, potencialmente, al resto de la red, son objetivos tentadores para los atacantes. Si un proceso de autenticación se interrumpe o es vulnerable, es muy probable que los atacantes descubran esa debilidad y la exploten.
Por lo tanto, en este capítulo, vamos a aprender cómo excluir a los malos cuando se trata de problemas de autenticación. Si primero quieres poner a prueba tus habilidades, no te pierdas nuestro desafío gamificado:
¿Quieres mejorar tu puntuación? Quédate conmigo mientras lo analizamos.
¿Cuáles son algunos ejemplos de autenticación rota o mal configurada?
Un ejemplo en el que el problema puede no ser tan evidente es cuando un método de autenticación es vulnerable al exceso de credenciales o al uso de listas de nombres de usuario y contraseñas conocidos para infringir la seguridad. Incluso un método de autorización que normalmente es muy seguro, como la autenticación multifactorial, puede resultar vulnerable si las solicitudes no se limitan, limitan o supervisan de otro modo.
Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a/api/sistema/códigos de verificación y proporcionar un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío de mensajes de texto SMS en el que se envía un código de seis dígitos al teléfono del usuario, pero el campo de entrada no es limitado, se puede acceder a la aplicación en solo unos minutos. Un atacante solo tiene que enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta que encuentre la correcta.
En ese escenario, a primera vista, parece que tener una autenticación de dos factores mantendrá segura una aplicación. Sin embargo, dado que la entrada del usuario no tiene una velocidad limitada, la autenticación no funciona y es vulnerable.
En otro ejemplo, una aplicación puede usar objetos de usuario codificados como cookies de autenticación. Sin embargo, si un atacante con un acceso de usuario de bajo nivel decodifica esa cookie con Base64, podría descubrir cómo la cookie define las sesiones y los usuarios de la aplicación. Por ejemplo, es posible que vean el siguiente JSON una vez decodificado:
{
«nombre de usuario»: «ShadyGuy»,
«rol»: «usuario»
{
En ese momento, el usuario malintencionado podría cambiar su nombre de usuario, rol o ambos. Podría convertirse en otro usuario con un nivel de privilegios más alto cambiando un par de valores:
{
«nombre de usuario»: «GoodGuy»,
«rol»: «administrador»
{
En ese momento, si el atacante recodifica la información y la establece como el valor de la cookie, básicamente se convierte en el nuevo usuario con un nivel de permiso más alto. A menos que existan métodos para evitar un cambio de este tipo, es muy probable que la aplicación acepte la transformación.
Eliminación de la autenticación rota o mal configurada
Si la autenticación falla, es muy probable que la seguridad general se vea comprometida. Sin embargo, seguir algunas pautas importantes al codificar las aplicaciones puede ayudar a mantener todo seguro.
En primer lugar, asegúrese de incluir comprobaciones de autenticación en todas partes que permitan a los usuarios acceder a las funciones del programa. Si la verificación de autenticación no existe en absoluto, la batalla está perdida desde el principio.
En cuanto a las prácticas recomendadas, una buena cosa a tener en cuenta es evitar exponer los ID de sesión en la URL a la que pueden acceder los usuarios. En el segundo ejemplo anterior, relativo a la autenticación interrumpida, evitar que un atacante intente descifrar la cookie de sesión es mucho más fácil si nunca la descubre.
También es una buena idea implementar la autenticación multifactor. Esto se puede hacer de forma segura mediante el uso de tokens de hardware que generan contraseñas de forma algorítmica en plazos ajustados. Si no puedes proporcionar a tus usuarios dispositivos como esos, los mensajes de texto SMS también pueden funcionar. Sin embargo, debes asegurarte de que las solicitudes de los usuarios se limiten a algo razonable, como tres o cuatro intentos en un período de 30 segundos, y de que los códigos caduquen todos juntos después de solo unos minutos. El uso de un código alfanumérico también puede mejorar la seguridad al añadir letras y números a las posibles contraseñas.
Por último, si es posible, evite utilizar nombres de usuario o valores secuenciales predecibles como ID de sesión. En su lugar, utilice un administrador de sesiones seguro del lado del servidor que genere un identificador de sesión aleatorio cada vez.
Implementar métodos de autenticación seguros es un poco más complicado que combatir la vulnerabilidad promedio. Sin embargo, dado que la autorización es tan importante para todas las aplicaciones, programas y API, vale la pena dedicar más tiempo a asegurarse de que se hace correctamente.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.


La autenticación suele actuar como puerta de entrada tanto a una aplicación como, potencialmente, al resto de la red, por lo que son objetivos tentadores para los atacantes. Si un proceso de autenticación se interrumpe o es vulnerable, es muy probable que los atacantes descubran esa debilidad y la exploten.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.


No es de extrañar que la autenticación fallida haya figurado en la lista OWASP de problemas de API; los mecanismos de autenticación son notoriamente difíciles de implementar correctamente. Además, los atacantes tienen una pequeña ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben estar expuestos a los usuarios, lo que les da la oportunidad de estudiarlos y buscar patrones o vulnerabilidades que puedan aprovechar.
Por último, dado que la autenticación suele actuar como puerta de entrada tanto a una aplicación como, potencialmente, al resto de la red, son objetivos tentadores para los atacantes. Si un proceso de autenticación se interrumpe o es vulnerable, es muy probable que los atacantes descubran esa debilidad y la exploten.
Por lo tanto, en este capítulo, vamos a aprender cómo excluir a los malos cuando se trata de problemas de autenticación. Si primero quieres poner a prueba tus habilidades, no te pierdas nuestro desafío gamificado:
¿Quieres mejorar tu puntuación? Quédate conmigo mientras lo analizamos.
¿Cuáles son algunos ejemplos de autenticación rota o mal configurada?
Un ejemplo en el que el problema puede no ser tan evidente es cuando un método de autenticación es vulnerable al exceso de credenciales o al uso de listas de nombres de usuario y contraseñas conocidos para infringir la seguridad. Incluso un método de autorización que normalmente es muy seguro, como la autenticación multifactorial, puede resultar vulnerable si las solicitudes no se limitan, limitan o supervisan de otro modo.
Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a/api/sistema/códigos de verificación y proporcionar un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío de mensajes de texto SMS en el que se envía un código de seis dígitos al teléfono del usuario, pero el campo de entrada no es limitado, se puede acceder a la aplicación en solo unos minutos. Un atacante solo tiene que enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta que encuentre la correcta.
En ese escenario, a primera vista, parece que tener una autenticación de dos factores mantendrá segura una aplicación. Sin embargo, dado que la entrada del usuario no tiene una velocidad limitada, la autenticación no funciona y es vulnerable.
En otro ejemplo, una aplicación puede usar objetos de usuario codificados como cookies de autenticación. Sin embargo, si un atacante con un acceso de usuario de bajo nivel decodifica esa cookie con Base64, podría descubrir cómo la cookie define las sesiones y los usuarios de la aplicación. Por ejemplo, es posible que vean el siguiente JSON una vez decodificado:
{
«nombre de usuario»: «ShadyGuy»,
«rol»: «usuario»
{
En ese momento, el usuario malintencionado podría cambiar su nombre de usuario, rol o ambos. Podría convertirse en otro usuario con un nivel de privilegios más alto cambiando un par de valores:
{
«nombre de usuario»: «GoodGuy»,
«rol»: «administrador»
{
En ese momento, si el atacante recodifica la información y la establece como el valor de la cookie, básicamente se convierte en el nuevo usuario con un nivel de permiso más alto. A menos que existan métodos para evitar un cambio de este tipo, es muy probable que la aplicación acepte la transformación.
Eliminación de la autenticación rota o mal configurada
Si la autenticación falla, es muy probable que la seguridad general se vea comprometida. Sin embargo, seguir algunas pautas importantes al codificar las aplicaciones puede ayudar a mantener todo seguro.
En primer lugar, asegúrese de incluir comprobaciones de autenticación en todas partes que permitan a los usuarios acceder a las funciones del programa. Si la verificación de autenticación no existe en absoluto, la batalla está perdida desde el principio.
En cuanto a las prácticas recomendadas, una buena cosa a tener en cuenta es evitar exponer los ID de sesión en la URL a la que pueden acceder los usuarios. En el segundo ejemplo anterior, relativo a la autenticación interrumpida, evitar que un atacante intente descifrar la cookie de sesión es mucho más fácil si nunca la descubre.
También es una buena idea implementar la autenticación multifactor. Esto se puede hacer de forma segura mediante el uso de tokens de hardware que generan contraseñas de forma algorítmica en plazos ajustados. Si no puedes proporcionar a tus usuarios dispositivos como esos, los mensajes de texto SMS también pueden funcionar. Sin embargo, debes asegurarte de que las solicitudes de los usuarios se limiten a algo razonable, como tres o cuatro intentos en un período de 30 segundos, y de que los códigos caduquen todos juntos después de solo unos minutos. El uso de un código alfanumérico también puede mejorar la seguridad al añadir letras y números a las posibles contraseñas.
Por último, si es posible, evite utilizar nombres de usuario o valores secuenciales predecibles como ID de sesión. En su lugar, utilice un administrador de sesiones seguro del lado del servidor que genere un identificador de sesión aleatorio cada vez.
Implementar métodos de autenticación seguros es un poco más complicado que combatir la vulnerabilidad promedio. Sin embargo, dado que la autorización es tan importante para todas las aplicaciones, programas y API, vale la pena dedicar más tiempo a asegurarse de que se hace correctamente.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

No es de extrañar que la autenticación fallida haya figurado en la lista OWASP de problemas de API; los mecanismos de autenticación son notoriamente difíciles de implementar correctamente. Además, los atacantes tienen una pequeña ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben estar expuestos a los usuarios, lo que les da la oportunidad de estudiarlos y buscar patrones o vulnerabilidades que puedan aprovechar.
Por último, dado que la autenticación suele actuar como puerta de entrada tanto a una aplicación como, potencialmente, al resto de la red, son objetivos tentadores para los atacantes. Si un proceso de autenticación se interrumpe o es vulnerable, es muy probable que los atacantes descubran esa debilidad y la exploten.
Por lo tanto, en este capítulo, vamos a aprender cómo excluir a los malos cuando se trata de problemas de autenticación. Si primero quieres poner a prueba tus habilidades, no te pierdas nuestro desafío gamificado:
¿Quieres mejorar tu puntuación? Quédate conmigo mientras lo analizamos.
¿Cuáles son algunos ejemplos de autenticación rota o mal configurada?
Un ejemplo en el que el problema puede no ser tan evidente es cuando un método de autenticación es vulnerable al exceso de credenciales o al uso de listas de nombres de usuario y contraseñas conocidos para infringir la seguridad. Incluso un método de autorización que normalmente es muy seguro, como la autenticación multifactorial, puede resultar vulnerable si las solicitudes no se limitan, limitan o supervisan de otro modo.
Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a/api/sistema/códigos de verificación y proporcionar un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío de mensajes de texto SMS en el que se envía un código de seis dígitos al teléfono del usuario, pero el campo de entrada no es limitado, se puede acceder a la aplicación en solo unos minutos. Un atacante solo tiene que enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta que encuentre la correcta.
En ese escenario, a primera vista, parece que tener una autenticación de dos factores mantendrá segura una aplicación. Sin embargo, dado que la entrada del usuario no tiene una velocidad limitada, la autenticación no funciona y es vulnerable.
En otro ejemplo, una aplicación puede usar objetos de usuario codificados como cookies de autenticación. Sin embargo, si un atacante con un acceso de usuario de bajo nivel decodifica esa cookie con Base64, podría descubrir cómo la cookie define las sesiones y los usuarios de la aplicación. Por ejemplo, es posible que vean el siguiente JSON una vez decodificado:
{
«nombre de usuario»: «ShadyGuy»,
«rol»: «usuario»
{
En ese momento, el usuario malintencionado podría cambiar su nombre de usuario, rol o ambos. Podría convertirse en otro usuario con un nivel de privilegios más alto cambiando un par de valores:
{
«nombre de usuario»: «GoodGuy»,
«rol»: «administrador»
{
En ese momento, si el atacante recodifica la información y la establece como el valor de la cookie, básicamente se convierte en el nuevo usuario con un nivel de permiso más alto. A menos que existan métodos para evitar un cambio de este tipo, es muy probable que la aplicación acepte la transformación.
Eliminación de la autenticación rota o mal configurada
Si la autenticación falla, es muy probable que la seguridad general se vea comprometida. Sin embargo, seguir algunas pautas importantes al codificar las aplicaciones puede ayudar a mantener todo seguro.
En primer lugar, asegúrese de incluir comprobaciones de autenticación en todas partes que permitan a los usuarios acceder a las funciones del programa. Si la verificación de autenticación no existe en absoluto, la batalla está perdida desde el principio.
En cuanto a las prácticas recomendadas, una buena cosa a tener en cuenta es evitar exponer los ID de sesión en la URL a la que pueden acceder los usuarios. En el segundo ejemplo anterior, relativo a la autenticación interrumpida, evitar que un atacante intente descifrar la cookie de sesión es mucho más fácil si nunca la descubre.
También es una buena idea implementar la autenticación multifactor. Esto se puede hacer de forma segura mediante el uso de tokens de hardware que generan contraseñas de forma algorítmica en plazos ajustados. Si no puedes proporcionar a tus usuarios dispositivos como esos, los mensajes de texto SMS también pueden funcionar. Sin embargo, debes asegurarte de que las solicitudes de los usuarios se limiten a algo razonable, como tres o cuatro intentos en un período de 30 segundos, y de que los códigos caduquen todos juntos después de solo unos minutos. El uso de un código alfanumérico también puede mejorar la seguridad al añadir letras y números a las posibles contraseñas.
Por último, si es posible, evite utilizar nombres de usuario o valores secuenciales predecibles como ID de sesión. En su lugar, utilice un administrador de sesiones seguro del lado del servidor que genere un identificador de sesión aleatorio cada vez.
Implementar métodos de autenticación seguros es un poco más complicado que combatir la vulnerabilidad promedio. Sin embargo, dado que la autorización es tan importante para todas las aplicaciones, programas y API, vale la pena dedicar más tiempo a asegurarse de que se hace correctamente.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserve una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
No es de extrañar que la autenticación fallida haya figurado en la lista OWASP de problemas de API; los mecanismos de autenticación son notoriamente difíciles de implementar correctamente. Además, los atacantes tienen una pequeña ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben estar expuestos a los usuarios, lo que les da la oportunidad de estudiarlos y buscar patrones o vulnerabilidades que puedan aprovechar.
Por último, dado que la autenticación suele actuar como puerta de entrada tanto a una aplicación como, potencialmente, al resto de la red, son objetivos tentadores para los atacantes. Si un proceso de autenticación se interrumpe o es vulnerable, es muy probable que los atacantes descubran esa debilidad y la exploten.
Por lo tanto, en este capítulo, vamos a aprender cómo excluir a los malos cuando se trata de problemas de autenticación. Si primero quieres poner a prueba tus habilidades, no te pierdas nuestro desafío gamificado:
¿Quieres mejorar tu puntuación? Quédate conmigo mientras lo analizamos.
¿Cuáles son algunos ejemplos de autenticación rota o mal configurada?
Un ejemplo en el que el problema puede no ser tan evidente es cuando un método de autenticación es vulnerable al exceso de credenciales o al uso de listas de nombres de usuario y contraseñas conocidos para infringir la seguridad. Incluso un método de autorización que normalmente es muy seguro, como la autenticación multifactorial, puede resultar vulnerable si las solicitudes no se limitan, limitan o supervisan de otro modo.
Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a/api/sistema/códigos de verificación y proporcionar un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío de mensajes de texto SMS en el que se envía un código de seis dígitos al teléfono del usuario, pero el campo de entrada no es limitado, se puede acceder a la aplicación en solo unos minutos. Un atacante solo tiene que enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta que encuentre la correcta.
En ese escenario, a primera vista, parece que tener una autenticación de dos factores mantendrá segura una aplicación. Sin embargo, dado que la entrada del usuario no tiene una velocidad limitada, la autenticación no funciona y es vulnerable.
En otro ejemplo, una aplicación puede usar objetos de usuario codificados como cookies de autenticación. Sin embargo, si un atacante con un acceso de usuario de bajo nivel decodifica esa cookie con Base64, podría descubrir cómo la cookie define las sesiones y los usuarios de la aplicación. Por ejemplo, es posible que vean el siguiente JSON una vez decodificado:
{
«nombre de usuario»: «ShadyGuy»,
«rol»: «usuario»
{
En ese momento, el usuario malintencionado podría cambiar su nombre de usuario, rol o ambos. Podría convertirse en otro usuario con un nivel de privilegios más alto cambiando un par de valores:
{
«nombre de usuario»: «GoodGuy»,
«rol»: «administrador»
{
En ese momento, si el atacante recodifica la información y la establece como el valor de la cookie, básicamente se convierte en el nuevo usuario con un nivel de permiso más alto. A menos que existan métodos para evitar un cambio de este tipo, es muy probable que la aplicación acepte la transformación.
Eliminación de la autenticación rota o mal configurada
Si la autenticación falla, es muy probable que la seguridad general se vea comprometida. Sin embargo, seguir algunas pautas importantes al codificar las aplicaciones puede ayudar a mantener todo seguro.
En primer lugar, asegúrese de incluir comprobaciones de autenticación en todas partes que permitan a los usuarios acceder a las funciones del programa. Si la verificación de autenticación no existe en absoluto, la batalla está perdida desde el principio.
En cuanto a las prácticas recomendadas, una buena cosa a tener en cuenta es evitar exponer los ID de sesión en la URL a la que pueden acceder los usuarios. En el segundo ejemplo anterior, relativo a la autenticación interrumpida, evitar que un atacante intente descifrar la cookie de sesión es mucho más fácil si nunca la descubre.
También es una buena idea implementar la autenticación multifactor. Esto se puede hacer de forma segura mediante el uso de tokens de hardware que generan contraseñas de forma algorítmica en plazos ajustados. Si no puedes proporcionar a tus usuarios dispositivos como esos, los mensajes de texto SMS también pueden funcionar. Sin embargo, debes asegurarte de que las solicitudes de los usuarios se limiten a algo razonable, como tres o cuatro intentos en un período de 30 segundos, y de que los códigos caduquen todos juntos después de solo unos minutos. El uso de un código alfanumérico también puede mejorar la seguridad al añadir letras y números a las posibles contraseñas.
Por último, si es posible, evite utilizar nombres de usuario o valores secuenciales predecibles como ID de sesión. En su lugar, utilice un administrador de sesiones seguro del lado del servidor que genere un identificador de sesión aleatorio cada vez.
Implementar métodos de autenticación seguros es un poco más complicado que combatir la vulnerabilidad promedio. Sin embargo, dado que la autorización es tan importante para todas las aplicaciones, programas y API, vale la pena dedicar más tiempo a asegurarse de que se hace correctamente.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Tabla de contenido
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Secure Code Warrior aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserve una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El habilitador 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.




%20(1).avif)
.avif)
