Discussion :

[Stéphane le calme]

Comment rendre nos applications web plus sûres ?
Un développeur énonce les erreurs les plus communes des programmeurs

Dans un contexte où on assiste à une recrudescence des menaces informatiques ainsi que des révélations sur les programmes de surveillance des données à l'échelle gouvernementale comme PRISM, le débat autour de la vie privée et la protection des données digitales se voit relancé.

Nombreux sont ceux qui ont opté pour une sensibilisation de l'utilisateur à la sécurité, espérant certainement leur offrir un moyen plus sûr de se protéger. Un journaliste de technologie, ancien programmeur professionnel, a quant à lui choisi une autre approche quand il a répertorié les six erreurs les plus reproduites par les développeurs relatives à la sécurité, erreurs qu'il n'a pas manqué de qualifier de stupides.

La première erreur qu'il met en évidence est une mise en garde bien souvent répétée aux apprentis webmaster : « ne jamais faire confiance aux données utilisateur ». Il invite les développeurs à faire attention aux types de données qui transitent sur leurs sites. « si vous êtes chanceux les données en provenance de vos utilisateurs pourraient entraîner un plantage de votre application ou la rendre moche » rappelant que certains utilisateurs intelligents et mal intentionnés pourraient effacer votre base de données ou pire encore. « Vérifiez que le type de données que vous attendez est bel et bien celui que vous recevez, pas plus pas moins ».

Pour lui, monter son propre système de chiffrement est une mauvaise initiative. Il préconise l'utilisation de solutions ayant déjà fait leurs preuves. Il remarque également que beaucoup de développeurs, surtout du côté des novices, accordent trop facilement des privilèges d'administration. De plus il recommande de penser à la gestion d'erreurs : « C'est souvent lorsque votre code échoue que vous êtes le plus vulnérable » rappelle-t-il. Et enfin il préconise l'utilisation des protocoles SSL/HTTPS. « Il y a une raison pour laquelle Google se sert de HTTPS » assure-t-il en expliquant que la connexion en devient plus sûre.

L'avis d'un développeur : nous avons demandé à un membre de notre communauté, gangsoleil, de commenter ces propos. Pour lui, un des problèmes actuels de la sécurité des applications vient du fait que les développeurs n'ont pas été formés sur le sujet et il précise « Attention, je ne dis pas qu'ils ne savent pas développer une application, je dis qu'il leur manque quelques bases, que j'estime fondamentales, sur la conception logicielle. »

Il soutient l'avis du journaliste qui estime qu'un développeur devrait envisager le pire dans une métaphore très imagée : « De même qu'un avion doit être capable de voler aussi bien lorsqu'il fait beau que dans un orage, un code doit fonctionner dans les conditions normales, mais aussi dans les pires conditions. ». D'ailleurs à ce propos il donne en exemple un cas de figure à prendre en considération lors d'une conception : « Votre code se sert d'un fichier ou d'une base de données ? Oui, il doit être capable de ne pas crasher si je supprime (violemment) le fichier ou la base de données. »

Toutefois il n'est pas convaincu par l'exemple pris par le journaliste sur Google « Enfin, quant au fait que Google utilise HTTPS, je trouve cet exemple assez mauvais car Google n'utilise toujours pas HTTPS comme protocole par défaut pour la recherche -- d'où le plugin HTTPS everywhere de l'EFF. »

Source : Venturebeat

Et vous ?

Avez-vous remarqué d'autres erreurs chez les développeurs ?

Que préconisez-vous pour améliorer la sécurité des applications ?

[Uther]

Cet article enfonce beaucoup de portes ouvertes. Ces problèmes de sécurités principaux sont bien sur tous connus depuis longtemps et il est aisé de se renseigner dessus.
Le vrai souci pour moi, c'est que les sociétés ne prennent pas le temps de s'intéresser a la sécurité des applications car ça a un cout que la grande majorité des entreprises n'est pas prêt a payer.

Quant au SSL, c'est juste un point parmi tant d'autre et certainement pas le plus prioritaire. Ça évite certes que les saisies de l'utilisateur puisse être interceptés par un tiers au milieu. C'est pas difficile a mettre en place et on voit immédiatement un joli cadenas faussement rassurant.
Mais si le site web en lui même n'est pas sur, c'est bien plus dangereux et facile à exploiter.

[GeoTrouvePas]

Merci pour cet article qui rappelle des concepts essentiels que l'on devrait avoir en tête en permanence. On pourrait même enlever le mot "web" dans le titre tellement ces recommandations me paraissent "universelles" (mise à part pour le HTTPS bien évidement).

Je suis particulièrement attaché au principe de ne jamais faire confiance à l'utilisateur. On dit souvent, par provocation, qu'il faut partir du principe que "l'utilisateur est un con". Ce n'est évidemment pas l'expression d'un mépris vis à vis de l'utilisateur mais simplement une façon de dire qu'il faut sans cesse imaginer le pire. Le seul moyen de s'en protéger est de contrôler systématiquement la qualité des données.

[imikado]

Premier conseil: utiliser des frameworks
Deuxieme conseil: regarder et repertorier les outils et méthodes à utiliser pour sécuriser votre application

Le mkframework, (par exemple) propose une page listant les failles de sécurité, les parties prises en comptes par le framework ainsi que celles à la charge du développeur: http://mkdevs.com/security.html

[n5Rzn1D9dC]

Ca me rappel il y a quelques temps où je suis tombé sur un site gouvernemental qui se servait de la valeur "host" du header http pour créer une grande quantité des liens de chaque page du site.
Donc en mettant une ip en host (n'importe quelle ip ou nom d'hote), ça donnait:
http://x.x.x.x/index.html etc...
Et il y avait bien sur pleins de liens pointant vers du js ou des médias en tout genre.

[DrHelmut]

Pour faire des applis sûres (et performantes tant qu'à faire...) il faut :

1. Des développeurs QUALIFIES :

De mon expérience, de nombreux juniors sortent d'école sans savoir correctement développer, avec beaucoup de lacunes en logique booléenne, algorithmique et ensembliste.

Et le web, du coup, n'en parlons pas : il est peu ou pas du tout enseigné, et souvent bien mal. J'ai en tête l'exemple d'une école qui proposait des cours de GWT mais en aucune manière ne parle des fondamentaux du web, de javascript, des appels asynchrones, ect...

A mon sens, la faute incombe donc clairement d'abord aux écoles et à la qualité de l'enseignement, pas aidée par le fait que très souvent les enseignants sont chercheurs mais n'ont jamais pratiqué la 'vraie' informatique..

En second, la faute aux entreprises, qui ne forment pas assez leurs juniors et n'exigent pas non plsu des écoles qu'elle srelèvent leur niveau.

Entre les deux, la faute revient au junior, qui devrait se bouger les fesses et savoir que l'école ne lui apprend au final quasiment rien, et qu'il devrait lire et tester beaucoup de choses s'il veut être un bon développeur !

Et 5 ans après, beaucp de juniors qui étaient dans ce cas devienent alors 'experts techniques" dans les SSII classiques, et du haut de leur grande incompétence qu'ils ne soupçonnent hélas pas, ils réalisent alors des prouesses de mauivais code, et avec du mauvais code, je ne vosi pas comment on peut assurer la sécurité d'une appli... :p

2. Une volonté de MOYENS

Si un client a des exigeances fortes en matière de sécurité, il faut qu'il comprennent que cela a un côut; or, bien des SSII nivellent par le bas pour gagner les appels d'offres, et la réalisations des applications en souffre évidement.
De plus, les DSI sont souvent de simples managers dont les connaissances en informatique font rêver... et eux aussi exigent le mouton à 5 pattes: l'appication faite rapidement, qui est sécurisée, performante, et n'aura pas couté cher. Mais bien sûr...

[DrHelmut]

Premier conseil: utiliser des frameworks

Avec modération, en connaissance du framework (pas un truc obscur fait par deux russes dans leur salon et sans doc) et surtout pas pour un junior !

De plus, autant les frameworks sont des raccourics géniaux je te l'accorde, autant ils ne dispensent pas (bien au contraire) de maitriser en amont les aspets de la sécurité !

[Jarodd]

« Il y a une raison pour laquelle Google se sert de HTTPS »

Etre NSA compliant ?

Il préconise l'utilisation de solutions ayant déjà fait leurs preuves.

Ah oui, c'est bien ça...

[herdans]

Les mesures de sécurité nécessitent un temps de mise en place qui dit délai, dit coût. Les développeurs sont des ouvriers, ils font ce qui est dans le cahier des charges, ni plus ni moins. On peut faire porter le blâme aux développeurs. Mais il n'y a pas de mauvais développeurs, il n'y a que des mauvais chefs. C'est à la hiérarchie d'insister sur l'exigence de sécurité, de fixer la barre et enfin de s'assurer de leur bonne application... le plus tôt possible

[imikado]

Avec modération, en connaissance du framework (pas un truc obscur fait par deux russes dans leur salon et sans doc) et surtout pas pour un junior !

De plus, autant les frameworks sont des raccourics géniaux je te l'accorde, autant ils ne dispensent pas (bien au contraire) de maitriser en amont les aspets de la sécurité !

J'ai bien écrit:

Premier conseil: utiliser des frameworks
Deuxieme conseil: regarder et repertorier les outils et méthodes à utiliser pour sécuriser votre application(sous entendu du framework)

[Johnny P.]

A mon sens, la faute incombe donc clairement d'abord aux écoles et à la qualité de l'enseignement, pas aidée par le fait que très souvent les enseignants sont chercheurs mais n'ont jamais pratiqué la 'vraie' informatique..

En effet la qualité de l'enseignement dans le développement logiciel / projet est déplorables , le but c'est de donner la matière et de pondre du code qui fonctionne mais les enseignants s'en fichent si oui ou non c'est correcte.

Le problème se situe aussi à l'opposé dans le fait que beaucoup de profs n'ont jamais réellement intégré une équipe ou développer un logiciel pro en entreprise ou bien il y a 30 ans en arrière...

Moralité à l'école on n'apprend jamais réellement à bien programmer mais uniquement avec les années et dans le monde pro.

Tout ça pour dire qu'il y'a deux axes : l'école = théorie , entreprise = pratique et l'école pense mieux savoir ce qui se passe en entreprise.

[CodeurPlusPlus]

Mais bien sûr, c'est bien connu, les développeurs qui terminent juste leurs études sont tous de brillants cerveaux et des programmeurs passionnés qui savent appliquer à la perfection tout ce que leur université / école a essayé de leur enseigner. (ironie inside)

En revanche ils n'ont aucun esprit critique, aucune pensée propre, ils ne font que reproduire ce que leurs profs-jamais-au-courant-de-rien leur ont montré. (ironie inside)

En conséquence de cela, il est évident que quand un jeune développeur écrit du code pas assez robuste / sûr, c'est à ses anciens profs qu'il faut jeter la pierre. Il n'est responsable de rien, et eux de tout. (ironie inside)

Si un développeur ne bétonne pas à fond la vérification de toutes les entrées, c'est un âne et puis c'est tout, quelle que soit la valeur de la formation initiale qu'il a reçu. (pas ironie at all)

[messinese]

Bonjour, personnellement je suis tout à fait d'accord sur un point: les dev ne sont que trop (tellement) peu sensibilisé au domaine de la sécurité..pour eux un message d'erreur est simplement un message d'erreur et pourtant c'est en général le signe d'une possible exploitation dont ils n'ont pas la moindre idée!

De meme qu'ils ne voient pas le mal à faire un "printf(var)" et pourtant ceci ouvre une porte non négligeable et j'en passe..

Sorti d'école ou pas c'est la meme chose en matiere de sécurité, ça n'a rien à voir avec les fait de savoir coder ou pas et d'ailleurs que le dev ayant de l'expérience et sachant poser un joli algo sera meilleurs dans le domaine c'est se planter lourdement !

Tant que les boites penseront de maniere académique telle qu'illustré plus haut, la sécurité s'en ressentira il faut juste penser que c'est un monde a part et que bien souvent les "mec dans leur garages" sont bien meilleur que les pseudo ingé sécu ayant 10ans d'expérience!

Combien d'entres eux savent comment exploiter un BoF en full RoP ?
Combien en auront simplement entendu parler?
Comment pourrait il s'en protéger dans ce cas?

Bref tout ça pour dire que la sécu défensive c'est bien, savoir développer de jolies appli aussi mais tant qu'on à jamais abordé ces questions la on ne peux défendre correctement à mon humble avis.

C'est se qu'on appelle l'offsec (securité offesive) et à mes yeux c'est quand meme incontournable quoi qu'on en dise et meme avec les meilleurs outils du monde..


Cdlt.

ps: petit coup de gueule

[gangsoleil]

De mon expérience, de nombreux juniors sortent d'école sans savoir correctement développer, avec beaucoup de lacunes en logique booléenne, algorithmique et ensembliste.

Et le web, du coup, n'en parlons pas : il est peu ou pas du tout enseigné, et souvent bien mal. J'ai en tête l'exemple d'une école qui proposait des cours de GWT mais en aucune manière ne parle des fondamentaux du web, de javascript, des appels asynchrones, ect...

A mon sens, la faute incombe donc clairement d'abord aux écoles et à la qualité de l'enseignement, pas aidée par le fait que très souvent les enseignants sont chercheurs mais n'ont jamais pratiqué la 'vraie' informatique..

Moui.... Faut pas oublier aussi qu'il y a pas mal de developpeurs d'applications qui ne sortent pas d'ecole justement, et donc qui se sont formes "comme ils ont pu", sans savoir s'ils passaient a cote de quelque chose ou non.

Quant aux chercheurs qui n'ont jamais pratique la 'vraie' informatique, nous n'avons clairement pas cotoye les memes...
Je suis d'accord pour dire que dans le domaine de la recherche, les contraintes ne sont pas les memes (delais, fonctionnalites, ...). Mais c'est un autre debat.

Bonjour, personnellement je suis tout à fait d'accord sur un point: les dev ne sont que trop (tellement) peu sensibilisé au domaine de la sécurité..pour eux un message d'erreur est simplement un message d'erreur et pourtant c'est en général le signe d'une possible exploitation dont ils n'ont pas la moindre idée!

Et le premier fautif, ce n'est pas le developpeur, mais le couple commercial/chef de projet qui prefere donner 50 jours pour un logiciel SANS securite que 70 pour un logiciel AVEC.

Ceci dit, tout le monde crie comme quoi les developpeurs ne connaissent pas la securite, ni les bases de l'informatique, ni la compilation, ni ceci, et cela encore moins, et alors je ne vous parle pas de ca, ils n'en ont meme jamais entendu parler :

Combien d'entres eux savent comment exploiter un BoF en full RoP ?
Combien en auront simplement entendu parler?
Comment pourrait il s'en protéger dans ce cas?

BoF en full RoP ? Ah non, jamais entendu parler effectivement (mais je ne suis pas developpeur d'applications web). Mais de mon point de vue, il serait bien plus important d'expliquer aux developpeurs les attaques MitM, DDoS, injection de code, et bien sur des notions de cryptographie (connaitre la difference entre les algo symetriques et asymetriques, SSL, ...)

Mais il semble que tout cela prenne un temps enorme, car chacun a des besoins differents, mais qu'en depit des besoins, le nombre de formation n'est pas infini, et le temps des etudes est deja restreint.

Bref tout ça pour dire que la sécu défensive c'est bien, savoir développer de jolies appli aussi mais tant qu'on à jamais abordé ces questions la on ne peux défendre correctement à mon humble avis.

C'est se qu'on appelle l'offsec (securité offesive) et à mes yeux c'est quand meme incontournable quoi qu'on en dise et meme avec les meilleurs outils du monde..

Mais il faut aussi voir qu'il y a des notions que tout le monde devrait partager (un peu de securite ne fait pas de mal), mais qu'il n'est absolument pas necessaire que tout le monde soit expert en securite !

[messinese]

Oui bon je suis peut etre allez un peu fort, certes mais de mon expérience un dev ne SAIT pas sécuriser ses codes de maniere générale car ils NE SAVENT pas (ou trés trés rarement) comment identifier les risques, il est la le soucis a la base.

Aprés l'idéal serait d'avoir des experts sécu réalisant des audits réguliers mais ça c'est pas la réalité, la réalité c'est qu'on veux des appli rapidement qui soient jolie, pratique et fonctionnelles rapidement, l'aspect sécuritaire est, comme souvent , passé au second plan jusqu'au jour ou... et la on se réveille mais il est trop tard :/ .

[JCB001]

Si l'on veut rendre un logiciel plus sur, de meilleures qualités il y a plusieurs axes :
le développeur est le point central, qu'on le considère comme un ouvrier, un artisan ou un ingénieur, c'est lui qui codera.
Un "bon" développeur codera propre, avec peu de bugs et l'application sera aussi performante qu'elle doit l'être.
On peut discuter à l'infini de sa formation... elle ne sera jamais parfaite et aucune école ne pourra lui apprendre tous les frameworks existants, le plus important est une tête bien faite pas une tête bien pleine, un gars (ou une fille) intelligent (e), motivé, mal formé arrivera à s'autoformer et à compenser ses lacunes avec de l'expérience.

De par mon expérience personnelle de 15 ans en tant que développeur puis chef de projet technique j'ai constaté une moyenne de 10-20% de développeur médiocre... ce que j'appelle médiocre c'est du code de mauvaise qualité (mauvaise gestion d'erreur, bugs nombreux, code redondant partout, usine à gaz, etc...). Former de tels personnes à développer propre est une gageure, même après des mois d'effort et de temps perdu les progrès sont souvent faibles (et quand ce sont des prestataires censés être opérationnels vous n'allez pas leur payer une formation !!! )

Comme c'est le développeur le plus important cela veut dire qu'il faut surtout bien recruter, donc la clef est d'avoir de bons rh et avec un politique salariale correcte (très important) et être capable d'évaluer le niveau technique du candidat sans se laisser "baratiner".
En même temps ne pas se focaliser sur des détails peu importants par rapport au job visé, j'ai vu ainsi dans mon entreprise un gars semble t-il doué ne pas être recruté car il parlait mal français (il était chinois je crois) mais maîtrisait l'anglais et devait travailler en interne, j'ai trouvé que c'était dommage, il vaut mieux un gars compétent,motivé qui améliorera son français très vite qu'un gars incompétent ou fainéant qui maîtrise le français.

[parou]

Maintenant il faut être réaliste aussi

Aucun site n'est 100% à l'abris d'une attaque si ce n'est pas le code qui est attaquer ce sera le hardware ou la couche network ...

ce que l'ont peu demander à un programeur c'est de faire au mieux ...

car pour 2 heures de temps accordé à la sécurisation d'une apllication un hacker lui peu prendre tout son temps qui peu alors compter en jours .... en mois avec l'aide d'une communauté pour parvennir à passer outre les défense mise en place.

L'utilisation d'un framework est une bonne solution cependant même en utilisant un framework il faut continuellement suivre les mise à jour de ce framework ... étudier minutieusement toutes les release note ... car les failles du framework sont public à partir du moment ou la release note est disponnible ...

De plus il est interessant pour un hacker de s'attaquer au Framework .... une faille trouvée leurs donnes alors une multitude de victime potentiel ...

donc malheureusement pas de solution miracle juste essayer de limiter la casse c'est déja pas mal ...

[imikado]

@parou
Une application n'est jamais sur à 100%, mais comme pour son domicile, cela n'empêche pas de mettre une serrure à sa porte

C'est pour cela qu'il faut pour les applications web "publiques" critiques les faire auditer par une société dont c'est le métier.

Idem pour le framework, le faire vérifier, voir donner les sources à ces sociétés pour qu'elle aient toutes les cartes en main pour éprouver la sécurité de vos applications.

[transit06]

Pour faire de la très haute qualité, il faut 3 points essentiels:
1) L'argent, "le nerf de la guerre" , pour payer les matières premières de qualité et les ouvriers qualifiés.
2) Le temps, on ne fait pas de la quasi-perfection dans le même temps ou l'on fait de l'approximatif.
3) De la sérénité!!! . Sans sérénité rien de bon ne sort.

La sécurité à un cout!!!

Quand à dire, qu'il n'y a pas de mauvais programmeurs, mais de mauvais chefs ???
Il y a des mauvais et des bons partout, tout le monde peut se tromper ?

"Si vous fermez la porte aux erreurs, la vérité restera dehors" Poète indien dixit.
Allez A+