Los codificadores conquistan la seguridad: Share & Learn Series: Referencia directa a objetos inseguros
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.
En este post, aprenderemos:
- Qué es IDOR y cómo lo utilizan los atacantes
- Por qué el IDOR es peligroso
- Técnicas que pueden solucionar esta vulnerabilidad
Entender IDOR
Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.
Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.
En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.
¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?
Sepa por qué el IDOR es peligroso
Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.
La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.
Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).
Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.
Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.
Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.
Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.
Derrotar a IDOR
El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.
La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.
En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.
Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.
El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.
Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.
Con estas medidas de mitigación, el IDOR será cosa del pasado.
Asegure sus referencias
Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.
Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .
¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Encontrar a sus promotores
Katelynd Trinidad, responsable de planes de estudios e incorporación, explica los distintos métodos para localizar a los contribuidores de código en su organización y garantizar que reciban una formación segura sobre el código.
.png)
El poder de la marca en AppSec DevSec DevSecOps (¿Qué hay en un Acrynym?)
En AppSec, el impacto duradero de un programa exige algo más que tecnología: necesita una marca fuerte. Una identidad poderosa garantiza que sus iniciativas resuenen e impulsen un compromiso sostenido dentro de su comunidad de desarrolladores.
Agente de confianza: AI por Secure Code Warrior
Esta página presenta SCW Trust Agent: AI, un nuevo conjunto de capacidades que proporcionan una profunda observabilidad y gobernanza sobre las herramientas de codificación de IA. Descubra cómo nuestra solución correlaciona de forma única el uso de herramientas de IA con las habilidades de los desarrolladores para ayudarle a gestionar el riesgo, optimizar su SDLC y garantizar que cada línea de código generado por IA sea segura.
Recursos para empezar
.avif)
Codificación segura en la era de la IA: pruebe nuestros nuevos retos interactivos de IA
La codificación asistida por IA está cambiando el desarrollo. Prueba nuestros nuevos retos de IA al estilo Copilot para revisar, analizar y corregir código de forma segura en flujos de trabajo realistas.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
