SCW 아이콘
영웅 배경, 구분선 없음
블로그

Las 10 mejores API de la serie OWASP de Coders Conquer Security: autenticación rota

마티아스 마두, Ph.
게시일 : 2020년 9월 16일
마지막 업데이트: 2026년 3월 6일

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.

더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

데모 예약하기
공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 9월 16일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

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.


리소스 보기
리소스 보기

다음 양식을 작성하여 보고서를 다운로드하십시오.

귀하의 허락을 받아 당사 제품 또는 안전한 암호화 관련 주제에 대한 정보를 보내드리고자 합니다. 귀하의 개인정보는 항상 최대한 신중하게 처리하며, 마케팅 목적으로 타사에 판매하지 않을 것을 약속드립니다.

보내기
scw 성공 아이콘
scw 오류 아이콘
양식을 보내려면 '분석' 쿠키를 활성화하세요. 완료 후에는 언제든지 다시 비활성화해도 됩니다.

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.


웹 세미나 보기
시작하다
더 알아보세요

아래 링크를 클릭하고 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

보고서 보기데모 예약하기
리소스 보기
공유하기:
링크드인 브랜드사회적x 로고
더 알고 싶으신가요?

공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 9월 16일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

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.


목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.

데모 예약하기다운로드
공유하기:
링크드인 브랜드사회적x 로고
자원 센터

시작하기 위한 자료

더 많은 게시물
자원 센터

시작하기 위한 자료

더 많은 게시물