Du code lisible et sécurisé tu développeras

Un code lisible se passe de commentaires !

Cet article traitant très simplement de l'art de coder, de la sécurité informatique, illustrant par un petit exemple une technique de hacking (piratage) est avant tout destiné aux non-initiés.
Nous espérons que nos chers lecteurs, nos prospects, les entrepreneurs intéressés par le sujet y trouveront un peu d’information pour mieux comprendre l'importance de confier ses projets web à des experts compétents et consciencieux. C'est toujours plus facile de séparer le bon grain de l'ivraie quand on dispose d'un minimum de connaissance sur un sujet donné.

La voie du développement : la genèse

Il y a une dizaine d’années, Sylvain m’a proposé de rejoindre l’aventure AxeNet pour seconder son développeur de l’époque un certain JS.
Au bout d’une journée plongé dans le code de M. JS, j’ai du constater que j’étais loin d’avoir le niveau, moi qui jusqu’à alors bricolais deux trois trucs en PHP, MySql, html, css et Cie pour une assoc...

L’homme sage connaissant ses limites, j’ai proposé à Sylvain la meilleure solution pour AxeNet : l’embauche d’un certain Florian (dit Flo pour les intimes). Ce jeune et talentueux développeur était arrivé dans mon association quelques semaines auparavant pour que je lui donne des cours d’initiation au développement, alors qu’ironie du sort ce fut un peu l’inverse qui se produisit…

Un jour JS attrapa la pierre dans la main de maître Sylvain et le petit scarabée quitta le temple pour partir vers d’autres horizons...
Florian et moi, rejoints un peu plus tard par l'apôtre Brandon, allions faire un long chemin ensemble les mains dans l’cambouis et construire notre cathédrale numérique projet après projet, ligne de code après ligne de code…

Au matin du début du commencement du premier projet, Flo eu une vision en redescendant de la montagne du mont PHP, avec gravé sur sa tablette de verre les 2 premiers commandements du développeur :

I) Du code lisible et structuré tu développeras

Prenons pour l’exemple (très simple, restez avec nous), un petit tableau (array) des données relatives à un produit :

Le « mauvais » développeur écrira :

$xyz = array('Iphone 7', 'Apple', 'Blanc', 780) ;

Le bon développeur :

/* Le tableau du produit */
$aProduit = array('nom' => 'Iphone 7',
                  'marque' => 'Apple',
                  'couleur' => 'Blanc',
                  'prix' => 780
                 );

Le bon développeur

Son code il commentera : pour lui-même et les autres développeurs afin que toutes les explications ou informations nécessaires soient clairement et directement disponibles dans le code.

Ses variables clairement il nommera : l'art de la programmation n'est pas des plus simples, le bon sens est par conséquent de ne surtout pas se rajouter des complications inutiles et bien au contraire de faciliter la lecture et la compréhension du code au maximum.
Dans le petit exemple ci-dessus, c’est clairement le tableau des données relatives à un produit (le petit a après le $ donne même le type de variable ($a pour un array, $o pour un objet, $s pour une chaîne de caractères (string), etc.).

À ses frères développeurs il pensera : d’autres dev (ou lui-même) seront peut-être amenés à retravailler un jour dans son code. L'objectif (pour ne pas dire la fierté) du bon développeur est que leur prochain soit agréablement surpris par la qualité, la clarté et la lisibilité de son propre^ code. Le respect des normes du langage, une indentation rigoureuse, un espacement pensé entre les blocs de code donneront de surcroît quelque chose « de beau à regarder »... Pour la p'tite histoire, WordPress eu un temps comme slogan affiché en admin "Code is Poetry".

Maintenant représentez-vous la petite comparaison ci-dessus multipliée par les dizaines de milliers de lignes de code que contient un site e-commerce. Ce petit exemple ne représente « qu’un atome » d’un gigantesque ensemble mille fois plus complexe avec des boucles, des conditions, des fonctions, des class, des méthodes, etc.
Cela suffira je pense à ce que tout le monde se fasse une idée des conséquences possibles entre un code lisible et un code dont les voies seront aussi impénétrables que celle du Seigneur...

Les conséquences :

Le développeur ou son collègue devront probablement réintervenir dans le code (modifications, résolution d’un bug, maintenance, optimisation, update, nouvelles fonctionnalités, etc.). Si le code n’est ni structuré, ni lisible même son créateur en sera pour ses frais le jour où il y retournera, sans parler des maux de tête pour ses collègues...
Avec Florian nous avons une fois relevé ce genre de défi : un client m’appelle un jour et me dit en substance « mon développeur freelance m’a lâché à deux semaines de la mise en prod. au secours AxeNet... »
AxeNet : « ok, mais on doit auditer avant de s’engager... »

L’audit révéla que le dev était probablement bon, le projet étant très complexe, mais qu’il avait codé de façon a ce que (presque) personne ne puisse intervenir derrière lui ! Malheureusement il n’y a pas que dans ce métier que cela arrive et les gens qui agissent ainsi le font souvent avec un égo qui n’a d’égal que leur niveau d’inconscience. Comme l’a dit JC il y a environ 2017 ans, « pardonne-leur, car ils ne savent pas ce qu’ils font ».

Un code pas assez réfléchi en amont, mal écrit, mal structuré rend très difficiles la correction des bugs, la maintenance, les évolutions d'un projet et au final vous coutera très cher. Il n’est malheureusement trop souvent que la face émergée de l’iceberg, un gage de pannes à répétitions et de failles de sécurité en veux-tu en voilà.

II) Ton code tu sécuriseras

Avant de connaître Florian, je vivais dans le monde merveilleux des cyber-bisounours. Je ne savais pas que des personnes mal intentionnées saisissaient dans les champs de formulaire autre chose que ce qu’on leur demandait…
En lieu et place de leur nom, dans l’url d’une page, des petits malins appelés hackers tapaient du code de façon à « entrer » par effraction dans le programme, l’application, le site…

Florian me montra les techniques (qui s’apparentent à celle du crochetage de serrures) et en quelques minutes ce fut la journée portes ouvertes pour lui sur le backoffice de mon pauvre site. Les programmes que je développais à l'époque, bien que fonctionnels étaient, sans que j’en aie conscience, de véritables passoires !

La prise de conscience planétaire de ce phénomène est relativement récente. Au-delà de nos petites affaires, les états ont également pris conscience de ce fléau et déploient les moyens nécessaires à ce que l’on nomme aujourd’hui la cyber-guerre.

Avec de bonnes connaissances, il est possible de bâtir une forteresse au lieu d’un moulin et aujourd’hui c’est devenu indispensable. Mieux vaut avoir dans son équipe un combattant aguerri capable de prévenir par la qualité du code qu'il produit et de contrer toute attaque.
Un hébergement pro du type serveur dédié nécessite quant à lui, obligatoirement, une infogérance suivie et effectuée par un expert tout au long de l'année (mise à jour des appli serveur (Apache, PHP, MySQL, etc.)). Une petite faille de sécurité négligée, une bonne attaque serveur et là ce sont potentiellement des dizaines de sites qui risquent de tomber en rideau en même temps.

Accrochez-vous, un petit exemple ultra-simplifié de hacking :

Prenons un champ de formulaire à saisir «Email» qui servira d’identifiant pour se logger sur le site.

Une personne « normale » saisira « pierredupond@monfai.truc », validera son formulaire , jusque là tout va bien.

Un hacker, lui se dira que derrière, on enregistre en base de données cet email et qu’elle sert ensuite à l’identification. Lors de la création de son compte, il saisira un truc du genre :
« hacker@tartenpion.fr' OR 1=1 # ».

Le hacker possédant les connaissances suffisantes sur la construction de site peut supposer que le code gérant l’identification est du style :

[…] user identified OK [...] WHERE `email` = 'hacker@tartenpion.fr' OR 1=1 #' AND `password` = 'après#onsenfout'

Explication :
Le code pour l’identification vérifie (en temps normal) que l’utilisateur est OK QUAND (WHERE) le couple 'email' ET (AND) 'le mot de passe' correspondent.

L’astuce consiste dans ce cas d’école à passer après l’email le bout de code « ' OR 1=1 # » ce qui donne pour notre hacker tentant de s’identifier sur le site :

L’utilisateur est OK WHERE `email` = 'hacker@tartenpion.fr' OR 1=1 #

Ce qu’il sait, c’est qu’après le #, le code est comme « coupé » (le # dans ce langage dit : ne plus prendre en compte (il est utile pour mettre des commentaires en langage SQL).
Si aucune bonne pratique n’a été mise en place, on se retrouve donc avec :
L’utilisateur est OK WHERE (n’importe quelle email) OU (OR) 1=1 !
C’est vrai pour tout le monde et à plus forte raison pour un ordinateur que 1=1. Là est l’astuce de la mort, donc à lui la console d’admin et bonjour les dégâts.

Les connaisseurs qualifient cette attaque « d’injection » en l’occurrence « d’injection de code SQL ». On injecte en effet un bout de code (malin) qui vient faire capoter le processus normal. Les hackers sont, il faut bien le reconnaître, extrêmement astucieux et vont le plus souvent « au plus simple ». Dans la vie réelle vous connaissez sans doute le coup de la méga super porte blindée à 7000 € que dédaigne le voleur en passant tout bêtement par la fenêtre ou le toit.

Cet exemple est le b.a.-ba du hacker et vous n’avez aucune chance que ça marche ici ou ailleurs. Je vous rappelle (au cas où) que ce genre de tentative est illégale et passible de poursuites (même virtuelle, il s’agit bien d’une tentative d'effraction). Les hackers sont autrement plus calés que dans ce cas d’école (qui a fait son temps), maîtrisent de nombreuses techniques qui font et feront encore beaucoup ravages. Ils possèdent avant tout d’excellentes connaissances pour agir « masqués », invisibles.
Nombreux, comme notre développeur Florian travaillent pour la bonne cause en étant motivé que par l’exploit et sur commande, à l'occasion d’un audit de sécurité par exemple.

Conclusion :

Avant de vous lancer dans un projet informatique ambitieux et complexe, pourquoi ne pas vous armer de quelques connaissances de base, aborder les aspects techniques, demander au mécano du web « à voir un peu sous l'capot » de quelques-unes de ses réalisations. Nous le faisons bien lors de l'achat d'une voiture...
Vous pouvez également choisir d'être accompagné par un expert avisé et impartial vis-à-vis de votre futur projet ou par un de vos collaborateurs informaticiens.
Bref, je vous déconseille de choisir un prestataire « à l'aveugle » en éludant la question et surtout si ce dernier vous invite à le faire.

En espérant que pour certains « la lumière fût » en lisant cette prose un peu technique, mais tout de même allégée d'un peu d'humour, nous vous invitons maintenant à poser vos questions, partager vos connaissances, vos expériences bonnes ou mauvaises sur le sujet.

Du code lisible et sécurisé tu développeras
4.8 (95.71%) 14 votes

Partager sur Facebook
Partager sur Twitter Plein
Partager sur linkedin
Partager sur Google+

5 réflexions au sujet de « Du code lisible et sécurisé tu développeras »

  1. Yann

    Oui, ce billet s'inscrit dans les bonnes pratiques en développement. Mais à qui s'adresse t-il ? Bien souvent, les managers n'ont pas envie d'entendre ou de lire ce genre de discours, parce que pour eux, cela signifie : du temps et de l'argent en plus. Mais comme ils sont contraints d'opérer une politique commerciale assez agressive la plupart du temps, cela signifie : prendre ces ressources sur le projet non pas EN PLUS (à facturer au client) mais EN MOINS (prendre sur la marge). Donc bien souvent c'est "NON". Le manager ne veut pas savoir. Il estime que le dev doit être compétent et intégrer tout cela depuis le début. Et s'il discute avec un autre manager qui lui dit que son dev (dev ou équipe de dév) abat un boulot monstrueux en peu de temps, il pensera que c'est son dev à lui qui est lent et incompétent, plutôt que de se dire que son dev (ou équipe de dev) livre un code propre, commenté et respectant les bonnes pratiques, et donc qui mène une veille technique continue : tout ça prend du temps, mais ce n'est jamais directement comptabilisé dans le temps passé au projet. Du coup c'est inutile pour le manager...

    Vous l'aurez compris, mon discours est volontairement cliché mais en plus de 17 ans de carrière dans le web j'ai croisé pas mal de managers de cet acabit. Leur parler de dette technique est bien souvent une cause perdue d'avance. Ils te diront qu'ils comprennent, mais qu'à la fin du mois il faut payer les salariés, grâce à des clients gagnés au travers de prix "compétitifs" (je ne rentre pas ici dans le grand débat sur la mondialisation et l'outsourcing de SSII/ENS et grosses compagnies IT qui font coder la majorité de leurs logiciels/apps/sites à l'étranger).

    Bref, pas toujours facile.

    Quant à la cible des développeurs, je suis 100% d'accord sur ce passage (je cite) "les gens qui agissent ainsi le font souvent avec un égo qui n’a d’égal que leur niveau d’inconscience". Et c'est donc une question d'attitude, de savoir-être, plutôt que de diplôme (ça s'applique à tout, surtout au SEO ^^). Là encore, j'ai des dizaines d'anecdotes de ce genre de cowboys développeurs, qui sur le moyen/long terme coûtent très cher à leur employeur, du fait que les collègues doivent repasser derrière eux et refactoriser tout ou partie du code.

    Mais ces cowboys s'en fichent car sur les plannings de gestion de projet, ils sont toujours dans les temps...

    Bref, le code touche tout le monde. Je reformule : Bref, la qualité touche tout le monde. Et la qualité à un prix. DONC : les hackers ont de beaux jours devant eux.

  2. jm Auteur de l’article

    @Yann
    Ton constat est malheureusement encore d'actualité, et ce dans tous les domaines. De nos petits déboires personnels à l'état de notre planète, on peut se dire que la médiocrité a encore de "beaux" jours devant elle...
    En même temps, comme dirait l'autre, on voit partout de plus en plus de gens qui luttent pour changer ça. Un manager averti en vaut deux et nous avons parmi nos clients nombre d’entre eux qui partagent désormais un de nos credo : "le moins cher c'est l'plus cher".
    Une terre, des océans rendus toxiques génèrent des aliments toxiques. Cette obsession du rendement à court terme doit mourir si l'on veut que l'Homme vive.
    À notre petit niveau, on essaye de faire prendre conscience des choses, que ça ne coûte finalement pas si cher de bien travailler, que c'est très rentable pour vous chers clients à long ou moyen terme, de produire du code "BIO" ; )

  3. Yann

    Tout à fait. Ça vaut le coup d'essayer de faire évoluer les mentalités. Comme on dit "les petits ruisseaux font les grandes rivières." 🙂

  4. Consultant SEO Paris

    Un autre point important, à part la lisibilité du code : l’évangélisation de la bonne pratique en interne (les DEV), mais aussi pour ceux qui sont amenés à “trifouiller” le code, comme les SEO. La bonne pratique doit être utilisée par tous les intervenants.

  5. Chartier Mathieu

    Super article, bravo. Il résume parfaitement ce que doivent penser beaucoup de développeurs, référenceurs, etc.
    Je dirais même que le comble dans l'histoire, c'est que parfois ce sont les meilleurs développeurs, qui programment en POO dans plein de technologies, qui commentent le moins ou qui prennent de mauvais réflexes. C'est un peu comme quand on conduit une voiture, il y a ce que les conducteurs devraient faire, et ce qu'on constate malheureusement sur la route... ^^
    Pour ma part, j'essaie de respecter au maximum les standards PSR (http://www.php-fig.org/psr/) pour que tout le monde puisse s'y retrouver. Après, que le développeur mette une tabulation ou 4 espaces, je m'en fous, mais dans l'idée, c'est ainsi que l'on devrait faire pour tous mieux s'y retrouver...

Partagez sur :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *