Les 18 et 19 mai, Sébastien Gioria, chapter leader d’OWASP pour la France, a donné une formation dans les locaux d’Agile Partner sur la sensibilisation à la sécurité applicative.

En guise de mise en bouche, nous avons passé en revue un panorama d’attaques récentes de différentes ampleurs et des moyens utilisés. A partir de ces exemples, on constate que tout système d’information est vulnérable d’une manière ou d’une autre. Contrairement à l’idée populaire, les attaques “réussies” résultent de plusieurs vulnérabilités mises bout à bout (par exemple un serveur mal configuré qui laisse échapper des informations sur l’architecture permettant à l’attaquant d’identifier des vulnérabilités logicielles). Les impacts d’une attaque peuvent être variés : financier, pénal, perte ou vol d’information, la plus grave étant souvent l’atteinte à l’image de marque.

Carte d’identité

Nom: OWASP (Open Web Application Security Project)

Genre : communauté en ligne

Dates clés : créé le 9 septembre 2001 par Mark Cuphrey, la fondation a été enregistrée en 2004 aux Etats-Unis et en 2011 en Europe

Particularités : libre et ouverte à tous, elle propose à un vaste public des méthodes et outils de sécurisation des applications

Dans la majorité des cas, une attaque informatique repose sur une faiblesse d’un logiciel (saisies utilisateur ou appels système mal contrôlées, paramétrage incorrect, …).

On peut distinguer 2 familles de langages de programmation ayant leurs propres faiblesses :

• Les langages gérés qui sont pseudo-compilés (Java, .NET, Flash) ou interprétés (PHP) pour être indépendants de la plateforme matérielle
• Les langages compilés (Assembleur, C, C++) fortement liés à une architecture

Pour les langages gérés, on rencontre des failles de type Injection SQL, XSS (Cross-site scripting) ou encore exécution de code arbitraire, tandis que les langages compilés sont sensibles à la corruption de la mémoire ou aux appels systèmes imprévus.

La découverte d’une faille peut résulter du travail de chercheurs, d’éditeurs de logiciel ou d’anonyme et peut représenter une valeur marchande importante. Une faille ne devient véritablement dangereuse qu’à partir du moment où il existe un programme en tirant partie.

Tout logiciel (à code source fermé comme ouvert) présente une surface d’attaque. Il est par conséquent primordial de tenir à jour tous les éléments du système d’information (système d’exploitation, service de publication web, application). On peut trouver sur internet toutes sortes d’outils permettant d’identifier des systèmes non-protégés (par exemple shodan.io qui permet de trouver toute sorte de systèmes connectés à internet) et de professionnels dont le travail consiste à trouver et / ou exploiter des failles (Zero Initiative Day, Zerodium).

Actuellement, les logiciels web sont les plus répandus et leur sécurisation représente le plus grand enjeu.

Chiffrement des données

La sécurité des données d’un tiers (entreprise, particulier, …) passe par le chiffrement et la signature du contenu pour garantir leur intégrité.

 

Le 1er objectif est atteignable en utilisant soit le chiffrement symétrique (la même clé est utilisée pour chiffrer et déchiffrer), soit le chiffrement asymétrique (la clé dite “publique” permet de chiffrer un message que seule la personne ayant la clé “privée” correspondante pourra déchiffrer).

Le 2nd objectif repose sur les fonctions de hachage générant une signature pour un message donné.

On retrouve ces outils dans la production de certificats électroniques, destinés à garantir l’identité de l’interlocuteur sur le web et à communiquer avec lui sans qu’un tiers ne puisse connaître les informations échangées.

La confiance dans un certificat électronique est basée sur une chaîne de confiance. Les navigateurs web embarquent les certificats de tiers de confiance, appelés “Autorité de Certification (CA)”. Ces dernières sont chargées de garantir l’identité des tiers pour lesquels elles ont émis des certificats.

Ces mécanismes sont fréquemment utilisés avec le protocole HTTP qui est à la base de la navigation sur internet. Malheureusement celui-ci a peu évolué depuis sa création et n’intègre pas nativement de sécurité. De base, ce protocole permet à un pirate d’intercepter, altérer ou usurper une identité.

Pour répondre à cette problématique, l’IETF (Internet Engineering Task Force) a mis au point les standards SSL puis TLS. TLS peut être utilisé conjointement à de nombreux protocoles : HTTP (alors appelé HTTPS), FTP, LDAP ou encore SMTP. Les protocoles SSL et TLS font l’objet de nombreuses recherches en vulnérabilité depuis 2014 (Poodle, Freak, Heartbleed, …) dont certaines ont permis de déchiffrer le contenu du trafic chiffré. A ce jour, il est d’ailleurs fortement recommandé de n’utiliser que TLS 1.3, les autres versions et SSL ayant des vulnérabilités connues et exploitables facilement.

Principes de code sécurisé

La sécurisation d’une application se joue de la conception à l’implémentation. Adoptée en cours de vie d’une application, elle ne fait qu’alourdir les coûts et est contre-productive.

Dans la phase de conception, il faut d’abord déterminer les éléments de confiance (systèmes, données, logiciels, échanges, …). En admettant que le code ne peut pas être totalement sécurisé, à cette étape on peut minimiser la surface d’attaque (par exemple en limitant les points d’entrée), rationaliser les privilèges nécessaires à l’application et prévoir le comportement en cas de plantage (rester dans un état stable et éviter de divulguer des informations). Le principe essentiel à retenir est que l’obfuscation ne garantit pas la sécurité.

A l’étape de l’implémentation, il faut mettre en place un certain nombre de mécanismes de contrôle tels que la validation des données d’entrée / sortie, le traçage, le transport et le stockage sécurisés des données, l’authentification et la gestion des autorisations. On peut citer par exemple la protection contre les injections SQL, l’utilisation de canaux de communications chiffrés (HTTPS) ou encore la trace des actions de l’utilisateur surtout pour des opérations sensibles. Une bonne pratique à observer est de ne pas réinventer la roue et d’utiliser des librairies qui ont été “battle-tested” comme celles de chiffrement par exemple.

SDLC

Comme vu précédemment, pour être efficace, l’intégration de la sécurité dans les développements doit se faire depuis le début du projet. Pour répondre à cette problématique, il est nécessaire de mettre en place un SDLC (Software Development Life Cycle). Par exemple dans le cas d’Internet Explorer 6 et 7, le nombre de vulnérabilités découvertes 1 an après leur sortie a été réduit de 35% grâce à la SDLC mise en place par Microsoft. Dans le cas de Windows, on a constaté une diminution de 45% des failles découvertes après 1 an entre XP et Vista.

Il existe plusieurs modèles de SDLC telles que celles du NIST ou de Gartner. La méthodologie Agile peut très bien se marier avec un SDLC, les différentes étapes de sécurisation étant réparties différemment. On peut estimer que la mise en place d’un SDLC pour la sécurité augmente le coût d’un projet de 5 à 15%. Le retour sur investissement est atteignable en prenant en compte la diminution de la maintenance et la gestion d’incident.

Des outils

On trouve sur internet divers outils dans le domaine de la sécurité :

• Le site de l’OWASP recense des bonnes pratiques applicables à différents langages
• Les applications WebGoat et Security Shepperd de l’OWASP pour comprendre le fonctionnement des failles de sécurité dans les applications web
• Les sites de “chasseurs de bug” tels qu’openbugbounty.org dont le but est de trouver des failles dans les logiciels grand public (Windows, iOs, Java, .NET, …)
• Checkmarx et Fortify pour l’analyse du code source

On vous le dit !

Si la sécurisation d’un système d’information peut paraître compliquée à mettre en œuvre et chère, il faut penser à la gestion des incidents et aux coûts engendrés. Outre l’impact financier et technique d’une attaque sur votre site internet, c’est l’image de marque de votre société qui est ternie et risque de vous faire perdre des clients ou passer à côté d’opportunités.

Aujourd’hui, la sécurité d’un système d’information ne peut plus passer au second plan. D’une part car la cybercriminalité est une activité fortement lucrative pour laquelle on assiste depuis plusieurs années à une véritable professionnalisation et d’autre part en raison de nouvelles contraintes légales fortes posées par l’Europe. En effet, des réglementations européennes telles que la RGPD obligeront en 2018 les entreprises à protéger les données des personnes physiques, à contrôler les accès aux données recueillies et à communiquer lors d’attaque de leur système d’information.

Enfin, comme l’a illustré commitstrip, la sécurité doit être pensée dès le début du projet !