
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., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.


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.

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Inhaltsverzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.




%20(1).avif)
.avif)
