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 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é.
Veuillez réserver une démonstration.
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]
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior 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é.
Veuillez consulter le rapportVeuillez réserver une démonstration.
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 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é.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes 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.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à 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 clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
