SCW图标
英雄背景无分隔线
博客

Coders Conquer Security: Serie Share & Learn: Insecure Direct Object Reference

Jaap Karan Singh
发布于 2019 年 3 月 14 日
最后更新于 2026年3月6日

Las URL son esenciales para navegar por todos los sitios web y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Si bien las URL son necesarias para que funcione la World Wide Web, también pueden representar un riesgo de seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

  • Qué es el IDOR y cómo lo utilizan los atacantes
  • Por qué el IDOR es peligroso
  • Técnicas que pueden corregir esta vulnerabilidad

Entender el IDOR

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, es posible que notes algo como «? id=12345" al final de una URL. El número, 12345, hace referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando no existe el control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Se trata de un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos que un atacante cambia el ID de la URL a 12344. En una aplicación que sea vulnerable al IDOR, el atacante podría ver los datos relacionados con 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 los registros de las aplicaciones en varios lugares. Una violación de esta magnitud puede ser importante, especialmente cuando se trata de datos confidenciales o de identificación personal.

La Oficina de Impuestos de Australia configurar un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, 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 comercial australiano (ABN). Da la casualidad de que este es un número fácilmente reconocible para cualquier empresa registrada. Este usuario decidió poner los números de otras empresas en la URL. ¡Le regalaron la información de su cuenta bancaria y sus datos personales!

Apple fue víctima recientemente de una vulnerabilidad de IDOR. Cuando se lanzó el iPad por primera vez, se filtraron 114 000 direcciones de correo electrónico de clientes. (Para ser justos, lo fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para admitir la conectividad 3G para iPads. El iPad envió un identificador almacenado en la tarjeta SIM al servicio de AT&T. Luego, el servicio devolvió la dirección de correo electrónico del usuario.

Desafortunadamente, estos identificadores eran simplemente números enteros secuenciales y, por lo tanto, eran fáciles de adivinar. Los atacantes revisaron los identificadores y robaron las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T intentó «proteger» el servicio devolviendo la dirección de correo electrónico solo si la solicitud es encabezado de agente de usuario indicó que provenía de un iPad. El agente de usuario es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades del IDOR pueden ser sutiles y disimuladas. Hablemos de cómo derrotarlos.

Derrotar a IDOR

El control de acceso es la clave para resolver el IDOR. Cuando un usuario solicita un registro específico, asegúrese de que está autorizado a ver el registro solicitado.

El uso de módulos de autorización centralizados es la mejor manera de hacerlo. Herramientas como Seguridad de primavera proporcionan autenticación y autorización sólidas y personalizables para las aplicaciones.

En pocas palabras: tenga un módulo en el que se basen todos los demás códigos para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores de registro de la base de datos reales 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 acceder a un registro con solo adivinar el siguiente identificador válido.

Y, por último, no confíe en nada que el usuario pueda manipular para proporcionar la autorización. AT&T intentó usar el encabezado usuario-agente para autorizar su servicio. No confíes en los encabezados HTTP, las cookies ni los parámetros GET y POST.

Con estas mitigaciones implementadas, el IDOR será cosa del pasado.

Proteja sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que se te acerquen sigilosamente cuando menos lo esperes. Comprueba siempre que los usuarios estén autorizados. No utilice identificadores de bases de datos reales. No dependa de los datos controlados por el usuario para obtener la autorización.

Desarrolla tu maestría consultando nuestra Recursos de aprendizaje. Si practicas cómo mitigar las vulnerabilidades del IDOR en el lenguaje que elijas, no tendrás problemas para encontrar y solucionar este problema en tus bases de código de producción. También puedes poner a prueba tus 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 ver la galería de otras amenazas de los delincuentes, visita Blog de Secure Code Warrior.

¿Estás listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate a ti mismo de forma gratuita: [Empieza aquí]

查看资源
查看资源

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.

感兴趣了解更多吗?

Jaap Karan Singh是一位安全编码布道者,首席辛格和Secure Code Warrior 的共同创始人。

了解更多

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

预约演示
分享到:
领英品牌社交x 标志
作者
Jaap Karan Singh
2019年3月14日发布

Jaap Karan Singh是一位安全编码布道者,首席辛格和Secure Code Warrior 的共同创始人。

分享到:
领英品牌社交x 标志

Las URL son esenciales para navegar por todos los sitios web y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Si bien las URL son necesarias para que funcione la World Wide Web, también pueden representar un riesgo de seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

  • Qué es el IDOR y cómo lo utilizan los atacantes
  • Por qué el IDOR es peligroso
  • Técnicas que pueden corregir esta vulnerabilidad

Entender el IDOR

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, es posible que notes algo como «? id=12345" al final de una URL. El número, 12345, hace referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando no existe el control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Se trata de un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos que un atacante cambia el ID de la URL a 12344. En una aplicación que sea vulnerable al IDOR, el atacante podría ver los datos relacionados con 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 los registros de las aplicaciones en varios lugares. Una violación de esta magnitud puede ser importante, especialmente cuando se trata de datos confidenciales o de identificación personal.

La Oficina de Impuestos de Australia configurar un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, 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 comercial australiano (ABN). Da la casualidad de que este es un número fácilmente reconocible para cualquier empresa registrada. Este usuario decidió poner los números de otras empresas en la URL. ¡Le regalaron la información de su cuenta bancaria y sus datos personales!

Apple fue víctima recientemente de una vulnerabilidad de IDOR. Cuando se lanzó el iPad por primera vez, se filtraron 114 000 direcciones de correo electrónico de clientes. (Para ser justos, lo fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para admitir la conectividad 3G para iPads. El iPad envió un identificador almacenado en la tarjeta SIM al servicio de AT&T. Luego, el servicio devolvió la dirección de correo electrónico del usuario.

Desafortunadamente, estos identificadores eran simplemente números enteros secuenciales y, por lo tanto, eran fáciles de adivinar. Los atacantes revisaron los identificadores y robaron las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T intentó «proteger» el servicio devolviendo la dirección de correo electrónico solo si la solicitud es encabezado de agente de usuario indicó que provenía de un iPad. El agente de usuario es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades del IDOR pueden ser sutiles y disimuladas. Hablemos de cómo derrotarlos.

Derrotar a IDOR

El control de acceso es la clave para resolver el IDOR. Cuando un usuario solicita un registro específico, asegúrese de que está autorizado a ver el registro solicitado.

El uso de módulos de autorización centralizados es la mejor manera de hacerlo. Herramientas como Seguridad de primavera proporcionan autenticación y autorización sólidas y personalizables para las aplicaciones.

En pocas palabras: tenga un módulo en el que se basen todos los demás códigos para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores de registro de la base de datos reales 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 acceder a un registro con solo adivinar el siguiente identificador válido.

Y, por último, no confíe en nada que el usuario pueda manipular para proporcionar la autorización. AT&T intentó usar el encabezado usuario-agente para autorizar su servicio. No confíes en los encabezados HTTP, las cookies ni los parámetros GET y POST.

Con estas mitigaciones implementadas, el IDOR será cosa del pasado.

Proteja sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que se te acerquen sigilosamente cuando menos lo esperes. Comprueba siempre que los usuarios estén autorizados. No utilice identificadores de bases de datos reales. No dependa de los datos controlados por el usuario para obtener la autorización.

Desarrolla tu maestría consultando nuestra Recursos de aprendizaje. Si practicas cómo mitigar las vulnerabilidades del IDOR en el lenguaje que elijas, no tendrás problemas para encontrar y solucionar este problema en tus bases de código de producción. También puedes poner a prueba tus 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 ver la galería de otras amenazas de los delincuentes, visita Blog de Secure Code Warrior.

¿Estás listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate a ti mismo de forma gratuita: [Empieza aquí]

查看资源
查看资源

请填写以下表格以下载报告

我们希望获得您的许可,以便向您发送有关我们产品或安全编码相关主题的信息。我们将始终以最高标准谨慎处理您的个人数据,绝不会出于营销目的将其出售给其他公司。

发送
scw 成功图标
SCW 错误图标
要提交表单,请启用「分析」cookie。完成后请随时将其重新禁用。

Las URL son esenciales para navegar por todos los sitios web y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Si bien las URL son necesarias para que funcione la World Wide Web, también pueden representar un riesgo de seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

  • Qué es el IDOR y cómo lo utilizan los atacantes
  • Por qué el IDOR es peligroso
  • Técnicas que pueden corregir esta vulnerabilidad

Entender el IDOR

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, es posible que notes algo como «? id=12345" al final de una URL. El número, 12345, hace referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando no existe el control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Se trata de un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos que un atacante cambia el ID de la URL a 12344. En una aplicación que sea vulnerable al IDOR, el atacante podría ver los datos relacionados con 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 los registros de las aplicaciones en varios lugares. Una violación de esta magnitud puede ser importante, especialmente cuando se trata de datos confidenciales o de identificación personal.

La Oficina de Impuestos de Australia configurar un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, 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 comercial australiano (ABN). Da la casualidad de que este es un número fácilmente reconocible para cualquier empresa registrada. Este usuario decidió poner los números de otras empresas en la URL. ¡Le regalaron la información de su cuenta bancaria y sus datos personales!

Apple fue víctima recientemente de una vulnerabilidad de IDOR. Cuando se lanzó el iPad por primera vez, se filtraron 114 000 direcciones de correo electrónico de clientes. (Para ser justos, lo fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para admitir la conectividad 3G para iPads. El iPad envió un identificador almacenado en la tarjeta SIM al servicio de AT&T. Luego, el servicio devolvió la dirección de correo electrónico del usuario.

Desafortunadamente, estos identificadores eran simplemente números enteros secuenciales y, por lo tanto, eran fáciles de adivinar. Los atacantes revisaron los identificadores y robaron las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T intentó «proteger» el servicio devolviendo la dirección de correo electrónico solo si la solicitud es encabezado de agente de usuario indicó que provenía de un iPad. El agente de usuario es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades del IDOR pueden ser sutiles y disimuladas. Hablemos de cómo derrotarlos.

Derrotar a IDOR

El control de acceso es la clave para resolver el IDOR. Cuando un usuario solicita un registro específico, asegúrese de que está autorizado a ver el registro solicitado.

El uso de módulos de autorización centralizados es la mejor manera de hacerlo. Herramientas como Seguridad de primavera proporcionan autenticación y autorización sólidas y personalizables para las aplicaciones.

En pocas palabras: tenga un módulo en el que se basen todos los demás códigos para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores de registro de la base de datos reales 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 acceder a un registro con solo adivinar el siguiente identificador válido.

Y, por último, no confíe en nada que el usuario pueda manipular para proporcionar la autorización. AT&T intentó usar el encabezado usuario-agente para autorizar su servicio. No confíes en los encabezados HTTP, las cookies ni los parámetros GET y POST.

Con estas mitigaciones implementadas, el IDOR será cosa del pasado.

Proteja sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que se te acerquen sigilosamente cuando menos lo esperes. Comprueba siempre que los usuarios estén autorizados. No utilice identificadores de bases de datos reales. No dependa de los datos controlados por el usuario para obtener la autorización.

Desarrolla tu maestría consultando nuestra Recursos de aprendizaje. Si practicas cómo mitigar las vulnerabilidades del IDOR en el lenguaje que elijas, no tendrás problemas para encontrar y solucionar este problema en tus bases de código de producción. También puedes poner a prueba tus 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 ver la galería de otras amenazas de los delincuentes, visita Blog de Secure Code Warrior.

¿Estás listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate a ti mismo de forma gratuita: [Empieza aquí]

观看网络研讨会
开始
了解更多

点击下方链接,下载此资源的PDF文件。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

查看报告预约演示
查看资源
分享到:
领英品牌社交x 标志
感兴趣了解更多吗?

分享到:
领英品牌社交x 标志
作者
Jaap Karan Singh
2019年3月14日发布

Jaap Karan Singh是一位安全编码布道者,首席辛格和Secure Code Warrior 的共同创始人。

分享到:
领英品牌社交x 标志

Las URL son esenciales para navegar por todos los sitios web y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Si bien las URL son necesarias para que funcione la World Wide Web, también pueden representar un riesgo de seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

  • Qué es el IDOR y cómo lo utilizan los atacantes
  • Por qué el IDOR es peligroso
  • Técnicas que pueden corregir esta vulnerabilidad

Entender el IDOR

Una referencia directa a un objeto se produce cuando se hace referencia a un registro específico (el «objeto») dentro de una aplicación. Por lo general, adopta la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, es posible que notes algo como «? id=12345" al final de una URL. El número, 12345, hace referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando no existe el control de acceso para los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Se trata de un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, supongamos que un atacante cambia el ID de la URL a 12344. En una aplicación que sea vulnerable al IDOR, el atacante podría ver los datos relacionados con 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 los registros de las aplicaciones en varios lugares. Una violación de esta magnitud puede ser importante, especialmente cuando se trata de datos confidenciales o de identificación personal.

La Oficina de Impuestos de Australia configurar un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desafortunadamente, 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 comercial australiano (ABN). Da la casualidad de que este es un número fácilmente reconocible para cualquier empresa registrada. Este usuario decidió poner los números de otras empresas en la URL. ¡Le regalaron la información de su cuenta bancaria y sus datos personales!

Apple fue víctima recientemente de una vulnerabilidad de IDOR. Cuando se lanzó el iPad por primera vez, se filtraron 114 000 direcciones de correo electrónico de clientes. (Para ser justos, lo fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para admitir la conectividad 3G para iPads. El iPad envió un identificador almacenado en la tarjeta SIM al servicio de AT&T. Luego, el servicio devolvió la dirección de correo electrónico del usuario.

Desafortunadamente, estos identificadores eran simplemente números enteros secuenciales y, por lo tanto, eran fáciles de adivinar. Los atacantes revisaron los identificadores y robaron las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T intentó «proteger» el servicio devolviendo la dirección de correo electrónico solo si la solicitud es encabezado de agente de usuario indicó que provenía de un iPad. El agente de usuario es solo un valor de cadena que puede manipularse fácilmente.

Las vulnerabilidades del IDOR pueden ser sutiles y disimuladas. Hablemos de cómo derrotarlos.

Derrotar a IDOR

El control de acceso es la clave para resolver el IDOR. Cuando un usuario solicita un registro específico, asegúrese de que está autorizado a ver el registro solicitado.

El uso de módulos de autorización centralizados es la mejor manera de hacerlo. Herramientas como Seguridad de primavera proporcionan autenticación y autorización sólidas y personalizables para las aplicaciones.

En pocas palabras: tenga un módulo en el que se basen todos los demás códigos para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores de registro de la base de datos reales 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 acceder a un registro con solo adivinar el siguiente identificador válido.

Y, por último, no confíe en nada que el usuario pueda manipular para proporcionar la autorización. AT&T intentó usar el encabezado usuario-agente para autorizar su servicio. No confíes en los encabezados HTTP, las cookies ni los parámetros GET y POST.

Con estas mitigaciones implementadas, el IDOR será cosa del pasado.

Proteja sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que se te acerquen sigilosamente cuando menos lo esperes. Comprueba siempre que los usuarios estén autorizados. No utilice identificadores de bases de datos reales. No dependa de los datos controlados por el usuario para obtener la autorización.

Desarrolla tu maestría consultando nuestra Recursos de aprendizaje. Si practicas cómo mitigar las vulnerabilidades del IDOR en el lenguaje que elijas, no tendrás problemas para encontrar y solucionar este problema en tus bases de código de producción. También puedes poner a prueba tus 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 ver la galería de otras amenazas de los delincuentes, visita Blog de Secure Code Warrior.

¿Estás listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate a ti mismo de forma gratuita: [Empieza aquí]

目录

下载PDF
查看资源
感兴趣了解更多吗?

Jaap Karan Singh是一位安全编码布道者,首席辛格和Secure Code Warrior 的共同创始人。

了解更多

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

预约演示下载
分享到:
领英品牌社交x 标志
资源中心

入门资源

更多出版物
资源中心

入门资源

更多出版物