72 votes

Connaissance du chapeau noir pour les programmeurs en chapeau blanc

Il y a toujours des scepticisme de non-programmeurs quand honnêtes développeurs apprennent les techniques des pirates du chapeau noir. Évidemment, nous avons besoin d’apprendre beaucoup de leurs astuces afin que nous puissions garder notre propre sécurité à la hauteur.

Dans quelle mesure pensez-vous qu'un honnête programmeur a besoin de connaître les méthodes de programmeurs malveillants ?

45voto

Lazarus Points 17526

À la fin de la journée rien que savent les « chapeaux noirs » est connaissances criminelles, c’est juste la façon dont la connaissance est appliquée. Ayant une connaissance approfondie de toute technique est précieuse en tant que programmeur, c’est comment nous tirer le meilleur parti du système. Il est possible d’obtenir en ces jours sans connaître les profondeurs que nous avons de plus en plus les cadres, les bibliothèques et les composants qui ont été écrits à l’aide de ces connaissances pour vous avoir à connaître tout sauver, mais il est toujours bon de creuser de temps en temps.

38voto

Avery Payne Points 1325

Je vais être un peu hérétique et aller sur une branche et dire:

  • Vous avez vraiment besoin de parler à l' administrateur système/réseau de gens qui fixent leurs machines. Ces gens traitent du concept de la des cambriolages chaque jour, et sont toujours à l'affût pour les menaces potentielles pour être utilisé contre eux. Pour la plupart, ignorent la "motivation" aspect de la façon dont les attaquants pense que, comme les jours de "piratage de notoriété" ont disparu depuis longtemps. Se concentrer plutôt sur la méthodologie. Compétent, l'administrateur sera en mesure de le démontrer facilement.

Lorsque vous écrivez un programme, la présentation de ce qui est (je l'espère), un uniforme, une interface lisse à ${importe quoi d'autre-accepte-vos-programmes-I/O}. Dans ce cas, il peut être un utilisateur final, ou il peut être un autre processus sur une autre machine, mais il n'a pas d'importance. Supposons TOUJOURS que le "client" de votre application est potentiellement hostile, qu'il s'agisse d'une machine ou d'une personne.

Ne me croyez pas? Essayez d'écrire une petite application qui prend les commandes de vente de vendeurs, alors une règle de la compagnie que vous avez besoin pour faire appliquer par le biais de cette application, mais les vendeurs sont constamment essayer d'obtenir autour de sorte qu'ils peuvent faire plus d'argent. Juste ce petit exercice, seul, permettra de montrer comment un attaquant motivé - dans ce cas, l'intention de l'utilisateur final sera activement à la recherche de moyens soit pour exploiter des failles dans la logique, ou de jeu, le système par d'autres moyens. Et ce sont de confiance des utilisateurs finaux!

Multijoueur jeux en ligne sont constamment en guerre contre les tricheurs, car le logiciel serveur généralement approuve le client; et dans tous les cas, le client peut et va être piraté, résultant dans les joueurs de jeu du système. Pensez à ceci: ici, nous avons des gens qui sont tout simplement profiter eux-mêmes, et ils vont utiliser des mesures extrêmes pour gagner la haute main dans une activité qui n'implique pas de faire de l'argent.

Imaginez la motivation d'un professionnel de bot herder qui rend leur argent pour vivre de cette façon...en écrivant des logiciels malveillants afin qu'ils puissent utiliser les machines des autres comme des générateurs de revenus, la vente de leurs réseaux de zombies à l'enchérisseur le plus offrant pour spam massif des inondations...oui, cela fait vraiment arriver.

Quelle que soit la motivation, le point reste, votre programme peut, et à un certain point, être l'objet d'attaques. Ce n'est pas suffisant pour le protéger contre les dépassements de tampon, d'écrasement de la pile, la pile d'exécution (code-que-chargement des données dans la pile, puis un retour est fait pour décharger la pile, conduisant à l'exécution du code), de l'exécution des données, le cross-site scripting, élévation de privilèges, conditions de course, ou d'autres "programmatique", les attaques, bien qu'il ne l'aide. En plus de votre "standard" programmatique défenses, vous aurez également besoin de penser en termes de confiance, de vérification, de l'identité et des informations d'identification - en d'autres mots, traitant de tout ce qui est de la prestation de votre programme d'entrée et de tout ce qui est encombrant votre programme de sortie de. Par exemple, comment se défendre contre l'empoisonnement DNS à partir d'un point de vue des programmes? Et parfois, vous ne pouvez pas éviter de choses dans le code de l'obtention de vos utilisateurs finaux à ne pas laisser leurs mots de passe à vos collègues de travail en est un exemple.

Intégrer ces concepts dans une méthodologie pour la sécurité, plutôt que d'une "technologie". La sécurité est un processus, pas un produit. Lorsque vous commencez à penser à ce qui est "de l'autre côté" de votre programme, et les méthodes que vous pouvez employer pour atténuer ces problèmes, il deviendra beaucoup plus clair quant à ce qui peut bien se passer, et ce qui peut aller terriblement mal.

38voto

Derecho Points 1122

Je suis arrivé en retard sur cette question, comme je viens d'entendre à ce sujet sur le podcast. Cependant, je vais vous donner mon avis en tant que quelqu'un qui a travaillé sur l'équipe de sécurité d'une entreprise de logiciels.

Nous avons pris développeur éducation très au sérieux, et nous aimerions que le plus grand nombre d'équipes de développeurs que possible la formation de base en développement sécurisé. Penser à la sécurité n'a vraiment besoin d'un changement dans la pensée du développement normal, donc nous voudrions essayer d'obtenir des développeurs de la pensée dans la façon de briser des choses à l'esprit. Un accessoire que nous avons utilisée était l'un de ceux à la maison de coffre avec le clavier numérique. Nous aimerions permettre aux développeurs de l'examiner à l'intérieur et à l'extérieur pour essayer de trouver une façon de briser dans. (La solution a été de mettre de la pression sur la poignée tout en donnant le coffre d'une forte bash sur le dessus, qui serait la cause de la culasse pour rebondir sur sa source dans le solénoïde.) Alors que nous ne leur donnons pas les spécifiques techniques de black-hat, nous discutions de la mise en œuvre des erreurs qui causent ces vulnérabilités, surtout des choses qu'ils n'auraient pas rencontré avant, comme les débordements d'entiers ou des compilateurs de l'optimisation de la fonction d'appels (comme memset pour effacer les mots de passe). Nous avons publié mensuellement un bulletin de sécurité interne, qui a invité les développeurs à l'endroit des bogues de sécurité dans les petits exemples de code, qui certainement ont montré combien ils manqueraient.

Nous avons également essayé de suivre de Sécurité de Microsoft Cycle de vie du Développement, ce qui permettrait d'impliquer les développeurs de parler de l'architecture de leurs produits et de comprendre les atouts et les moyens possibles pour attaquer ces actifs.

Comme pour l'équipe de sécurité, qui étaient pour la plupart anciens développeurs, la compréhension des techniques de black-hat était très important pour nous. Une des choses que nous étions responsable de recevoir les alertes de sécurité, de tiers, et sachant combien il serait difficile pour un chapeau noir à exploiter une faiblesse a été une partie importante de l'aire de triage et des processus d'enquête. Et oui, à l'occasion que m'a impliqué passant dans un débogueur pour calculer les décalages de mémoire vulnérables routines et de la correction des exécutables binaires.

Le vrai problème, cependant, est que beaucoup de cela a été au-delà des développeurs capacités. Tout, de taille raisonnable, la société va avoir beaucoup de développeurs qui sont assez bons dans l'écriture de code, mais n'ont tout simplement pas la sécurité de l'état d'esprit. Donc, ma réponse à votre question est: est-ce attend à ce que tous les développeurs d'avoir de black-hat connaissances serait un indésirable et nuisible fardeau, mais quelqu'un dans votre entreprise doit avoir des connaissances, que ce soit un audit de sécurité et d'intervention de l'équipe, ou tout simplement de développeurs chevronnés.

19voto

ScottStonehouse Points 6513

Dans une large mesure. Vous devez penser comme un criminel, ou vous n’êtes pas assez paranoïaque.

18voto

Bill the Lizard Points 147311
<blockquote> <p>Dans quelle mesure pensez-vous qu'un honnête programmeur a besoin de connaître les méthodes de programmeurs malveillants ?</p> </blockquote> <p>Vous avez besoin de savoir <em>plus</em> qu’eux.</p>

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X