SCW アイコン
ヒーロー背景(区切りなし)
ブログ

Les codeurs conquièrent la sécurité : série Share & Learn : Référence directe d'objets non sécurisée

Jaap Karan Singh
2019年3月14日 掲載
最終更新日: 2026年3月8日

Les URL sont essentielles pour naviguer sur tous les sites Web et applications Web que nous connaissons et aimons. Leur fonction de base est d'identifier où se trouvent les ressources et comment les récupérer. Bien que les URL soient nécessaires au fonctionnement du World Wide Web, elles peuvent également présenter un risque de sécurité si elles ne sont pas correctement sécurisées.

Dans cet article, nous allons apprendre :

  • Qu'est-ce qu'idor et comment les attaquants l'utilisent
  • IDORが危険な理由
  • Techniques permettant de corriger cette vulnérabilité

Comprenez IDOR

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

Par exemple, vous allez peut-être remarquer quelque chose comme « ? id=12345" à la fin d'une URL. Le numéro 12345 fait référence à un enregistrement spécifique. Les failles de sécurité apparaissent lorsque le contrôle d'accès n'est pas présent pour les enregistrements individuels. Cela permet aux utilisateurs d'accéder à des enregistrements et à des données qu'ils ne devraient pas voir. Il s'agit d'une attaque qui nécessite un niveau de compétence relativement faible.

Dans ce cas, supposons qu'un attaquant change l'ID de l'URL en 12344. Dans une application vulnérable à IDOR, l'attaquant pourrait voir les données relatives à cet enregistrement.

Quels dégâts ce type de vulnérabilité peut-il réellement causer ?

Découvrez pourquoi L'idor est dangereux

Lorsque les développeurs ne font pas attention, ils peuvent concevoir un système qui affiche et divulgue les enregistrements des applications à divers endroits. Une violation de cette ampleur peut être importante, en particulier lorsqu'il s'agit de données sensibles ou d'informations d'identification personnelle.

Le bureau des impôts australien create a Web site pour aider les entreprises à percevoir une nouvelle taxe. Malheureusement, il était livré avec la fonctionnalité indésirable d'une vulnérabilité IDOR. Un utilisateur curieux s'est rendu compte que les URL du site contenaient son numéro d'entreprise australien, ou ABN. Il se trouve qu'il s'agit d'un numéro facilement détectable pour toute entreprise enregistrée. Cet utilisateur a décidé de saisir les numéros d'autres entreprises dans l'URL. Il a reçu leurs informations de compte bancaire et leurs informations personnelles !

Apple a récemment été victime d'une vulnérabilité IDOR. Lorsque l'iPad est sorti pour la première fois, 114 000 adresses e-mail de clients ont été divulguées. (Pour être honnête, c'était plutôt une erreur de la part d'AT&T).

Vous voyez, AT&T a créé un service pour prendre en charge la connectivité 3G pour les iPad. L'iPad a envoyé un identifiant stocké sur la carte SIM au service d'AT&T. Le service a ensuite renvoyé l'adresse e-mail de l'utilisateur.

Malheureusement, ces identifiants n'étaient que des entiers séquentiels et étaient donc facilement devinables. Les attaquants ont parcouru les identifiants et ont volé les adresses e-mail.

Une autre erreur est que le service d'AT & T a essayé de « sécuriser » le service en ne renvoyant l'adresse e-mail que si la demande en-tête user-agent a indiqué qu'il provenait d'un iPad. L'agent utilisateur n'est qu'une valeur de chaîne qui peut être facilement manipulée.

Les vulnérabilités d'Idor peuvent être subtiles et sournoises. Discutons de la manière de les vaincre.

Vaincre l'IDOR

Le contrôle d'accès est la clé pour résoudre les problèmes d'Idor. Lorsqu'un utilisateur demande un enregistrement spécifique, assurez-vous qu'il est autorisé à consulter l'enregistrement demandé.

L'utilisation de modules d'autorisation centralisés est le meilleur moyen d'y parvenir. Des outils tels que Printanière Security fournir une authentification et une autorisation robustes et personnalisables pour les applications.

Conclusion : ayez un module sur lequel tous les autres codes s'appuient pour effectuer des contrôles d'autorisation.

Une autre mesure d'atténuation courante est l'utilisation de références de substitution. Au lieu d'utiliser les identifiants d'enregistrement de base de données réels dans votre URL, vous pouvez créer des nombres aléatoires qui correspondent aux enregistrements réels.

L'utilisation de références de substitution garantit qu'un attaquant ne peut pas accéder à un enregistrement simplement en devinant le prochain identifiant valide.

Enfin, ne vous fiez à rien que l'utilisateur puisse manipuler pour fournir une autorisation. AT&T a essayé d'utiliser l'en-tête de l'agent utilisateur pour autoriser son service. Ne vous fiez pas aux en-têtes HTTP, aux cookies ou aux paramètres GET et POST.

Une fois ces mesures d'atténuation mises en place, L'idor appartiendra au passé.

Sécurisez vos références

Les références directes aux objets non sécurisés constituent l'une des vulnérabilités les plus faciles à exploiter. Ne les laissez pas vous surprendre au moment où vous vous y attendez le moins. Vérifiez toujours que les utilisateurs sont autorisés. N'utilisez pas de véritables identifiants de base de données. Ne vous fiez pas aux données contrôlées par l'utilisateur pour l'autorisation.

Développez votre maîtrise en consultant notre Pédagogiques. En vous entraînant à atténuer les vulnérabilités IDOR dans le langage de votre choix, vous n'aurez aucun problème à trouver et à résoudre ce problème dans vos bases de code de production. Vous pouvez également mettre vos nouvelles connaissances en matière de défense à l'épreuve grâce à une démonstration gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.

Êtes-vous prêt à vous défendre contre les attaques d'Idor dès maintenant ? Rendez-vous sur la plateforme et lancez-vous un défi gratuit : [Commencez ici]

リソースを表示する
リソースを表示する

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

さらに詳しく知りたいですか?

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

もっと詳しく

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

デモを予約する
共有する:
リンクトインのブランドソーシャルx ロゴ
作者
Jaap Karan Singh
2019年3月14日発行

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

共有する:
リンクトインのブランドソーシャルx ロゴ

Les URL sont essentielles pour naviguer sur tous les sites Web et applications Web que nous connaissons et aimons. Leur fonction de base est d'identifier où se trouvent les ressources et comment les récupérer. Bien que les URL soient nécessaires au fonctionnement du World Wide Web, elles peuvent également présenter un risque de sécurité si elles ne sont pas correctement sécurisées.

Dans cet article, nous allons apprendre :

  • Qu'est-ce qu'idor et comment les attaquants l'utilisent
  • IDORが危険な理由
  • Techniques permettant de corriger cette vulnérabilité

Comprenez IDOR

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

Par exemple, vous allez peut-être remarquer quelque chose comme « ? id=12345" à la fin d'une URL. Le numéro 12345 fait référence à un enregistrement spécifique. Les failles de sécurité apparaissent lorsque le contrôle d'accès n'est pas présent pour les enregistrements individuels. Cela permet aux utilisateurs d'accéder à des enregistrements et à des données qu'ils ne devraient pas voir. Il s'agit d'une attaque qui nécessite un niveau de compétence relativement faible.

Dans ce cas, supposons qu'un attaquant change l'ID de l'URL en 12344. Dans une application vulnérable à IDOR, l'attaquant pourrait voir les données relatives à cet enregistrement.

Quels dégâts ce type de vulnérabilité peut-il réellement causer ?

Découvrez pourquoi L'idor est dangereux

Lorsque les développeurs ne font pas attention, ils peuvent concevoir un système qui affiche et divulgue les enregistrements des applications à divers endroits. Une violation de cette ampleur peut être importante, en particulier lorsqu'il s'agit de données sensibles ou d'informations d'identification personnelle.

Le bureau des impôts australien create a Web site pour aider les entreprises à percevoir une nouvelle taxe. Malheureusement, il était livré avec la fonctionnalité indésirable d'une vulnérabilité IDOR. Un utilisateur curieux s'est rendu compte que les URL du site contenaient son numéro d'entreprise australien, ou ABN. Il se trouve qu'il s'agit d'un numéro facilement détectable pour toute entreprise enregistrée. Cet utilisateur a décidé de saisir les numéros d'autres entreprises dans l'URL. Il a reçu leurs informations de compte bancaire et leurs informations personnelles !

Apple a récemment été victime d'une vulnérabilité IDOR. Lorsque l'iPad est sorti pour la première fois, 114 000 adresses e-mail de clients ont été divulguées. (Pour être honnête, c'était plutôt une erreur de la part d'AT&T).

Vous voyez, AT&T a créé un service pour prendre en charge la connectivité 3G pour les iPad. L'iPad a envoyé un identifiant stocké sur la carte SIM au service d'AT&T. Le service a ensuite renvoyé l'adresse e-mail de l'utilisateur.

Malheureusement, ces identifiants n'étaient que des entiers séquentiels et étaient donc facilement devinables. Les attaquants ont parcouru les identifiants et ont volé les adresses e-mail.

Une autre erreur est que le service d'AT & T a essayé de « sécuriser » le service en ne renvoyant l'adresse e-mail que si la demande en-tête user-agent a indiqué qu'il provenait d'un iPad. L'agent utilisateur n'est qu'une valeur de chaîne qui peut être facilement manipulée.

Les vulnérabilités d'Idor peuvent être subtiles et sournoises. Discutons de la manière de les vaincre.

Vaincre l'IDOR

Le contrôle d'accès est la clé pour résoudre les problèmes d'Idor. Lorsqu'un utilisateur demande un enregistrement spécifique, assurez-vous qu'il est autorisé à consulter l'enregistrement demandé.

L'utilisation de modules d'autorisation centralisés est le meilleur moyen d'y parvenir. Des outils tels que Printanière Security fournir une authentification et une autorisation robustes et personnalisables pour les applications.

Conclusion : ayez un module sur lequel tous les autres codes s'appuient pour effectuer des contrôles d'autorisation.

Une autre mesure d'atténuation courante est l'utilisation de références de substitution. Au lieu d'utiliser les identifiants d'enregistrement de base de données réels dans votre URL, vous pouvez créer des nombres aléatoires qui correspondent aux enregistrements réels.

L'utilisation de références de substitution garantit qu'un attaquant ne peut pas accéder à un enregistrement simplement en devinant le prochain identifiant valide.

Enfin, ne vous fiez à rien que l'utilisateur puisse manipuler pour fournir une autorisation. AT&T a essayé d'utiliser l'en-tête de l'agent utilisateur pour autoriser son service. Ne vous fiez pas aux en-têtes HTTP, aux cookies ou aux paramètres GET et POST.

Une fois ces mesures d'atténuation mises en place, L'idor appartiendra au passé.

Sécurisez vos références

Les références directes aux objets non sécurisés constituent l'une des vulnérabilités les plus faciles à exploiter. Ne les laissez pas vous surprendre au moment où vous vous y attendez le moins. Vérifiez toujours que les utilisateurs sont autorisés. N'utilisez pas de véritables identifiants de base de données. Ne vous fiez pas aux données contrôlées par l'utilisateur pour l'autorisation.

Développez votre maîtrise en consultant notre Pédagogiques. En vous entraînant à atténuer les vulnérabilités IDOR dans le langage de votre choix, vous n'aurez aucun problème à trouver et à résoudre ce problème dans vos bases de code de production. Vous pouvez également mettre vos nouvelles connaissances en matière de défense à l'épreuve grâce à une démonstration gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.

Êtes-vous prêt à vous défendre contre les attaques d'Idor dès maintenant ? Rendez-vous sur la plateforme et lancez-vous un défi gratuit : [Commencez ici]

リソースを表示する
リソースを表示する

以下のフォームに記入してレポートをダウンロードしてください

当社製品および/またはセキュアコーディング関連の情報をお送りするにあたり、ご承諾を頂戴できれば幸いです。お客様の個人情報は常に細心の注意をもって取り扱い、マーケティング目的で他社に販売することは一切ございません。

提出する
SCW成功アイコン
SCWエラーアイコン
フォームを送信するには、Analyticsクッキーを有効にしてください。完了後は再度無効化しても構いません。

Les URL sont essentielles pour naviguer sur tous les sites Web et applications Web que nous connaissons et aimons. Leur fonction de base est d'identifier où se trouvent les ressources et comment les récupérer. Bien que les URL soient nécessaires au fonctionnement du World Wide Web, elles peuvent également présenter un risque de sécurité si elles ne sont pas correctement sécurisées.

Dans cet article, nous allons apprendre :

  • Qu'est-ce qu'idor et comment les attaquants l'utilisent
  • IDORが危険な理由
  • Techniques permettant de corriger cette vulnérabilité

Comprenez IDOR

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

Par exemple, vous allez peut-être remarquer quelque chose comme « ? id=12345" à la fin d'une URL. Le numéro 12345 fait référence à un enregistrement spécifique. Les failles de sécurité apparaissent lorsque le contrôle d'accès n'est pas présent pour les enregistrements individuels. Cela permet aux utilisateurs d'accéder à des enregistrements et à des données qu'ils ne devraient pas voir. Il s'agit d'une attaque qui nécessite un niveau de compétence relativement faible.

Dans ce cas, supposons qu'un attaquant change l'ID de l'URL en 12344. Dans une application vulnérable à IDOR, l'attaquant pourrait voir les données relatives à cet enregistrement.

Quels dégâts ce type de vulnérabilité peut-il réellement causer ?

Découvrez pourquoi L'idor est dangereux

Lorsque les développeurs ne font pas attention, ils peuvent concevoir un système qui affiche et divulgue les enregistrements des applications à divers endroits. Une violation de cette ampleur peut être importante, en particulier lorsqu'il s'agit de données sensibles ou d'informations d'identification personnelle.

Le bureau des impôts australien create a Web site pour aider les entreprises à percevoir une nouvelle taxe. Malheureusement, il était livré avec la fonctionnalité indésirable d'une vulnérabilité IDOR. Un utilisateur curieux s'est rendu compte que les URL du site contenaient son numéro d'entreprise australien, ou ABN. Il se trouve qu'il s'agit d'un numéro facilement détectable pour toute entreprise enregistrée. Cet utilisateur a décidé de saisir les numéros d'autres entreprises dans l'URL. Il a reçu leurs informations de compte bancaire et leurs informations personnelles !

Apple a récemment été victime d'une vulnérabilité IDOR. Lorsque l'iPad est sorti pour la première fois, 114 000 adresses e-mail de clients ont été divulguées. (Pour être honnête, c'était plutôt une erreur de la part d'AT&T).

Vous voyez, AT&T a créé un service pour prendre en charge la connectivité 3G pour les iPad. L'iPad a envoyé un identifiant stocké sur la carte SIM au service d'AT&T. Le service a ensuite renvoyé l'adresse e-mail de l'utilisateur.

Malheureusement, ces identifiants n'étaient que des entiers séquentiels et étaient donc facilement devinables. Les attaquants ont parcouru les identifiants et ont volé les adresses e-mail.

Une autre erreur est que le service d'AT & T a essayé de « sécuriser » le service en ne renvoyant l'adresse e-mail que si la demande en-tête user-agent a indiqué qu'il provenait d'un iPad. L'agent utilisateur n'est qu'une valeur de chaîne qui peut être facilement manipulée.

Les vulnérabilités d'Idor peuvent être subtiles et sournoises. Discutons de la manière de les vaincre.

Vaincre l'IDOR

Le contrôle d'accès est la clé pour résoudre les problèmes d'Idor. Lorsqu'un utilisateur demande un enregistrement spécifique, assurez-vous qu'il est autorisé à consulter l'enregistrement demandé.

L'utilisation de modules d'autorisation centralisés est le meilleur moyen d'y parvenir. Des outils tels que Printanière Security fournir une authentification et une autorisation robustes et personnalisables pour les applications.

Conclusion : ayez un module sur lequel tous les autres codes s'appuient pour effectuer des contrôles d'autorisation.

Une autre mesure d'atténuation courante est l'utilisation de références de substitution. Au lieu d'utiliser les identifiants d'enregistrement de base de données réels dans votre URL, vous pouvez créer des nombres aléatoires qui correspondent aux enregistrements réels.

L'utilisation de références de substitution garantit qu'un attaquant ne peut pas accéder à un enregistrement simplement en devinant le prochain identifiant valide.

Enfin, ne vous fiez à rien que l'utilisateur puisse manipuler pour fournir une autorisation. AT&T a essayé d'utiliser l'en-tête de l'agent utilisateur pour autoriser son service. Ne vous fiez pas aux en-têtes HTTP, aux cookies ou aux paramètres GET et POST.

Une fois ces mesures d'atténuation mises en place, L'idor appartiendra au passé.

Sécurisez vos références

Les références directes aux objets non sécurisés constituent l'une des vulnérabilités les plus faciles à exploiter. Ne les laissez pas vous surprendre au moment où vous vous y attendez le moins. Vérifiez toujours que les utilisateurs sont autorisés. N'utilisez pas de véritables identifiants de base de données. Ne vous fiez pas aux données contrôlées par l'utilisateur pour l'autorisation.

Développez votre maîtrise en consultant notre Pédagogiques. En vous entraînant à atténuer les vulnérabilités IDOR dans le langage de votre choix, vous n'aurez aucun problème à trouver et à résoudre ce problème dans vos bases de code de production. Vous pouvez également mettre vos nouvelles connaissances en matière de défense à l'épreuve grâce à une démonstration gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.

Êtes-vous prêt à vous défendre contre les attaques d'Idor dès maintenant ? Rendez-vous sur la plateforme et lancez-vous un défi gratuit : [Commencez ici]

ウェビナーを表示する
始めましょう
もっと詳しく

以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

レポートを表示するデモを予約する
PDFをダウンロード
リソースを表示する
共有する:
リンクトインのブランドソーシャルx ロゴ
さらに詳しく知りたいですか?

共有する:
リンクトインのブランドソーシャルx ロゴ
作者
Jaap Karan Singh
2019年3月14日発行

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

共有する:
リンクトインのブランドソーシャルx ロゴ

Les URL sont essentielles pour naviguer sur tous les sites Web et applications Web que nous connaissons et aimons. Leur fonction de base est d'identifier où se trouvent les ressources et comment les récupérer. Bien que les URL soient nécessaires au fonctionnement du World Wide Web, elles peuvent également présenter un risque de sécurité si elles ne sont pas correctement sécurisées.

Dans cet article, nous allons apprendre :

  • Qu'est-ce qu'idor et comment les attaquants l'utilisent
  • IDORが危険な理由
  • Techniques permettant de corriger cette vulnérabilité

Comprenez IDOR

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l' « objet ») est référencé dans une application. Il prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

Par exemple, vous allez peut-être remarquer quelque chose comme « ? id=12345" à la fin d'une URL. Le numéro 12345 fait référence à un enregistrement spécifique. Les failles de sécurité apparaissent lorsque le contrôle d'accès n'est pas présent pour les enregistrements individuels. Cela permet aux utilisateurs d'accéder à des enregistrements et à des données qu'ils ne devraient pas voir. Il s'agit d'une attaque qui nécessite un niveau de compétence relativement faible.

Dans ce cas, supposons qu'un attaquant change l'ID de l'URL en 12344. Dans une application vulnérable à IDOR, l'attaquant pourrait voir les données relatives à cet enregistrement.

Quels dégâts ce type de vulnérabilité peut-il réellement causer ?

Découvrez pourquoi L'idor est dangereux

Lorsque les développeurs ne font pas attention, ils peuvent concevoir un système qui affiche et divulgue les enregistrements des applications à divers endroits. Une violation de cette ampleur peut être importante, en particulier lorsqu'il s'agit de données sensibles ou d'informations d'identification personnelle.

Le bureau des impôts australien create a Web site pour aider les entreprises à percevoir une nouvelle taxe. Malheureusement, il était livré avec la fonctionnalité indésirable d'une vulnérabilité IDOR. Un utilisateur curieux s'est rendu compte que les URL du site contenaient son numéro d'entreprise australien, ou ABN. Il se trouve qu'il s'agit d'un numéro facilement détectable pour toute entreprise enregistrée. Cet utilisateur a décidé de saisir les numéros d'autres entreprises dans l'URL. Il a reçu leurs informations de compte bancaire et leurs informations personnelles !

Apple a récemment été victime d'une vulnérabilité IDOR. Lorsque l'iPad est sorti pour la première fois, 114 000 adresses e-mail de clients ont été divulguées. (Pour être honnête, c'était plutôt une erreur de la part d'AT&T).

Vous voyez, AT&T a créé un service pour prendre en charge la connectivité 3G pour les iPad. L'iPad a envoyé un identifiant stocké sur la carte SIM au service d'AT&T. Le service a ensuite renvoyé l'adresse e-mail de l'utilisateur.

Malheureusement, ces identifiants n'étaient que des entiers séquentiels et étaient donc facilement devinables. Les attaquants ont parcouru les identifiants et ont volé les adresses e-mail.

Une autre erreur est que le service d'AT & T a essayé de « sécuriser » le service en ne renvoyant l'adresse e-mail que si la demande en-tête user-agent a indiqué qu'il provenait d'un iPad. L'agent utilisateur n'est qu'une valeur de chaîne qui peut être facilement manipulée.

Les vulnérabilités d'Idor peuvent être subtiles et sournoises. Discutons de la manière de les vaincre.

Vaincre l'IDOR

Le contrôle d'accès est la clé pour résoudre les problèmes d'Idor. Lorsqu'un utilisateur demande un enregistrement spécifique, assurez-vous qu'il est autorisé à consulter l'enregistrement demandé.

L'utilisation de modules d'autorisation centralisés est le meilleur moyen d'y parvenir. Des outils tels que Printanière Security fournir une authentification et une autorisation robustes et personnalisables pour les applications.

Conclusion : ayez un module sur lequel tous les autres codes s'appuient pour effectuer des contrôles d'autorisation.

Une autre mesure d'atténuation courante est l'utilisation de références de substitution. Au lieu d'utiliser les identifiants d'enregistrement de base de données réels dans votre URL, vous pouvez créer des nombres aléatoires qui correspondent aux enregistrements réels.

L'utilisation de références de substitution garantit qu'un attaquant ne peut pas accéder à un enregistrement simplement en devinant le prochain identifiant valide.

Enfin, ne vous fiez à rien que l'utilisateur puisse manipuler pour fournir une autorisation. AT&T a essayé d'utiliser l'en-tête de l'agent utilisateur pour autoriser son service. Ne vous fiez pas aux en-têtes HTTP, aux cookies ou aux paramètres GET et POST.

Une fois ces mesures d'atténuation mises en place, L'idor appartiendra au passé.

Sécurisez vos références

Les références directes aux objets non sécurisés constituent l'une des vulnérabilités les plus faciles à exploiter. Ne les laissez pas vous surprendre au moment où vous vous y attendez le moins. Vérifiez toujours que les utilisateurs sont autorisés. N'utilisez pas de véritables identifiants de base de données. Ne vous fiez pas aux données contrôlées par l'utilisateur pour l'autorisation.

Développez votre maîtrise en consultant notre Pédagogiques. En vous entraînant à atténuer les vulnérabilités IDOR dans le langage de votre choix, vous n'aurez aucun problème à trouver et à résoudre ce problème dans vos bases de code de production. Vous pouvez également mettre vos nouvelles connaissances en matière de défense à l'épreuve grâce à une démonstration gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.

Êtes-vous prêt à vous défendre contre les attaques d'Idor dès maintenant ? Rendez-vous sur la plateforme et lancez-vous un défi gratuit : [Commencez ici]

目次

PDFをダウンロード
リソースを表示する
さらに詳しく知りたいですか?

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

もっと詳しく

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。

デモを予約するダウンロード
共有する:
リンクトインのブランドソーシャルx ロゴ
リソースセンター

はじめの一歩を踏み出すためのリソース

投稿はありません
リソースセンター

はじめの一歩を踏み出すためのリソース

投稿はありません