Vous êtes engagé pour corriger un petit bogue pour un site exigeant beaucoup de sécurité. En regardant le code, il est rempli de failles de sécurité. Que faire?
J'ai été embauché par quelqu'un pour faire quelques petits travaux sur un site. C'est un site pour une grande entreprise. Il contient des données très sensibles, la sécurité est donc très importante. En analysant le code, j'ai remarqué qu'il est rempli de failles de sécurité - lire, beaucoup de fichiers PHP lançant les entrées get/post de l'utilisateur directement dans les requêtes mysql et les commandes système.
Le problème est que la personne qui a créé le site pour lui est un programmeur dont la famille et les enfants dépendent de ce travail. Je ne peux pas simplement dire: "votre site est un parc d'attractions pour enfants. Laissez-moi le refaire pour vous et tout ira bien."
Que feriez-vous dans cette situation?
Mise à jour:
J'ai suivi quelques bons conseils ici et signalé poliment au développeur que j'ai trouvé des failles de sécurité possibles sur le site. J'ai souligné la ligne et dit qu'il pourrait y avoir une vulnérabilité possible aux attaques par injection SQL, et lui ai demandé s'il était au courant. Il a répondu: "bien sûr, mais je pense que pour l'exploiter, l'attaquant devrait avoir des informations sur la structure de la base de données; je dois mieux comprendre" .
Mise à jour 2:
J'ai dit que ce n'était pas toujours le cas et lui ai suggéré de suivre ce lien de question Stack Overflow afin de le traiter correctement: Comment empêcher l'injection SQL en PHP? Il a dit qu'il l'étudierait et m'a remercié de l'avoir dit lui avant. Je suppose que ma partie est terminée, merci les gars.
Ici et avant tout, la priorité est de combler les failles de sécurité.
Si vous travaillez directement avec l'ingénieur qui a écrit ceci, documentez tout et donnez-le à cet ingénieur.
Sinon, dites à votre employeur que les problèmes de sécurité sont plus importants que prévu et que le site a besoin de beaucoup de travail. Demandez à travailler avec le développeur principal qui est sur le site et offrez-lui de lui enseigner la sécurité PHP (ne promettez pas de faire de la personne un expert, mais proposez de la former à tout ce que vous savoir) afin que cette personne puisse prendre le relais une fois que vous avez terminé.
Ne pas en faire un problème "ce gars est mauvais, vire-le". Abordez-le du point de vue de "Hé, j'ai trouvé des bogues potentiels qui ont besoin d'être corrigés, qui semblent provenir de certaines ignorances/idées fausses courantes sur la sécurité du site. J'aimerais également parler à votre développement afin que nous puissions améliorer votre site et, espérons-le, éviter davantage de ces problèmes à l'avenir. "
Il y a une différence entre l'ignorance et l'incompétence. Il fut un temps où vous ne saviez pas non plus ce qu'était l'injection SQL, et il n'y a aucune raison de croire que le programmeur d'origine n'est pas capable de résoudre les problèmes une fois qu'il en a été informé.
Alors dis-leur. Soyez précis et objectif et soyez disponible pour répondre aux questions, fournir des exemples d'exploits et des recommandations de correctifs. S'ils ne l'obtiennent toujours pas après ce point, le mieux que vous puissiez faire est de ne pas mettre vos propres informations personnelles sur le site.
Votre travail n'est pas de refaire le site pour lui. C'est pour corriger le petit bug. Cependant, si vous avez remarqué des problèmes de sécurité qui devraient être corrigés, vous pouvez le signaler au propriétaire du site et donner un aperçu de ce que pourrait être le problème.
Ne réprimandez pas ou ne parlez pas négativement du développeur d'origine ou ne commentez pas à quel point le code est horrible. Soyez respectueux et professionnel. Vous pouvez proposer de travailler avec le développeur pour résoudre les problèmes. N'essayez pas de le réparer vous-même ou de proposer une solution à moins d'avoir été contracté pour résoudre le problème. S'ils suivent vos conseils et que vous vous trompez, ils pourraient revenir sur vous.
D'abord et avant tout - réparez la raison pour laquelle ils vous ont embauché. Si vous ne le faites pas, vous serez perçu comme le type de consultant qui souhaite faire plus de travail pour lui-même, plutôt que de faire le travail.
En plus des correctifs, vous devez leur donner une liste des choses que vous avez remarquées qui ne vont pas du point de vue de la sécurité, et pourquoi ces choses sont mauvaises.
Cela ne servira à personne de ne pas signaler les problèmes. Si vous aviez une tâche spécifique pour laquelle vous avez été embauché, mais documentez les autres problèmes de sécurité tels que vous les voyez et signalez-les à la personne appropriée, probablement la personne à laquelle vous faites rapport pour la tâche pour laquelle vous avez été embauché.
Il s'agit d'une situation où de solides compétences générales vont être utiles, car pour gérer cela avec tact, il faudra ne pas abandonner le travail effectué par d'autres sur le site et ne pas donner au développeur l'impression de remettre en question son talent.
Évitez évidemment les mots comme "merde, mauvais, pauvre, criblé" en faisant référence au code/aux défauts et aux mots similaires pour le développeur qui a écrit le site.
En plus des autres réponses, vous pouvez indiquer au développeur certaines ressources sur la facilité avec laquelle les problèmes d'injection SQL peuvent être exploités, par exemple sqlmap qui est un outil d'exploitation automatisé par injection SQL.
Ce que j'ai trouvé efficace pour démontrer la gravité de ce type de problème dans le passé, c'est de montrer ce qui peut être fait avec, donc si vous exécutez quelque chose comme ça contre un développeur. copie du site pour lui montrer l'extraction de données, etc., vous pourriez les convaincre du sérieux.
D'abord et seulement; La direction ne veut pas entendre parler des problèmes. J'ai été licencié du Bureau de la gestion du personnel (autorisations de sécurité pour la maison blanche) parce que je soulignais à quel point leur système n'était pas sûr. C'était il y a quelque temps, mais les attitudes de la direction n'ont pas changé.
Résolvez le problème avec le développeur, par e-mail afin que vous ayez une piste, puis marchez ou fuyez. Lorsqu'ils ont finalement un problème, en tant qu'entrepreneur, ils essaieront de vous blâmer, indépendamment de toute implication, même à distance, liée au problème.
Avoir un problème aussi fondamental qu'une injection SQL, indique qu'ils étaient bon marché lorsqu'ils ont initialement développé le système, et il y a de fortes chances qu'ils soient au mieux bon marché maintenant. Obtenez ce que vous pouvez d'eux alors qu'ils sont encore en affaires, mais cherchez le développement des affaires ailleurs.