Vous travaillez à Big Co. et vos collègues dans la salle sont sur l'équipe de développement Web du système de blog public de Big CO, dont beaucoup de grands employés de CO et de certaines personnes publiques utilisent. Le système de blogs permet à n'importe quel HTML et JavaScript, et on vous a dit que c'était un choix (pas par accident) mais vous n'êtes pas sûr s'ils réalisent les implications de cela.
Donc, vous voulez les convaincre que c'est une mauvaise idée. Vous écrivez du code de démonstration et plantez un script XSS dans votre propre blog, puis écrivez des poteaux de blog. Peu de temps après, le blog de la tête admin (dans la salle) visite votre poteau de blog et que le XSS vous envoie ses cookies. Vous les copiez dans votre navigateur et vous êtes maintenant connecté en tant que lui.
D'accord, maintenant vous êtes connecté en tant que lui ... et vous commencez à vous rendre compte que ce n'était peut-être pas une si bonne idée d'aller de l'avant et de «pirater» le système de blog. Mais tu es un bon gars! Vous ne touchez pas son compte après l'avoir connecté et vous ne planifiez certainement pas de publication de cette faiblesse; Vous voulez peut-être simplement leur montrer que le public est capable de le faire, afin qu'ils puissent le réparer avant que quelqu'un malveillant réalise la même chose!
Quel est le meilleur plan d'action d'ici?
6 Réponses :
Chaque fois que j'ai vu un problème de sécurité qui devait être adressé par notre équipe informatique interne dans le passé, je leur dis simplement quelle est la question et que peut-on faire pour l'exploiter potentiellement.
Selon la sensibilité qu'ils sont sensibles et que vous tenez compte avec eux / votre entreprise, le code de la preuve de concept peut être une bonne idée. S'ils ont des raisons de vous soupçonner de l'utiliser malicieusement, je le garderais à moi-même. Sinon, s'ils l'appréciaient, partagez-la.
C'est à propos de la seule zone sensible. Il suffit de communiquer le problème de manière responsable de manière à ce qu'il soit clair que vous étiez simplement préoccupé par les problèmes de sécurité et que vous ne cherchiez pas à les exploiter.
dépend vraiment de votre position dans l'entreprise, la nature du peuple dans la salle, etc., etc.
présenter une option:
Promenez-vous, décrivez la menace des termes abstraits («Quelqu'un pourrait détourner vos cookies, qui, à leur tour ...»), et demandez-leur s'ils aimeraient voir une démonstration? S'il y a de gros egos en jeu et que vous voulez vraiment qu'ils le réparent, ne parlent pas à toute l'équipe, mais juste la tête de l'équipe.
S'ils sont d'accord, attendez quelques heures et revenez être connecté comme «lui», et faites quelque chose de non destructeur mais perceptible dans le système - vous l'avez fait avec leur permission. Ils seront probablement impressionnés et veilleront à ce que le trou soit réparé.
S'ils ne sont pas d'accord et vous disent partir, vous devrez bien peser vos options: soit vous le prenez quelque part plus haut, ou vous l'enterrez. En mentionnant le problème, vous aurez abandonné toutes les options de l'envoyer de manière anonyme.
Si vous ne pouvez pas être sûr à 100% que tout le monde dans la chaîne de décision est raisonnable et comprend totalement ce que vous faites, et que c'est pour le bien de la société, je ne ferais pas de rogue "piratage" - toujours en parler d'abord, en particulier dans un environnement de grande entreprise. Ce genre de choses est trop facile pour mal comprendre comme malveillant sur votre fin - surtout s'il y a quelqu'un qui sera gêné en construisant ce trou de sécurité et aimerait mettre le blâme sur quelqu'un d'autre.
Tout le monde se concentre sur la fixation du problème du site Web, et peut-être que je suis juste un petit machiavélique, mais je penserais également à nous assurer que mes objections étaient enregistrées par écrit; J'écrirais un email à quelques-uns de mes supérieurs.
La dernière chose dont vous avez besoin est le site à exploiter, et le décideur qui vient à venir insister sur celui-ci était votre travail (ou votre copain) de considérer cet aspect technique, et que vous ne trouvez personne qui vous souvenait que vous avez parlé. < / p>
Je pense que vous avez dépassé votre rôle. Alors que les vulnérabilités XSS constituent une préoccupation sérieuse, si vous n'êtes pas dans le rôle de sécurité de l'information de votre organisation, vous n'avez vraiment aucune entreprise qui s'introduite sur la manière dont l'organisation de développement dans le hall opère.
Il n'y a pas de sécurité absolue, mais j'imagine que les personnes supervisant le projet de blog sont faciles la nuit, sachant que si des employés abusent de la technologie, ils peuvent être suivis à travers des journaux et être traités en conséquence.
Si vous avez écrit du code malveillant "pour le désamorcer" sans leur consentement, c'est une action assez grave à entreprendre sans approbation et j'imagine que vos supérieurs ressentaient de la même manière.
Je conviens qu'il aurait dû prendre la permission avant de rédiger un tel exploitation, mais tout le monde peut trouver un problème de sécurité afin qu'il devrait y avoir des moyens de le signaler et de le réparer. Le problème ici est l'équipe de devis Web ne comprenant pas la question de la sécurité qu'ils ont ... Personne ne devrait se cacher derrière la "Sécurité, ce n'est pas mon travail" et ignore le problème.
Vous avez trois choix viables:
Parlez à l'équipe Web.
Parlez à votre propre patron.
ignore-le.
Je pense que je vais aller pour les deux et 2.
C'est un comportement alarmant. S'ils ne comprennent pas les défauts de sécurité les plus simples comme XSS, ils doivent être Comprendre l'impact de votre code de votre code est une exigence absolue. Sans cela, le programmeur n'est qu'une responsabilité.
Ne serait-ce pas une bonne idée d'essayer de parler pour eux?
Vous avez exprimé brièvement vos préoccupations; C'était la conversation dans laquelle vous avez appris que c'était une décision (tout ou rien, vous avez été informé). Vous souhaitez exprimer qu'il existe un terrain d'entente, bloquant toutes les balises HTML, à l'exception de celles non malveillantes, mais dans le même temps que vous avez fait la démonstration en premier lieu d'avoir réellement Preuve pour sauvegarder Vos inquiétudes.
Pour envoyer la preuve de l'attaque anonymement à l'administrateur de la tête du blog, tournez vers la page 34.