Les codeurs conquièrent la sécurité : série Share & Learn - Information Exposure
«Loose Lips fait couler des navires« est une expression qui est devenue populaire aux États-Unis pendant la Seconde Guerre mondiale. En Grande-Bretagne, vous avez entendu « Les propos insouciants coûtent des vies ». L'essentiel de ce dicton était que le fait de parler imprudemment d'informations sensibles pouvait être entendu par des espions et entraîner de graves conséquences.
Le même principe s'applique lors de la création d'applications Web. Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement.
Dans cet article, nous expliquerons ce qu'est l'exposition à l'information, pourquoi elle est dangereuse et comment la prévenir.
Comprendre l'exposition aux informations
L'exposition aux informations fait référence aux applications Web qui exposent des informations internes à ceux qui ne devraient pas les voir. Cela peut également faire référence à l'exposition d'informations sensibles sur les clients via des fichiers journaux ou l'interface utilisateur. Dans les deux cas, les attaquants peuvent utiliser les informations qu'ils trouvent pour attaquer vos systèmes ou vos utilisateurs.
Souvent, la première étape pour un attaquant est d'essayer de créer une erreur dans votre application. Une gestion des erreurs et une mauvaise configuration des applications Web entraînent une exposition d'informations sous forme de messages d'erreur. Que se passe-t-il si l'attaquant crée une erreur dans votre application ? Si un message d'erreur technique apparaît, y compris des détails techniques tels qu'une trace de pile, cela signifie que vous avez révélé trop d'informations. Ces informations peuvent inclure la base de données que vous utilisez ou la version du serveur d'applications que vous utilisez.
La divulgation d'informations sensibles peut se faire par d'autres moyens. Un formulaire contient-il des champs masqués contenant des informations sensibles ? Les attaquants peuvent simplement consulter la source de la page et en voir les valeurs.
En résumé, l'exposition d'informations se produit lorsque des informations qui devraient être demandées à vos utilisateurs sont rendues trop facilement accessibles.
Comprenez pourquoi l'exposition à l'information est dangereuse
Que peut faire un attaquant avec les informations exposées par l'application ? Si les informations sont de nature sensible, un attaquant pourrait voler des identités ou des informations d'identification utilisateur. Cela pourrait entraîner des dommages financiers, des violations de la vie privée et des amendes réglementaires
Si un attaquant utilise des messages d'erreur pour obtenir des informations sur une application, ces informations pourraient être utilisées lors d'une attaque future. En fait, le Guide de test OWASP contient une section complète sur collecte d'informations.
Le guide de test OWASP encourage l'utilisation des moteurs de recherche pour trouver des informations sur votre site Web qui ne vous intéressent peut-être pas. Par exemple, vos pages administratives sont-elles exposées aux moteurs de recherche ? Utilisez le fichier robots.txt pour indiquer aux moteurs de recherche de ne pas indexer certaines pages. Dans le même temps, le fichier robots.txt peut également divulguer des informations. Des URL sensibles peuvent parfois se trouver dans le fichier robots.txt. Les attaquants extraient le fichier et commencent à apprendre une partie de la structure des répertoires du site.
Google propose des options de moteur de recherche avancées qui permettent une inspection approfondie des sites Web. Par exemple, vous pouvez effectuer une recherche sur un site spécifique en utilisant la <domain>syntaxe « site : ». Vous pouvez consulter les pages mises en cache qui ont peut-être été supprimées mais qui se trouvent toujours dans le cache d'une tâche d'indexation précédente. L'utilisation de différents moteurs de recherche, tels que Bing et DuckDuckGo, peut donner des résultats différents. Testez donc sur chaque moteur de recherche ce qui est révélé à propos</domain> de votre application Web.
Les en-têtes HTTP, les bannières de sites Web et même les commentaires dans le code HTML et JavaScript peuvent contenir des informations que les attaquants ne devraient pas voir. Les en-têtes HTTP peuvent révéler les serveurs d'applications et les numéros de version. Les attaquants peuvent utiliser ces informations pour trouver des exploits à utiliser contre ces versions spécifiques. Assurez-vous de bien comprendre les différents endroits où les attaquants peuvent trouver vos informations et comment les masquer de manière appropriée.
Éliminez l'exposition à l'information
La divulgation d'informations est souvent un problème lié à la configuration des applications Web. Par défaut, de nombreux serveurs d'applications renvoient des traces de pile dans des messages d'erreur. Assurez-vous de modifier ce paramètre pour que les applications de production soient redirigées vers une page d'erreur générique lors de l'enregistrement de l'erreur à des fins de dépannage. Les messages d'erreur détaillés ne doivent jamais être renvoyés au navigateur de l'utilisateur.
Si certains fichiers nécessaires à l'application contiennent des informations sensibles, assurez-vous qu'un contrôle d'accès approprié garantit que seule l'application peut les lire. Désactivez la liste des répertoires sur le serveur et déplacez ces fichiers en dehors du répertoire racine Web. Cela empêche les attaquants d'accéder au fichier à l'aide du navigateur à l'aide d'un attaque par traversée de répertoires.
Les journaux peuvent être utilisés pour recueillir des informations lorsqu'ils ne sont pas configurés correctement. En cas d'erreur, n'enregistrez pas d'informations sensibles telles que les mots de passe, les jetons de session ou les informations personnelles identifiables (PII). Si un attaquant pouvait accéder aux fichiers journaux, il trouverait une mine d'informations sensibles à dérober. N'enregistrez pas plus que ce qui est nécessaire. Il s'agit généralement d'un identifiant de compte, d'un message d'erreur détaillé et peut-être de la méthode dans laquelle l'erreur s'est produite ou de l'opération en cours d'exécution. Supposez que les fichiers journaux ne sont pas secrets et vous ne serez pas tenté d'y placer des informations sensibles.
Ne supprimez pas vos applications Web
Auriez-vous vraiment pu divulguer des informations en parlant à un ami, menant directement à la perte d'un cuirassé pendant la Seconde Guerre mondiale ? Peut-être pas. Mais pourquoi courir ce risque ? C'est la leçon du dicton : « Des lèvres lâches font couler des navires ».
De même, il n'y a aucune raison d'exposer le fonctionnement interne de votre application Web au monde extérieur. Il n'y a aucune raison de consulter l'intégralité des numéros de cartes de crédit ou des mots de passe. Il n'y a aucune raison d'avoir des données PII dans les fichiers journaux. Alors ne le fais pas. Consultez nos ressources pédagogiques pour en savoir plus sur l'exposition à l'information.
Conservez le fonctionnement interne de vos applications à leur place. Ne supprimez pas vos applications Web.
Pensez-vous pouvoir mettre un terme à l'exposition à l'information dès maintenant ? Relevez le défi, guerrier : [Commencez ici]
Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement. Dans cet article, nous expliquerons ce qu'est l'exposition aux informations, pourquoi elle est dangereuse et comment la prévenir.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démo
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
«Loose Lips fait couler des navires« est une expression qui est devenue populaire aux États-Unis pendant la Seconde Guerre mondiale. En Grande-Bretagne, vous avez entendu « Les propos insouciants coûtent des vies ». L'essentiel de ce dicton était que le fait de parler imprudemment d'informations sensibles pouvait être entendu par des espions et entraîner de graves conséquences.
Le même principe s'applique lors de la création d'applications Web. Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement.
Dans cet article, nous expliquerons ce qu'est l'exposition à l'information, pourquoi elle est dangereuse et comment la prévenir.
Comprendre l'exposition aux informations
L'exposition aux informations fait référence aux applications Web qui exposent des informations internes à ceux qui ne devraient pas les voir. Cela peut également faire référence à l'exposition d'informations sensibles sur les clients via des fichiers journaux ou l'interface utilisateur. Dans les deux cas, les attaquants peuvent utiliser les informations qu'ils trouvent pour attaquer vos systèmes ou vos utilisateurs.
Souvent, la première étape pour un attaquant est d'essayer de créer une erreur dans votre application. Une gestion des erreurs et une mauvaise configuration des applications Web entraînent une exposition d'informations sous forme de messages d'erreur. Que se passe-t-il si l'attaquant crée une erreur dans votre application ? Si un message d'erreur technique apparaît, y compris des détails techniques tels qu'une trace de pile, cela signifie que vous avez révélé trop d'informations. Ces informations peuvent inclure la base de données que vous utilisez ou la version du serveur d'applications que vous utilisez.
La divulgation d'informations sensibles peut se faire par d'autres moyens. Un formulaire contient-il des champs masqués contenant des informations sensibles ? Les attaquants peuvent simplement consulter la source de la page et en voir les valeurs.
En résumé, l'exposition d'informations se produit lorsque des informations qui devraient être demandées à vos utilisateurs sont rendues trop facilement accessibles.
Comprenez pourquoi l'exposition à l'information est dangereuse
Que peut faire un attaquant avec les informations exposées par l'application ? Si les informations sont de nature sensible, un attaquant pourrait voler des identités ou des informations d'identification utilisateur. Cela pourrait entraîner des dommages financiers, des violations de la vie privée et des amendes réglementaires
Si un attaquant utilise des messages d'erreur pour obtenir des informations sur une application, ces informations pourraient être utilisées lors d'une attaque future. En fait, le Guide de test OWASP contient une section complète sur collecte d'informations.
Le guide de test OWASP encourage l'utilisation des moteurs de recherche pour trouver des informations sur votre site Web qui ne vous intéressent peut-être pas. Par exemple, vos pages administratives sont-elles exposées aux moteurs de recherche ? Utilisez le fichier robots.txt pour indiquer aux moteurs de recherche de ne pas indexer certaines pages. Dans le même temps, le fichier robots.txt peut également divulguer des informations. Des URL sensibles peuvent parfois se trouver dans le fichier robots.txt. Les attaquants extraient le fichier et commencent à apprendre une partie de la structure des répertoires du site.
Google propose des options de moteur de recherche avancées qui permettent une inspection approfondie des sites Web. Par exemple, vous pouvez effectuer une recherche sur un site spécifique en utilisant la <domain>syntaxe « site : ». Vous pouvez consulter les pages mises en cache qui ont peut-être été supprimées mais qui se trouvent toujours dans le cache d'une tâche d'indexation précédente. L'utilisation de différents moteurs de recherche, tels que Bing et DuckDuckGo, peut donner des résultats différents. Testez donc sur chaque moteur de recherche ce qui est révélé à propos</domain> de votre application Web.
Les en-têtes HTTP, les bannières de sites Web et même les commentaires dans le code HTML et JavaScript peuvent contenir des informations que les attaquants ne devraient pas voir. Les en-têtes HTTP peuvent révéler les serveurs d'applications et les numéros de version. Les attaquants peuvent utiliser ces informations pour trouver des exploits à utiliser contre ces versions spécifiques. Assurez-vous de bien comprendre les différents endroits où les attaquants peuvent trouver vos informations et comment les masquer de manière appropriée.
Éliminez l'exposition à l'information
La divulgation d'informations est souvent un problème lié à la configuration des applications Web. Par défaut, de nombreux serveurs d'applications renvoient des traces de pile dans des messages d'erreur. Assurez-vous de modifier ce paramètre pour que les applications de production soient redirigées vers une page d'erreur générique lors de l'enregistrement de l'erreur à des fins de dépannage. Les messages d'erreur détaillés ne doivent jamais être renvoyés au navigateur de l'utilisateur.
Si certains fichiers nécessaires à l'application contiennent des informations sensibles, assurez-vous qu'un contrôle d'accès approprié garantit que seule l'application peut les lire. Désactivez la liste des répertoires sur le serveur et déplacez ces fichiers en dehors du répertoire racine Web. Cela empêche les attaquants d'accéder au fichier à l'aide du navigateur à l'aide d'un attaque par traversée de répertoires.
Les journaux peuvent être utilisés pour recueillir des informations lorsqu'ils ne sont pas configurés correctement. En cas d'erreur, n'enregistrez pas d'informations sensibles telles que les mots de passe, les jetons de session ou les informations personnelles identifiables (PII). Si un attaquant pouvait accéder aux fichiers journaux, il trouverait une mine d'informations sensibles à dérober. N'enregistrez pas plus que ce qui est nécessaire. Il s'agit généralement d'un identifiant de compte, d'un message d'erreur détaillé et peut-être de la méthode dans laquelle l'erreur s'est produite ou de l'opération en cours d'exécution. Supposez que les fichiers journaux ne sont pas secrets et vous ne serez pas tenté d'y placer des informations sensibles.
Ne supprimez pas vos applications Web
Auriez-vous vraiment pu divulguer des informations en parlant à un ami, menant directement à la perte d'un cuirassé pendant la Seconde Guerre mondiale ? Peut-être pas. Mais pourquoi courir ce risque ? C'est la leçon du dicton : « Des lèvres lâches font couler des navires ».
De même, il n'y a aucune raison d'exposer le fonctionnement interne de votre application Web au monde extérieur. Il n'y a aucune raison de consulter l'intégralité des numéros de cartes de crédit ou des mots de passe. Il n'y a aucune raison d'avoir des données PII dans les fichiers journaux. Alors ne le fais pas. Consultez nos ressources pédagogiques pour en savoir plus sur l'exposition à l'information.
Conservez le fonctionnement interne de vos applications à leur place. Ne supprimez pas vos applications Web.
Pensez-vous pouvoir mettre un terme à l'exposition à l'information dès maintenant ? Relevez le défi, guerrier : [Commencez ici]
«Loose Lips fait couler des navires« est une expression qui est devenue populaire aux États-Unis pendant la Seconde Guerre mondiale. En Grande-Bretagne, vous avez entendu « Les propos insouciants coûtent des vies ». L'essentiel de ce dicton était que le fait de parler imprudemment d'informations sensibles pouvait être entendu par des espions et entraîner de graves conséquences.
Le même principe s'applique lors de la création d'applications Web. Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement.
Dans cet article, nous expliquerons ce qu'est l'exposition à l'information, pourquoi elle est dangereuse et comment la prévenir.
Comprendre l'exposition aux informations
L'exposition aux informations fait référence aux applications Web qui exposent des informations internes à ceux qui ne devraient pas les voir. Cela peut également faire référence à l'exposition d'informations sensibles sur les clients via des fichiers journaux ou l'interface utilisateur. Dans les deux cas, les attaquants peuvent utiliser les informations qu'ils trouvent pour attaquer vos systèmes ou vos utilisateurs.
Souvent, la première étape pour un attaquant est d'essayer de créer une erreur dans votre application. Une gestion des erreurs et une mauvaise configuration des applications Web entraînent une exposition d'informations sous forme de messages d'erreur. Que se passe-t-il si l'attaquant crée une erreur dans votre application ? Si un message d'erreur technique apparaît, y compris des détails techniques tels qu'une trace de pile, cela signifie que vous avez révélé trop d'informations. Ces informations peuvent inclure la base de données que vous utilisez ou la version du serveur d'applications que vous utilisez.
La divulgation d'informations sensibles peut se faire par d'autres moyens. Un formulaire contient-il des champs masqués contenant des informations sensibles ? Les attaquants peuvent simplement consulter la source de la page et en voir les valeurs.
En résumé, l'exposition d'informations se produit lorsque des informations qui devraient être demandées à vos utilisateurs sont rendues trop facilement accessibles.
Comprenez pourquoi l'exposition à l'information est dangereuse
Que peut faire un attaquant avec les informations exposées par l'application ? Si les informations sont de nature sensible, un attaquant pourrait voler des identités ou des informations d'identification utilisateur. Cela pourrait entraîner des dommages financiers, des violations de la vie privée et des amendes réglementaires
Si un attaquant utilise des messages d'erreur pour obtenir des informations sur une application, ces informations pourraient être utilisées lors d'une attaque future. En fait, le Guide de test OWASP contient une section complète sur collecte d'informations.
Le guide de test OWASP encourage l'utilisation des moteurs de recherche pour trouver des informations sur votre site Web qui ne vous intéressent peut-être pas. Par exemple, vos pages administratives sont-elles exposées aux moteurs de recherche ? Utilisez le fichier robots.txt pour indiquer aux moteurs de recherche de ne pas indexer certaines pages. Dans le même temps, le fichier robots.txt peut également divulguer des informations. Des URL sensibles peuvent parfois se trouver dans le fichier robots.txt. Les attaquants extraient le fichier et commencent à apprendre une partie de la structure des répertoires du site.
Google propose des options de moteur de recherche avancées qui permettent une inspection approfondie des sites Web. Par exemple, vous pouvez effectuer une recherche sur un site spécifique en utilisant la <domain>syntaxe « site : ». Vous pouvez consulter les pages mises en cache qui ont peut-être été supprimées mais qui se trouvent toujours dans le cache d'une tâche d'indexation précédente. L'utilisation de différents moteurs de recherche, tels que Bing et DuckDuckGo, peut donner des résultats différents. Testez donc sur chaque moteur de recherche ce qui est révélé à propos</domain> de votre application Web.
Les en-têtes HTTP, les bannières de sites Web et même les commentaires dans le code HTML et JavaScript peuvent contenir des informations que les attaquants ne devraient pas voir. Les en-têtes HTTP peuvent révéler les serveurs d'applications et les numéros de version. Les attaquants peuvent utiliser ces informations pour trouver des exploits à utiliser contre ces versions spécifiques. Assurez-vous de bien comprendre les différents endroits où les attaquants peuvent trouver vos informations et comment les masquer de manière appropriée.
Éliminez l'exposition à l'information
La divulgation d'informations est souvent un problème lié à la configuration des applications Web. Par défaut, de nombreux serveurs d'applications renvoient des traces de pile dans des messages d'erreur. Assurez-vous de modifier ce paramètre pour que les applications de production soient redirigées vers une page d'erreur générique lors de l'enregistrement de l'erreur à des fins de dépannage. Les messages d'erreur détaillés ne doivent jamais être renvoyés au navigateur de l'utilisateur.
Si certains fichiers nécessaires à l'application contiennent des informations sensibles, assurez-vous qu'un contrôle d'accès approprié garantit que seule l'application peut les lire. Désactivez la liste des répertoires sur le serveur et déplacez ces fichiers en dehors du répertoire racine Web. Cela empêche les attaquants d'accéder au fichier à l'aide du navigateur à l'aide d'un attaque par traversée de répertoires.
Les journaux peuvent être utilisés pour recueillir des informations lorsqu'ils ne sont pas configurés correctement. En cas d'erreur, n'enregistrez pas d'informations sensibles telles que les mots de passe, les jetons de session ou les informations personnelles identifiables (PII). Si un attaquant pouvait accéder aux fichiers journaux, il trouverait une mine d'informations sensibles à dérober. N'enregistrez pas plus que ce qui est nécessaire. Il s'agit généralement d'un identifiant de compte, d'un message d'erreur détaillé et peut-être de la méthode dans laquelle l'erreur s'est produite ou de l'opération en cours d'exécution. Supposez que les fichiers journaux ne sont pas secrets et vous ne serez pas tenté d'y placer des informations sensibles.
Ne supprimez pas vos applications Web
Auriez-vous vraiment pu divulguer des informations en parlant à un ami, menant directement à la perte d'un cuirassé pendant la Seconde Guerre mondiale ? Peut-être pas. Mais pourquoi courir ce risque ? C'est la leçon du dicton : « Des lèvres lâches font couler des navires ».
De même, il n'y a aucune raison d'exposer le fonctionnement interne de votre application Web au monde extérieur. Il n'y a aucune raison de consulter l'intégralité des numéros de cartes de crédit ou des mots de passe. Il n'y a aucune raison d'avoir des données PII dans les fichiers journaux. Alors ne le fais pas. Consultez nos ressources pédagogiques pour en savoir plus sur l'exposition à l'information.
Conservez le fonctionnement interne de vos applications à leur place. Ne supprimez pas vos applications Web.
Pensez-vous pouvoir mettre un terme à l'exposition à l'information dès maintenant ? Relevez le défi, guerrier : [Commencez ici]
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Afficher le rapportRéservez une démo
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
«Loose Lips fait couler des navires« est une expression qui est devenue populaire aux États-Unis pendant la Seconde Guerre mondiale. En Grande-Bretagne, vous avez entendu « Les propos insouciants coûtent des vies ». L'essentiel de ce dicton était que le fait de parler imprudemment d'informations sensibles pouvait être entendu par des espions et entraîner de graves conséquences.
Le même principe s'applique lors de la création d'applications Web. Lorsque votre application Web révèle trop d'informations, elle peut permettre aux attaquants de s'y introduire plus facilement.
Dans cet article, nous expliquerons ce qu'est l'exposition à l'information, pourquoi elle est dangereuse et comment la prévenir.
Comprendre l'exposition aux informations
L'exposition aux informations fait référence aux applications Web qui exposent des informations internes à ceux qui ne devraient pas les voir. Cela peut également faire référence à l'exposition d'informations sensibles sur les clients via des fichiers journaux ou l'interface utilisateur. Dans les deux cas, les attaquants peuvent utiliser les informations qu'ils trouvent pour attaquer vos systèmes ou vos utilisateurs.
Souvent, la première étape pour un attaquant est d'essayer de créer une erreur dans votre application. Une gestion des erreurs et une mauvaise configuration des applications Web entraînent une exposition d'informations sous forme de messages d'erreur. Que se passe-t-il si l'attaquant crée une erreur dans votre application ? Si un message d'erreur technique apparaît, y compris des détails techniques tels qu'une trace de pile, cela signifie que vous avez révélé trop d'informations. Ces informations peuvent inclure la base de données que vous utilisez ou la version du serveur d'applications que vous utilisez.
La divulgation d'informations sensibles peut se faire par d'autres moyens. Un formulaire contient-il des champs masqués contenant des informations sensibles ? Les attaquants peuvent simplement consulter la source de la page et en voir les valeurs.
En résumé, l'exposition d'informations se produit lorsque des informations qui devraient être demandées à vos utilisateurs sont rendues trop facilement accessibles.
Comprenez pourquoi l'exposition à l'information est dangereuse
Que peut faire un attaquant avec les informations exposées par l'application ? Si les informations sont de nature sensible, un attaquant pourrait voler des identités ou des informations d'identification utilisateur. Cela pourrait entraîner des dommages financiers, des violations de la vie privée et des amendes réglementaires
Si un attaquant utilise des messages d'erreur pour obtenir des informations sur une application, ces informations pourraient être utilisées lors d'une attaque future. En fait, le Guide de test OWASP contient une section complète sur collecte d'informations.
Le guide de test OWASP encourage l'utilisation des moteurs de recherche pour trouver des informations sur votre site Web qui ne vous intéressent peut-être pas. Par exemple, vos pages administratives sont-elles exposées aux moteurs de recherche ? Utilisez le fichier robots.txt pour indiquer aux moteurs de recherche de ne pas indexer certaines pages. Dans le même temps, le fichier robots.txt peut également divulguer des informations. Des URL sensibles peuvent parfois se trouver dans le fichier robots.txt. Les attaquants extraient le fichier et commencent à apprendre une partie de la structure des répertoires du site.
Google propose des options de moteur de recherche avancées qui permettent une inspection approfondie des sites Web. Par exemple, vous pouvez effectuer une recherche sur un site spécifique en utilisant la <domain>syntaxe « site : ». Vous pouvez consulter les pages mises en cache qui ont peut-être été supprimées mais qui se trouvent toujours dans le cache d'une tâche d'indexation précédente. L'utilisation de différents moteurs de recherche, tels que Bing et DuckDuckGo, peut donner des résultats différents. Testez donc sur chaque moteur de recherche ce qui est révélé à propos</domain> de votre application Web.
Les en-têtes HTTP, les bannières de sites Web et même les commentaires dans le code HTML et JavaScript peuvent contenir des informations que les attaquants ne devraient pas voir. Les en-têtes HTTP peuvent révéler les serveurs d'applications et les numéros de version. Les attaquants peuvent utiliser ces informations pour trouver des exploits à utiliser contre ces versions spécifiques. Assurez-vous de bien comprendre les différents endroits où les attaquants peuvent trouver vos informations et comment les masquer de manière appropriée.
Éliminez l'exposition à l'information
La divulgation d'informations est souvent un problème lié à la configuration des applications Web. Par défaut, de nombreux serveurs d'applications renvoient des traces de pile dans des messages d'erreur. Assurez-vous de modifier ce paramètre pour que les applications de production soient redirigées vers une page d'erreur générique lors de l'enregistrement de l'erreur à des fins de dépannage. Les messages d'erreur détaillés ne doivent jamais être renvoyés au navigateur de l'utilisateur.
Si certains fichiers nécessaires à l'application contiennent des informations sensibles, assurez-vous qu'un contrôle d'accès approprié garantit que seule l'application peut les lire. Désactivez la liste des répertoires sur le serveur et déplacez ces fichiers en dehors du répertoire racine Web. Cela empêche les attaquants d'accéder au fichier à l'aide du navigateur à l'aide d'un attaque par traversée de répertoires.
Les journaux peuvent être utilisés pour recueillir des informations lorsqu'ils ne sont pas configurés correctement. En cas d'erreur, n'enregistrez pas d'informations sensibles telles que les mots de passe, les jetons de session ou les informations personnelles identifiables (PII). Si un attaquant pouvait accéder aux fichiers journaux, il trouverait une mine d'informations sensibles à dérober. N'enregistrez pas plus que ce qui est nécessaire. Il s'agit généralement d'un identifiant de compte, d'un message d'erreur détaillé et peut-être de la méthode dans laquelle l'erreur s'est produite ou de l'opération en cours d'exécution. Supposez que les fichiers journaux ne sont pas secrets et vous ne serez pas tenté d'y placer des informations sensibles.
Ne supprimez pas vos applications Web
Auriez-vous vraiment pu divulguer des informations en parlant à un ami, menant directement à la perte d'un cuirassé pendant la Seconde Guerre mondiale ? Peut-être pas. Mais pourquoi courir ce risque ? C'est la leçon du dicton : « Des lèvres lâches font couler des navires ».
De même, il n'y a aucune raison d'exposer le fonctionnement interne de votre application Web au monde extérieur. Il n'y a aucune raison de consulter l'intégralité des numéros de cartes de crédit ou des mots de passe. Il n'y a aucune raison d'avoir des données PII dans les fichiers journaux. Alors ne le fais pas. Consultez nos ressources pédagogiques pour en savoir plus sur l'exposition à l'information.
Conservez le fonctionnement interne de vos applications à leur place. Ne supprimez pas vos applications Web.
Pensez-vous pouvoir mettre un terme à l'exposition à l'information dès maintenant ? Relevez le défi, guerrier : [Commencez ici]
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démoTéléchargerRessources pour vous aider à démarrer
Sujets et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions d'IA Beat the Boss sont désormais disponibles à la demande
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés liés à l'IA et au LLM pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyberrésilience : ce que cela signifie pour le développement de logiciels sécurisés dès la conception
Découvrez ce que la loi européenne sur la cyberrésilience (CRA) exige, à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite définis et mesurables
Enabler 1 donne le coup d'envoi de notre série en 10 parties intitulée Enablers of Success en montrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité pour assurer la maturité à long terme des programmes.
