Quelle est la gravité de la question de l'accès non intentionnel/malveillant aux informations sensibles des utilisateurs par les programmeurs?

Question

Dans une application Web, par exemple, le mot de passe et d'autres informations sensibles peuvent être consignés ou consultés d'une autre manière avant même d'être hachés et enregistrés dans la base de données.

Parfois, avec de très grandes applications, il n'est pas toujours possible de revoir tout le code pour éviter que cela ne se produise. Un programmeur malveillant pourrait facilement imprimer les informations privées de l'utilisateur dans un fichier journal.

Je voudrais savoir s'il s'agit d'une véritable menace et s'il existe des moyens standard pour empêcher ce type de compromission d'informations. Je suis un débutant web alors excusez-moi si cela ressemble à une question triviale.

Answer 1

Une solution triviale serait d'entrer votre nom d'utilisateur et mot de passe, puis grep tous les journaux du serveur pour ce mot de passe.

S'il y a une intention malveillante de certains de vos programmeurs, alors vous avez des problèmes dans votre équipe.

Ecrire de grandes applications nécessite la confiance des programmeurs, et quand je dis confiance, je veux dire: "vous croyez en votre équipe de ne pas faire des erreurs de manœuvre". Ne donnez pas aux programmeurs que vous ne croyez pas l'accès en écriture à n'importe quel code utilisé dans une application sensible.

Answer 2

Ou passez en revue tout le code avant qu'il ne soit déployé. Je ne pense pas qu'il y ait autre chose que vous puissiez faire.

Assurez-vous que tous les changements de code passent par le contrôle de version, de sorte que le programmeur coupable puisse laisser une trace. Mais même ce n'est pas vraiment sécurisé. Il pourrait vérifier le changement d'un autre poste de travail de programmeurs. Ou il pourrait ajouter un trou de sécurité dans l'application d'une manière qui ne peut pas être distinguée d'une erreur honnête. Et puis exploitez juste ce trou de sécurité.

Answer 3

Dans les grands environnements d'entreprise tels que les banques et les compagnies d'assurance, les développeurs ne devraient pas avoir accès à se connecter sur des serveurs en direct, les bases de données, etc.

Les développeurs ne devraient avoir un accès complet à des environnements de test. Cela fait en fait partie de l'audit externe annuel pour vérifier qui a accès aux données de production. En réalité, seule une révision de code serait en mesure de résoudre ces problèmes, car un développeur intelligent pourrait contourner ce problème.

Answer 4

S'il y a un accès malveillant, il n'y a pas grand chose à faire à ce sujet. Le programmeur trouvera toujours un autre moyen de contourner les précautions que vous avez prises.

Un accès non intentionnel peut être détecté par des tests. Évitez les informations de débogage en cours d'impression à l'écran ou dans des fichiers. Il arrive souvent que les lignes de débogage ne soient pas supprimées lors du déploiement. L'utilisation de bibliothèques comme LOG4J et autres peut empêcher cela.

Answer 5

Vous devez faire confiance à vos développeurs. Si vous ne leur faites pas confiance, vous avez des problèmes plus importants. En fin de compte, vous ne pouvez pas l'empêcher, mais si cela devait arriver, vous devriez avoir recours à des voies de recours pour obtenir des dommages-intérêts et, dans certains cas, des poursuites criminelles pourraient être intentées.

C'est un peu comme la question du 'crack crack'.Vous pouvez mettre tous les gardes de sécurité en place, mais à la fin de la journée, un développeur talentueux trouvera un moyen de les contourner avec suffisamment de motivation.

La culture d'entreprise joue aussi un rôle, si les employés sont engagés et se sentent partie intégrante de la situation dans son ensemble, il est dans leur intérêt de ne pas se soucier du succès futur de l'entreprise.