La sécurité par les développeurs.

Je vous avais promis de revenir et pour rien au monde j’aurai loupé ça!

Si vous avez bien compris l’objectif du premier article alors vous êtes des génies ( histoire de vous flatter c’est pas vrai ). Si cela n’a pas été le cas ne vous en faites pas on a encore du chemin et je reviendrai dessus autant de fois que vous le jugerez nécessaire . Eh oui quand je dis “à votre service” je le pense vraiment .

Pour faire court et passer à l’essentiel sur le précédent article j’ai essayé de vous faire comprendre que pour mettre en place un système de communication sécurisé, il n’y a pas de place pour la magie ni le tâtonnement ni la chance.  L’essentiel des actions doit être formalisé dans ce fameux manifeste qu’est la politique de sécurité qui s’adresse à différents profils d’utilisateurs que sont simple utilisateur, entrepreneur, administrateur, et développeur . Ce manifeste n’est pas figé et est amené à évoluer avec le système d’information.

Aujourd’hui je vais principalement vous parler de certaines précautions que j’ai identifiées comme étant essentielles ( je pèse mes mots) pour assurer la sécurité des plateformes applicatives.

Le jour ou je serai responsable d’une équipe de concepteurs et de développeurs je ne sais pas vous mais moi je ne me lasserai pas de leur demander de faire très attention lors de cette étape de développements des applications. La sécurité des applications doit être prise en compte tout dabord à la phase de conception, ensuite pendant le développement et l’intégration, et enfin durant toute la durée de vie de l’application.

Je vous rappelle qu’une vulnérabilité est avant tout un problème de conception. Pour aller plus loin encore une attaque c’est l’exploitation d’une vulnérabilité. Je ne vous cache pas que dans ce scénario d’attaques et de piratage, vous les concepteurs et developpeurs y avez une grande part de responsabilité.

Comment ça? Nous notre métier c’est de faciliter la vie des gens!

Dit le premier élève qui intervient dans mon cours aujourd’hui et on sent bien qu’il fait partie de la bande. La plupart d’entre vous  concepteurs et developpeurs d’applications vont se sentir viser par mes propos. Mais je vous calme tout de suite cela ne sert a rien de s’emporter on ne fait que discuter!!!!!

Pour répondre à ta question “comment”

Aujourd’hui une application à minima nécessite une interaction avec son environnement . Ces  interactions peuvent se faire avec un utilisateur, ou un système, ou d’autres applications. La première chose à laquelle je veux que vous pensiez c’est à la vérification et à l’assainissement de ces données échangées. Ensuite ne pas utiliser les fonctions d’API (Applications Programming Interface) qui sont identifiés comme étant obsolètes. La liste est loin d’être exhaustive et je vous encourage à m’aider à compléter l’article. ( Quand je dis que j’ai besoin de vous c’est vrai je vous assure).

Avant de commencer je précise que mon objectif est de vous sensibiliser à certaines failles de codage. En aucun cas je ne fournirai un document qui les recense tous. Et jespère que cela  vous incitera à faire des recherches pour en savoir plus!!!!!!

Pourquoi Vérifier ces données?

Lorsqu’une application reçoit des données d’un utilisateur par exemple, celles ci doivent impérativement être vérifiées afin d’empêcher les personnes mal intentionnées d’avoir une opportunité de faire du mal. Je sais que vous avez compris en gros mais si vous etes comme moi il vous faut un exemple concret pour que tout s’éclaire. ( Sauf pour les geek et geekettes bien sur!!). Plusieurs exemples peuvent être cités : débordements de mémoire tampon, injections de code, injections de fichiers…

Les debordements de mémoire la plupart d’entre vous savent ce que c’est et je parie que cela vous est arrivé plus d’une fois. Segmentation Fault !!! ( ahhhhh ça y est vous comprenez?). Cela se produit lorsque qu’on dépasse l’espace mémoire allouée lors de l’éxécution d’un programme. Les plus futés l’appelle Buffer overflow ( ne vous affolez pas c’est juste la traduction anglaise). Certains me diront que avec “segmentation fault” l’éxécution du programme sera bloquée, donc pas de risques. Mais il y a des langages de programmation comme le “C” qui permettent ces débordements.

Exemple :  un programme reçoit en entrée une chaine de caractère qui doit être copié dans un tableau dont la mémoire a été déja allouée. L’attaquant ayant au minimum une certaine connaissance de la  structure de sa mémoire se débrouille pour créer une donnée bien spécifique. L’écriture de ces données vont dépasser la taille du tableau et empiéter dans une espace mémoire qui controle l’éxécution du programme. Et le petit malin va en profiter pour détourner l’éxécution du programme.

Les injections ( SQL, de paramètres, de codes) sont également une porte d’exploitation des failles d’un système qui ne procède pas à une vérification minutieuse des données en entrée.

L’attaquant fournit des valeurs à des paramètres d’une requête SQL de manière à faire éxécuter au serveur  une requête sémantiquement incorrecte. Je vous laisse rechercher sur le net des exemples d’injection SQL et de vous amuser à les tester sur vos programmes.

J’aperçois un petit doigt au fond de la classe et une voix timide qui dit : Et pour ce qui concerne les API dont vous avez parlé au début de l’article?

C’est bien toi au moins tu es intéressé par ce que je dis (à moins que tu veuilles en finir au plus vite !lol). D’abord je vais faire comme si vous ne saviez pas  ce qu’est une API. Application Programming Interface  ce sont des bibliotèques comportant un ensemble de fonctions et méthodes toutes faites et prêtes à être utilisées. L’objectif premier c’est de faciliter le travail des programmeurs. Et comme tout programme, elle doit évoluer et être corrigée en cas de faille.

Comment reconnaitre une fonction d’API Obsolete et que faire dans ce cas?

Vous devez vous dire mais pour qui elle se prend, elle n’est même pas geek et elle ose déclarer des fonctions d’API comme étant obsolètes !!! Mais je vous jure que cela ne vient pas de moi. Ce sont des personnes très fortes et on les appelle des hackers qui ont decouvert ces vulnérabilités. Parfois lorsque vous recherchez une API sur le net, vous voyez la mention “ obsolète” à coté et parfois même les plus gentils vous indiquent une API  de remplacement.

Un exemple de fonction d’API obsolète : strcpy est une fonction en C qui  permet de copier une chaine de caractère dans un emplacement mémoire défini au préalable. Son obsolescence réside dans le fait que cette fonction procède au recopie sans vérifier la taille de la chaine source par rapport à ce que peut contenir la destination. D’où des problèmes de débordement mémoire qui peut entrainer la  manipulation du contenu de la mémoire d’éxécution du programme.

Je sais je vous ai donné des exemples qui pour la plupart concernent le langage C. Mais cela ne signifie absolument pas que les autres langages de programmation sont epargnés. Non loin de là!!!!

Pour compléter

Et pour réduire les chances de voir votre  conception assiégée par une armée de pirates:

• Servez-vous des tests. Au lieu de les utiliser juste pour voir les fonctionnalités du service, ajoutez-y des tests sécurité ( aucune idée si ces types de tests éxistent officiellement mais vous savez ce que je veux dire  ).

• N’hésitez pas à demander relecture aux plus grands.

• Au delà faites simples et écoutez notre ami Garry Winogrand : “L’extraordinaire nous attire un instant, la simplicité nous retient plus longtemps, parce que c’est en elle seule que réside l’essentiel.”

J’arrive au moment de l’article ou les paresseux me detestent au delà de tout. Je sais mes articles vous obligent toujours à aller faire des recherches de votre côté pour assouvir votre soif. Oui j’assume mes responsabilités et je vous répète que je ne ferai pas le travail à votre place. Je vous pointe juste l’endroit du doigt. Pour  trouver le trésor “A vous de jouer”!!!!

Hey mes amis developpeurs ce n’est pas parce que j’en ai fini avec votre cas que vous ne devez pas revenir. Rendez vous sur les prochains épisodes de cette série qui seront consacrés à mes amis administrateurs et utilisateurs du système d’information.

M.D pour vous servir!!!! A bientôt sur la Redac by Social Input

• Bio
• Latest Posts

M.D

Vous connaissez l'histoire du "i" dans mon prénom donc pas la peine d'y revenir je pense. Entre nous disons juste Mareme Diagne, ingénieur en réseaux et télécommunications , spécialisée en sécurité des systèmes d'information. Aidez moi s'il vous plaît, il me faut une armée de Hacker pour que je sois reconnue au Galsen. Vers, virus, cheval de Troie ... Peu importe faut que ça saute!! Merci d'avance

Latest posts by M.D (see all)

• Que faire quand je serai grand? - 23/02/2013
• La sécurité par les développeurs. - 09/01/2013
• La sécurité du système d’information, paranoïa ou réel danger, Qu’en pensez vous? - 06/11/2012
• Mon corps sain avant tout! - 07/09/2012