IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Copier du code sur des plateformes spécialisées et l'utiliser pour ses propres projets peut les rendre vulnérables
D'après une étude

Le , par Stéphane le calme

503PARTAGES

20  0 
Un objectif majeur du développement de logiciels est de fournir des logiciels de haute qualité de manière rapide et rentable. La réutilisation du code est une pratique acceptée et une approche essentielle pour atteindre ce principe. Les extraits de code réutilisés proviennent de nombreuses sources différentes et sous différentes formes, par exemple, une bibliothèque tierce, un logiciel open source et des plateformes spécialisées comme la plateforme de Stack Overflow. Le partage d'extraits de code et d'exemples de code est également une pratique d'apprentissage courante. Les novices et encore plus de développeurs expérimentés utilisent des exemples de code et des explications partagées sur des plateformes spécialisées pour apprendre à effectuer de nouvelles tâches de programmation ou à utiliser certaines API.

De nombreuses études ont examiné le flux de connaissances et le partage de connaissances de Stack Overflow dans des référentiels de logiciels open source hébergés dans GitHub. Elles en sont venues à la conclusion selon laquelle les extraits de code trouvés sur Stack Overflow peuvent être toxiques (c'est-à-dire de piètre qualité) et peuvent potentiellement conduire à des violations de licence. La sécurité est un aspect important de la qualité sur lequel la communauté de recherche n'a pas enquêté en détail. Si des extraits de code vulnérables sont migrés depuis Stack Overflow vers des applications, ces applications seront exposées aux attaques. De plus, la plupart des études qui s'y sont intéressées se sont plutôt penchées sur Java et Python.

Dans un document de recherche soumis au service de préimpression ArXiv, six chercheurs en informatique issus de l'Université de Shiraz en Iran, de l'Université polytechnique de Montréal au Québec et de l'Université Chamran en Iran (Morteza Verdi, Ashkan Sami, Jafar Akhondali, Foutse Khomh, Gias Uddin et Alireza Karami Motlagh) se sont fixé pour objectif de comprendre la nature et la prévalence des vulnérabilités en matière de sécurité dans les exemples de code en C++ partagés.

Ils expliquent que « dans les sessions de collaboration impliquant plusieurs codeurs humains, nous avons évalué manuellement les vulnérabilités de sécurité de chaque fragment de code conformément aux instructions de CWE (Common Weakness Enumeration). Parmi les 72 483 extraits de code examinés utilisés dans au moins un projet hébergé sur GitHub, nous avons trouvé un total de 69 extraits de code vulnérables classés dans 29 types. Beaucoup d'extraits de code étudiés ne sont toujours pas corrigés lors du dépassement de pile. Les 69 extraits de code vulnérables trouvés sur Stack Overflow ont été réutilisés dans un total de 2859 projets GitHub. Pour améliorer la qualité des extraits de code partagés sur Stack Overflow, nous avons développé une extension de navigateur qui permet aux utilisateurs de Stack Overflow de rechercher les vulnérabilités dans les extraits de code lorsqu'ils les téléchargent sur la plateforme ».


Pour les besoins de leur étude, ils se sont servis de Syntaxnet, un outil de traitement de langage naturel qui a été utilisé pour détecter les extraits de code contenant des codes C ++ réels. Selon l'équipe, Syntaxnet est l’un des analyseurs syntaxiques les plus précis disponibles. La principale différence entre Syntaxnet et les autres outils de PNL est que Syntaxnet n'utilise pas le sens de la phrase, mais considère également les mots comme étant indépendants les uns des autres. Parmi les 121 892 extraits de code possibles, seuls 72 483 extraits de code étaient en réalité des extraits de code C ++ inclus dans 1 325 réponses.

Afin de rendre le processus de révision plus efficace et systématique, les chercheurs ont créé une application Web dotée d'une interface simple avec une coloration syntaxique spécifique au langage. L'application de révision Web peut marquer les extraits de code comme étant vulnérables, attribuer une ou plusieurs balises CWE pour chaque extrait de code et afficher simultanément tous les codes similaires d'une même réponse.


Organigramme de la révision du code dans la première étape

Trois étudiants en master expérimentés (premier, troisième et sixième auteur) en matière de sécurité C++ ont été choisis pour examiner les extraits de code. Comme indiqué dans la section précédente, seuls 2 056 extraits de code unique devaient être révisés. L’examinateur devait identifier les vulnérabilités selon les critères de CWE appropriés.

Lors de la première étape du processus d’inspection manuelle, l’objectif était de réduire la taille des ensembles de données sans perte de précision. Ainsi, tous les extraits de code qui n'étaient certainement pas vulnérables ont été supprimés. Comme le montre l'organigramme, les trois examinateurs ont inspecté les extraits de code et marqué tout éventuel extrait de code vulnérable comme un code vulnérable. Si une vulnérabilité comportant un extrait de code était perceptible dès le premier tour de contrôle, ils rédigeraient une courte description expliquant pourquoi ils estimaient que l'extrait de code pouvait être vulnérable.

Les étapes spécifiques ont été documentées. Ce processus a pris 868 heures. En revanche, les extraits de code dépourvus de fonctionnalités spécifiques ou utilisés uniquement à des fins pédagogiques (et ne présentant aucune vulnérabilité) ont été supprimés. Au cours du processus de révision, les examinateurs ont été directement en contact les uns avec les autres et ont résolu leur désaccord par des discussions.

Second cycle d'examination

Après cette première étape d’examen approfondi du code, 498 extraits de code vulnérables ont été détectés. La première série de critiques a été présentée à un professeur en sécurité logicielle pour validation. Un groupe de 12 étudiants diplômés ayant déjà suivi des cours sur la sécurité des systèmes et/ou des logiciels au dernier cycle a finalisé la première série de révisions.

La deuxième série de processus d’examen était plus robuste et suivait des directives bien précises. Afin de trouver des vulnérabilités dans les réponses, les examinateurs devaient approfondir le processus et mieux comprendre les extraits de code ainsi que leur évolution. Sur la base des connaissances acquises au cours de la première phase d’examen, les chercheurs ont établi un ensemble de directives expliquées ci-dessous afin de détecter le plus grand nombre possible de vulnérabilités dans les extraits de code sans en manquer aucune :
  1. lire la question correspondante pour répondre avec l'extrait de code vulnérable probable : pour mieux comprendre les raisons pour lesquelles les développeurs ont partagé l'extrait de code sur Stack Overflow
  2. lire la dernière version de la réponse, sa description et son évolution au fil du temps : déterminer si la vulnérabilité a été corrigée ou si elle a évolué dans les différentes versions.
  3. lire les commentaires des réponses : pour savoir si la vulnérabilité a été signalée à travers les commentaires. Par exemple, dans l'illustration ci-dessous, les premier et second commentaires ont indiqué une vulnérabilité, les troisième et quatrième commentaires ont indiqué une réponse déconseillée. Le code source de la réponse est également inclus dans la liste 1.

  4. rechercher les fonctions obsolètes ou dangereuses dans les extraits de code : Par exemple, la fonction [C]rand ()[/B] est obsolète depuis C ++ 11 et n’est pas recommandée pour la génération de nombres aléatoires et les opérations cryptographiques.
  5. vérifier les arguments passés aux fonctions dans l'extrait de code : les types d'arguments et leurs valeurs sont très importants. Par exemple, un grand nombre entier non signé sortant de la limite passé à une fonction qui accepte les entiers signés peut interpréter la valeur en tant que nombre négatif entraînant un comportement non défini ou un plantage du programme.
  6. vérifier les utilisations des fonctions en se basant sur les documentations officielles : pour la référence et la documentation appropriée des vulnérabilités découvertes, des documentations officielles ont été largement utilisées tout au long du processus de révision. Par exemple, dans la liste 2, la valeur renvoyée par malloc n’a pas été vérifiée.
  7. rechercher les vulnérabilités logiques dans les extraits de code : en règle générale, la sécurité n’est pas la première priorité des personnes qui répondent sur Stack Overflow. Ils préfèrent se concentrer davantage sur les fonctionnalités que sur la sécurité. Par exemple, dans la liste 5, l’objectif est de lire un vecteur, mais aucune vérification des limites n’est effectuée. L'utilisation d'une valeur supérieure à celle liée à l'index peut se produire soit par une erreur de programmation, soit par un attaquant.

Après le deuxième cycle de révision, les extraits de code vulnérables identifiés ont été confirmés et étiquetés sur la base de CWE. Une ou plusieurs balises CWE ont été attribuées à chaque extrait de code. Ces balises ont permis aux chercheurs de suivre l'évolution de la sécurité des extraits de code tout au long de l'évolution de Stack Overflow sur une période allant de 2008 à 2018.

Ashkan Sami, professeur agrégé d'informatique, d'ingénierie et de technologie de l'information à l'Université de Chiraz en Iran, a déclaré que la recherche représentait une tentative pour examiner comment le code défectueux migre de Stack Overflow vers GitHub. « En gros, ce que nous avons essayé de montrer, c’est que le fait d’utiliser du code de Stack Overflow sans l’examiner attentivement peut conduire à des vulnérabilités au sein des applications », a déclaré Sami.

La recherche fait écho à un article académique de 2017 selon lequel 1 161 extraits de code non sécurisés publiés sur Stack Overflow avaient été copiés et collés dans 1,3 million d'applications Android disponibles sur Google Play.

Source : étude (au format PDF), recherche académique de 2017

Et vous ?

Avez-vous déjà copié du code sur une plateforme ? En quel langage ?
Avez-vous pris des mesures pour vous assurer de la qualité du code ou vous intéressait-il simplement dès lors qu'il était fonctionnel ?
L'avez-vous intégré dans des projets ou l'avez-vous seulement utilisé comme illustration ?
Avez-vous modifié le code en conséquence dès lors que vous avez appris qu'il était vulnérable ?

Voir aussi :

Microsoft évoque le futur de C++/CLI et de .NET Core : C++ sera disponible sur .NET Core 3.1 pour Windows
La première version finale de Nim, le langage doté d'un transcompilateur vers C, C++, JavaScript est disponible avec des ajouts
« Pourquoi le C est mon meilleur choix pour programmer des jeux vidéo », d'après un travailleur de la filière qui s'appuie aussi sur le C++ pour ses projets commerciaux
Microsoft amorce le support des Concepts apportés par C++ 20 dans Visual Studio 2019 version 16.3 Preview 2, au niveau du compilateur mais aussi de la bibliothèque

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de lsbkf
Membre actif https://www.developpez.com
Le 08/10/2019 à 1:23
Eh ui StackOverflow c'est fait pour expliquer pourquoi ceci ou cela ne marche pas et comment y remédier avec un exemple d'extrait de code (ou autre) à adapter selon le contexte réel du problème, pas un recueil pour codemonkey. On ne cherche pas à y produire du code sécurisé mais à aider quelqu'un avec un truc aussi simple que possible, et c'est sûrement expliqué quelque part sur le site !! Pas besoin d'une étude pour ça.
Pour Github en revanche, même si le code d'origine est sécurisé, quelqu'un qui copie/colle du code à la truelle laissera des vulnérabilités partout. Peut-être qu'il va omettre un mutex trois lignes plus haut parce qu'il n'a pas besoin des deux lignes entre les deux. Peut-être que les user inputs sont vérifiés en amont. Peut-être que yadda yadda.
7  0 
Avatar de sergio_is_back
Expert éminent https://www.developpez.com
Le 08/10/2019 à 9:37
Citation Envoyé par el_slapper Voir le message
Je présume que la partie que j'ai mis en gras est un euphémisme?
Oui... De façon plus explicite on peut dire que ça donnait de la merde mais c'était pour rester poli en début de semaine...
5  0 
Avatar de sergio_is_back
Expert éminent https://www.developpez.com
Le 08/10/2019 à 9:00
Quand je cherche des exemple de codes je ne copie pas bêtement le code proposé. J'essaye d'abord de comprendre ce que le code fait puis de l'adapter à mon cas particulier c'est comme ça que l'on peut apprendre. Les codes proposés en exemple sur Stackoverflow et d'autres sites ne le sont qu'a titre d'exemple et ils ne sont pas exempts de bugs ni de vulnérabilités. Ils sont souvent de plus soit hors contexte dans le cas d'un exemple générique ou dans un contexte bien particulier qui n'est pas forcement celui dans lequel on travaille. Il faut comprendre avant d'intégrer tout ou partie du code proposé.

Perso j'aime bien avoir deux trois exemples avant de choisir la façon dont j'intégrerai ça dans mon propre code.

J'ai connu des collègues (qui ne sont plus là) qui au contraire faisaient du copier/collé systématique sans chercher à comprendre (sans même renommer les variables ou refactoriser le code) et ça donnait pas toujours de bons résultats. Il faut toujours un effort de compréhension, en plus c'est bon pour sa propre culture.
4  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 09/10/2019 à 19:05
Citation Envoyé par sergio_is_back  Voir le message
Quand je cherche des exemple de codes je ne copie pas bêtement le code proposé. J'essaye d'abord de comprendre ce que le code fait puis de l'adapter à mon cas particulier c'est comme ça que l'on peut apprendre.

Pareil. Perso je rajoute même un commentaire avec la source, du genre // Adapted from <URL de la source>.
3  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 08/10/2019 à 9:31
Citation Envoyé par sergio_is_back Voir le message
(.../...)J'ai connu des collègues (qui ne sont plus là) qui au contraire faisaient du copier/collé systématique sans chercher à comprendre (sans même renommer les variables ou refactoriser le code) et ça donnait pas toujours de bons résultats. Il faut toujours un effort de compréhension, en plus c'est bon pour sa propre culture.
Je présume que la partie que j'ai mis en gras est un euphémisme?
2  0 
Avatar de emixam16
Membre chevronné https://www.developpez.com
Le 08/10/2019 à 9:41
J'ai un peu de mal avec cette étude

Parmi les 72 483 extraits de code examinés utilisés dans au moins un projet hébergé sur GitHub, nous avons trouvé un total de 69 extraits de code vulnérables classés dans 29 types
En vrai c'est pas si mal, ça voudrait dire que ~99.9% des codes partagé sur SO sont surs, pas la peine d'être si catastrophistes!

Des fois, si on met tous les codes de vérification, on se retrouve avec un code long et pas forcément très lisible. Autant ne mettre que les briques essentielles. Le programmeur pourra gérer lui-même la sécurité comme il l'entend. Et si l'utilisateur ne se rend même pas compte qu'il copie un code vulnérable, la vulnérabilité copiée ne sera probablement pas la seule ni la pire de son code...

En plus sur StackOverflow il peut y avoir des question sur la sécurité, donc si je vois une question du style "Qu'est-ce qu'un Buffer Overflow", ça ne me paraît pas alarmant que la réponse contienne une vulnérabilité, notamment si c'est un Buffer Overflow
2  0 
Avatar de
https://www.developpez.com
Le 10/10/2019 à 10:29
Citation Envoyé par air-dex  Voir le message
Pareil. Perso je rajoute même un commentaire avec la source, du genre // Adapted from <URL de la source>.

Ça rend le code source illisible très rapidement. Je maintiens une base de code où 2-3 devs successifs sont passés et ils ont fait ça a plein d'endroit. Après dans mon cas ils ont vraiment fait le forcing, quand ils changeaient un truc dans un script le dernier dev en date faisait du "Made by blababla on the xx/xx/xxxx, code inspired from [lien SO]" souvent sur plusieurs lignes. Infâme.

Perso quand je ne commente le code que lorsque ce n'est pas évident à la lecture, par exemple des règles spécifiques au secteur d'activité ou l'utilisation d'un pattern pas forcément évident au premier coup d’œil. Sinon j'utilise des noms de variables explicites et des constantes.
2  0 
Avatar de zecreator
Membre expert https://www.developpez.com
Le 17/10/2019 à 7:32
Copie un code pour l'utiliser dans son propre projet peut le rendre vulnérable, si c'est un copier-coller compulsif, sans chercher à comprendre totalement ce que fait ce code.
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 10/10/2019 à 11:23
j'ai rajouté l'URL exactement une seule fois en commentaire, pour une manip système tout sauf évidente, que j'avais trouvé sur le site officiel d'IBM. Sinon, je fais comme MrSKY : je ne laisse que l'utile en commentaire.
1  0 
Avatar de matthius
Inactif https://www.developpez.com
Le 08/10/2019 à 20:28
Ça s'appelle BSD.
0  0