Le monde de la sécurité web est impressionnant. Il regorge d’attaques parfois bien tordues, et difficiles à comprendre, et une fois de temps en temps, on nous “découvre” une nouvelle technique. Cette fois-ci c’est CSRF. Le point particulier de ce genre d’attaque, c’est qu’il n’y a rien de nouveau à savoir, n’importe qui ayant fait un tout petit peu de web la maîtrise déja… mais jusqu’ici sans le savoir. Bref, si cela doit démontrer une chose, c’est que personne ne maîtrise [plus] la sécurité du web.

Le point le plus amusant avec CSRF, c’est qu’il s’appuie sur une fonctionnalité fondamentale du web, présente depuis les version les plus antiques de HTTP : la possibilité d’inclure et d’adresser des éléments depuis d’autres sites web. Depuis quelques années, nous nous moquons des institutions dont les avocats ont créé une charte Internet qui interdit la création de liens hypertextes ou l’inclusion d’image ou d’autres objets sans leur accord. Avec CSRF, la question se pose : et s’ils avaient eu raison ?!

La plupart des projets développés en Logiciels Libres s’appuient sur des communautés de développeurs, qui se créent et évoluent au fil du temps selon les intérêts et talents de chacun. La méritocratie à la base de la constitution de ces communautés est-elle bien suffisante pour garantir l’intégrité des développeurs qui rejoignent un projet ?

Il semble que les projets LL disposent de peu de critères objectifs et stricts pour décider d’accorder à un contributeur des droits d’écriture sur tout ou partie du code. Les système simplement basés sur le vote des membres en place sont attaquables, par exemple par des attaques sociales. Un attaquant peut tâcher de devenir sympathique aux yeux de quelques membres clés, et cela peut suffire, en manifestant sa présence sur un salon IRC, et en envoyant les bons patches au bon moment…

Mettons nous à la place de vendeurs de Logiciels propriétaires/privatifs, qui n’ont pour certains eu de cesse ces derniers temps que de décrier les Logiciels Libres pour défendre leur bifsteak. Les moyens mis en oeuvre par ces acteurs sont parfois douteux, comme on le voit plus ou moins couramment lors de certaines campagnes de lobbying auprès d’institutions politiques. Ces vendeurs/éditeurs disposent de moyens colossaux, et peuvent vouloir nuire à tel ou tel projet, voire vouloir discréditer le Logiciel libre dans son ensemble. Si j’étais à leur place, je considérerais que payer des “taupes” pour infiltrer des projets et y semer du code dormant sur la durée pourrait être un moyen relativement efficace de parvenir à mes fins.

À la place, notamment, des distributions Linux, je me méfierais.

Suggestions :

• Formaliser un délai minimum et incompressible entre les premiers contacts avec un développeur et son admission au titre de commiteur
• Formaliser une politique sur le volume de code envoyé avant de gagner le moindre droit de commit
• Formaliser une procédure de parrainage
• Exiger une preuve d’identité de chaque développeur (et pourquoi pas un jour mettre en place une liste noire centralisée d’indésirables ?)

Aucun de ces moyens ne suffit à garantir l’intégrité d’un développeur, mais leur application conjointe pourrait ralentir considérablement les agissements d’un attaquant.

Le développement de logiciels libres relève, dans la plupart des cas, d’une initiative communautaire.
Une communauté de développeurs s’agglomère autour d’un projet, de manière relativement naturelle, en fonction des intérêts et des compétences des contributeurs.
Ainsi, pour joindre un projet et contribuer à son développement, il faut :

• s’y intéresser. Que ce soit de manière personnelle, ou pour le compte d’une entité qui pousse à le faire contre un intéressement matériel, par exemple.
• l’intéresser. Il s’agit de la fameuse notion de méritocratie que nous trouvons dans nombre de grands projets.

Tout est question de confiance et de légitimité gagnée. Logiquement, un contributeur qui propose ses compétences sur un projet ne reçoit pas au départ une très grande confiance : ses patches sont relus et (éventuellement) appliqués par d’autres, on ne lui demande pas son avis pour les questions d’architecture.
Quand la sauce prend (après quelques patches*(semaines|mois|années)), le projet peut commencer à reconnaître ce contributeur, et à lui attribuer des fonctions officielles. C’est ainsi que l’on gagne son “droit de commit”.

Ce modèle permet aux acteurs de se connaître avant de s’accorder la confiance de modifier le coeur des projets en question.

Bien entendu, les procédures diffèrent selon les projets. Très souvent, tout ceci est extrêmement informel. Mais pour certains gros projets, les choses ont été quelque peu structurées. Le projet Apache, par exemple,

• fait voter les membres pour déterminer si une personne devrait gagner des droits de commit
• exige la signature papier d’un accord au sujet de la propriété intellectuelle du projet : http://www.apache.org/licenses/icla.pdf.