Doit-on être un bon programmeur pour effectuer une analyse sécurisée du code source?
Une personne a une bonne connaissance des risques de sécurité globaux, connaît les vulnérabilités OWASP Top 10 et possède des certifications telles que CEH, CISSP, OSCP, etc., qui sont davantage des tests de boîte noire. Et il a également parcouru le guide de test OWASP, le guide de révision du code, etc. et les feuilles de triche. Sera-t-il capable d'effectuer une révision de code sécurisée sans connaissance de plusieurs langages de programmation et maîtrise de ceux-ci?
Cela dépend de ce que l'on entend par "analyse de code source sécurisé". On peut faire tout ce qu'on veut. Le problème, je présume, est que quelqu'un d'autre a demandé quelque chose appelé "analyse de code source sécurisé", et on se demande pourquoi on n'est pas qualifié pour cela.
Dans de nombreux cas, cette analyse doit être effectuée par un expert en la matière (PME). Dans le produit final, un SME livrera une déclaration disant en gros "Je déclare que ce code est sécurisé", avec une compréhension qui est une déclaration plus profonde que "J'ai cherché un tas de modèles, et n'a trouvé aucun problème. "
Si vous étiez intéressé par la traduction authentique d'une philosophie chinoise, feriez-vous confiance à une personne qui en savait beaucoup sur la philosophie et qui avait un tas de tricheurs pour aider à la déchiffrer, mais qui ne connaissait pas vraiment le chinois?
Un excellent exemple qui me vient à l'esprit est un bogue qui a frappé un moteur SQL. Pardonnez-moi de ne pas avoir le nom de quel moteur ou de quelle version vous pouvez le vérifier, j'ai eu du mal à le retrouver depuis. Cependant, l'erreur était poignante. L'erreur était dans un code qui ressemblait à ceci:
int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
if (dest->putPtr + length < dest->putPtr)
return ERROR; // prevent buffer overflow caused by overflow
if (dest->putPtr + length > dest->endPtr) {
... // write the data in two parts
return OK;
} else {
... // write the data in one part
return OK;
}
}
Ce code était destiné à faire partie d'un tampon circulaire. Dans un tampon circulaire lorsque vous atteignez la fin du tampon, vous vous enroulez. Parfois, cela vous oblige à diviser le message entrant en deux parties, ce qui est correct. Cependant, dans ce programme SQL, ils étaient préoccupés par le cas où length pourrait être suffisamment grand pour provoquer un débordement de dest->putPtr + length, Créant une opportunité de débordement de tampon car la prochaine vérification ne fonctionnerait pas droite. Ils ont donc mis un test: if (dest->putPtr + length < dest->putPtr). Leur logique était que la seule façon dont cette déclaration pourrait être vraie, c'est si un débordement se produisait, donc nous attrapons le débordement.
Cela a créé un trou de sécurité qui a été exploité et a dû être corrigé. Pourquoi? Eh bien, à l'insu de l'auteur d'origine, la spécification C++ déclare que le débordement d'un pointeur est un comportement non défini, ce qui signifie que le compilateur peut faire tout ce qu'il veut. En l'occurrence, lorsque l'auteur d'origine l'a testé, gcc a effectivement émis le code correct. Cependant, quelques versions plus tard, gcc avait des optimisations pour tirer parti de cela. Il a vu qu'il n'y avait aucun comportement défini où cette instruction if pouvait passer son test, et l'a optimisée!
Ainsi, pour quelques versions, les gens avaient des serveurs SQL qui avaient un exploit, même si le code avait des contrôles explicites pour empêcher ledit exploit!
Fondamentalement, les langages de programmation sont des outils très puissants qui peuvent facilement mordre le développeur. Analyser si cela se produira nécessite une base solide dans la langue en question.
(Edit: Greg Bacon était assez grand pour trouver un avertissement CERT à ce sujet: les vulnérabilités Les compilateurs VU # 162289 C peuvent ignorer silencieusement certains contrôles enveloppants. , et aussi this related un. Merci Greg!)
Je pense que vous devez être un bon programmeur pour réussir, donc je vous recommande d'en devenir un. Il peut y avoir beaucoup de choses qui manquent à votre boîte à outils/scanner. Honnêtement, je ne recommande pas de s'appuyer entièrement sur des outils pour analyser votre code pour vous, car les exploits changent constamment, et quelqu'un peut avoir codé d'une manière où le scanner ne peut pas détecter les vulnérabilités.
La capacité de parcourir le code et de voir comment il fonctionne et comment il ne devrait pas fonctionner est fondamentale pour sécuriser le développement logiciel. Avoir un développeur au courant des problèmes de sécurité est exactement ce que vous voulez quand il s'agit de produire un produit solide, et exactement ce dont vous avez besoin lors d'une révision de code.
Bien que oui, vous pouvez pointer et cliquer et vérifier les vulnérabilités avec vos scanners et boîtes à outils, cela ne sera pas très efficace dans le grand schéma des choses. Savez-vous combien vous seriez plus efficace si vous pouviez regarder le code vous-même et déterminer s'il est bon ou mauvais? Waaaay mieux.
N'essayez pas de passer un examen de code sécurisé si vous ne savez pas ce que vous faites, mais n'abandonnez pas l'idée si vous pensez que vous n'êtes pas à un point où vous pouvez faire un bon examen. Je recommande d'essayer d'apprendre en créant vos propres revues de code sécurisé et de les parcourir plusieurs fois pour vous assurer que tout va bien.
Mais encore, vous devez certainement apprendre non seulement à coder, mais à bien coder.
Il est douteux qu'un expert en sécurité soit efficace pour effectuer une analyse de code source sans être également un programmeur qualifié. De nombreuses vulnérabilités sont le résultat de pratiques de codage technique ou syntaxique qui sont mal utilisées de manière mineure. Un point-virgule manquant, un signe égal au lieu d'un double-égal, une limite de tableau qui est doublement définie le premier jour mais une version est modifiée dans la version suivante, des crochets manquants, des fuites de mémoire, tous ont conduit à des vulnérabilités. Un développeur expérimenté peut les voir, mais un novice ne le verra probablement pas.
Ce que votre expert en sécurité devrait faire est d'encourager les ingénieurs à utiliser des outils d'analyse automatisés tels que des analyseurs de code statiques, des testeurs fuzz et des vérificateurs d'applications dynamiques. Aidez les équipes d'ingénierie à comprendre la validation des entrées, les attaques par injection, les limites de confiance. Faites prendre conscience que les défauts de sécurité doivent être hiérarchisés de manière appropriée et traités rapidement. Planifiez et effectuez des tests de plume. Et le plus important, demandez aux ingénieurs de faire des revues de code du travail de chacun.
Oui, l'expert en sécurité devrait pouvoir lire le code, mais cela ne signifie pas qu'il est qualifié pour être l'arbitre de la sécurité du code.
Cela dépend de vos attentes. Des vulnérabilités de sécurité causées par des problèmes de conception (c.-à-d. Une protection CSRF manquante, seule l'implémentation rudimentaire d'un protocole, etc.) peuvent probablement être trouvées si le testeur a une connaissance approfondie des concepts de sécurité, même s'il ne peut suivre le flux de code sans avoir une connaissance plus approfondie du langage de programmation spécifique.
Mais des problèmes de sécurité spécifiques à la langue, tels que des dépassements de tampon, des erreurs ponctuelles, la gestion d'unicode ou \0, les problèmes causés par la taille des types de données et les signés et non signés, etc. ne seront pas trouvés si le testeur n'a pas une connaissance plus approfondie de la langue, des mauvaises pratiques et des modèles d'insécurité typiques spécifiques à la langue. Prenons l'exemple des vulnérabilités Java Java), où même les développeurs experts Java) ont remarqué les trous qu'ils ont percés dans le bac à sable du langage en ajoutant de la réflexion à la langue et seulement experts externes avec une compréhension approfondie de la langue interne détecté les défauts.
Non seulement la révision sécurisée du code nécessite une connaissance du langage de haut niveau, mais aussi des options du compilateur et COMMENT LE CODE FONCTIONNERA RÉELLEMENT SUR LE CPU! Les langages de haut niveau sont efficaces pour écrire du code car ils cachent une grande partie de la complexité. Mais de nombreuses erreurs et bogues se cachent dans la complexité. Comme indiqué dans une autre réponse, les compilateurs essaient de faire la bonne chose, mais vous devez vraiment comprendre ce qui se passe en désassemblant le code et en développant une compréhension approfondie de son fonctionnement.
Cette compréhension est également requise avec les langages de script comme JavaScript qui interprètent le code de haut niveau pour les instructions du processeur et l'allocation de mémoire. Malheureusement, cet examen dépendrait de la plate-forme. Voir par exemple sur https://en.m.wikipedia.org/wiki/Interpreted_language .
Doit-on être un bon programmeur pour effectuer une analyse sécurisée du code source?
Non.
Sera-t-il capable d'effectuer une révision de code sécurisée sans connaissance de plusieurs langages de programmation et maîtrise de ceux-ci?
Non.
La programmation ne se limite pas à l'expertise dans les détails du fonctionnement des différentes langues. C'est l'une des choses dont vous avez besoin pour être un bon programmeur, et c'est aussi l'une des choses dont vous avez besoin pour être en mesure d'analyser le code source dans une perspective de sécurité (ou toute autre qualité).
Donc, même si vous n'avez pas besoin d'être un bon programmeur, vous avez besoin de maîtriser les langages impliqués.
Afin de comprendre correctement le danger d'attaques par canal latéral, vous devez connaître le matériel. Il y a des attaques latérales vraiment laides, comme exécuter un processus non privilégié sur une configuration multi-CPU en parallèle avec un privilégié effectuant une tâche de chiffrement/déchiffrement et sonder quelles lignes de cache partagées se salissent dans quel type de modèle temporel ou par chronométrer la livraison respective de séquences de motifs spécifiques à chiffrer.
Les algorithmes de cryptage étant soumis à un examen minutieux des mathématiciens et autres théoriciens, les attaques par canal latéral sont des moyens de plus en plus importants de pousser le jeu à nouveau. L'inconvénient est qu'ils doivent être conçus pour une implémentation, un code et un matériel particuliers.