Audit PHP : sécurité et bonnes pratiques

PHP_LOGO

Créé en 1994, PHP (Hypertext Preprocessor) est un langage de programmation très répandu sur Internet.

C’est un langage puissant, facile à aborder et permissif.
De ce fait, il est fréquent de retrouver des codes PHP qui ne respectent pas les normes élémentaires de sécurité et de bonnes pratiques.

Cet article est un aide-mémoire qui dresse une liste (non exhaustive) des points à contrôler dans le cadre d’une revue de code.

Cryptographie en java 1/3 : Notions de base

Trois billets pour expliquer les notions élémentaires de cryptographie, comment les mettre en œuvre sous linux puis dans une application JAVA.

Clé privée / clé publique

La clé privée et la clé publique sont similaires dans leur présentation (un fichier contenant une longue chaîne de caractères) mais diffèrent par leur utilisation. La seule différence est le fait qu’on peut générer la clé publique à partir de la clé privée, alors que l’inverse est évidemment faux. Pour le reste il est possible de crypter un fichier avec l’une des deux clés, et ce message pourra être décrypté avec l’autre clé.

Les autres différences résident dans l’utilisation qui est faite de ces clés, la clé publique est destinée à être distribuée alors que la clé privée doit rester à l’usage exclusif de son propriétaire.

La clé privée a trois usages :

  • Générer la clé publique
  • Signer un document
  • Décrypter un fichier crypté avec la clé publique

La clé publique a deux usages :

  • Crypter un fichier
  • Vérifier la signature d’un document signé à l’aide de la clé privée

En pratique cette paire de clé est utilisée pour deux raisons :

  • Crypter un fichier avec la clé publique, cela permet permet de garantir que seule la personne qui possède la clé privée pourra lire le message.
  • Crypter un fichier avec la clé privée et envoyer à la fois le fichier crypté et le fichier en clair. Cela permet à toute personne possédant la clé publique d’utiliser cette clé pour décrypter le message et de comparer le résultat avec le fichier en clair. Si les deux fichiers sont identiques, on est certain que le fichier original a été crypté par quelqu’un possédant la clé privée. Les mécanismes de signature électronique sont basés sur ce principe.

Certificats électroniques

Un certificat est destiné à lier une clé publique à son propriétaire. Je dois demander à un organisme spécialisé, appelé autorité de certification, de signer ma clé publique en utilisant sa clé privée. Le rôle de l’autorité de certification est de vérifier mon identité avant de procéder à la signature.

Le résultat de cette signature, clé publique + clé publique cryptée, est placé dans un fichier appelé certificat. Ainsi toute personne possédant la clé publique de l’autorité de certification peut confirmer que cette autorité de certification a « validé » ma clé publique. Je peux donc distribuer mon certificat et chacun pourra vérifier que la clé que je distribue m’appartient bien.

Il est également possible de vérifier auprès de l’autorité de certification si le certificat est toujours valide. Si je sais que quelqu’un a eu accès à ma clé privée, il me suffit d’avertir l’autorité de certification qui après avoir vérifié mon identité va révoquer mon certificat. Mon certificat sera donc ajouté à une « liste noire ».

Chaîne de certificats

Si une autorité de certification se fait dérober sa clé privée, tous les certificats créés à l’aide de cette clé sont suspects, car toute personne possédant la clé privée a la possibilité de créer un certificat. Dans un cas pareil, l’autorité de certification déclare que sa clé est compromise. Les éditeurs de logiciels vont alors mettre à jour la liste des autorités de certification acceptées dans les navigateurs (ou tout autre logiciel nécessitant une authentification). Les faux certificats, comme les vrais, seront donc refusés par les navigateurs.

Pour éviter que tous les certificats d’une autorité particulière ne soient invalidés d’un coup, on utilise une chaîne de certificat. Une clé privée unique permet de certifier un certain nombre de clés publiques. On parle alors de certificat intermédiaire. Les clés privées liées à ces clés publiques sont à leur tour utilisées pour certifier d’autres clés et ainsi de suite. Ainsi la compromission d’une clé à de moins grandes conséquences. La clé « Racine » est par ailleurs relativement facile à protéger car on n’en a plus besoin sauf pour créer éventuellement d’autres certificats intermédiaires.

Evidemment le problème de la validité de la clé « Racine » se pose. C’est aux éditeurs de logiciels de décider à quelles autorités de certifications ils font confiance et d’ajouter les clés publiques correspondantes dans leurs logiciels. Pour JAVA par exemple, les certificats racine sont stockés dans le fichier « jre/lib/security/cacerts ».

Checklist d’audit de sécurité pour Drupal

Pourquoi cette check-list d’audit de sécurité pour sites Drupal ?

Le nombre de sites développés avec Drupal est impressionnant. Certains respectent scrupuleusement toutes les bonnes pratiques de développement, d’autres ne les respectent pas, pour des raisons diverses et variées : manque de compétences de l’équipe, délais trop courts, …

Ne pas respecter un minimum de règles de sécurisation, c’est prendre le risque de voir son site attaqué, ses données perverties ou volées, c’est aussi prendre le risque de voir son image écornée.

[Spring Security] Authentification par certificat

ssLogo

Dans le cadre du projet sur lequel je travaille en ce moment j’ai dû mettre en place le framework Spring Security. Le niveau de sécurité élevé demandé par notre client nécessitait une authentification par certificat signé en SHA-256. Je vais donc vous expliquer comment mettre en place Spring Security sur un projet maven et comment configurer une authentification par certificat.

Présentation de Spring Security

Spring Security est un framework d’authentification et de contrôle d’accès.
C’est est un sous-projet de Spring, il a été lancé en 2003 sous le nom d’Acegi Secuirty. En 2007 il sera renommé Spring Security. C’est l’un des projets les plus avancés de Spring.
Liste des projets Spring : http://www.springsource.org/projects

Composants Open Source : retour sur investissement en minimisant les risques

Comment accroître les bénéfices de l’Open Source dans le cycle de développement d’application tout en réduisant les risques induits ?

C’est un scénario que de nombreux développeurs Java ont déjà rencontré et qu’ils redoutent. En vous connectant à votre messagerie, vous découvrez des messages de panique du Directeur de la sécurité, du Directeur des Etudes ou du Directeur commercial. Un composant Open Source fréquemment utilisé contient  une faille de sécurité susceptible d’exposer vos applications clients à une attaque. Pire, cette vulnérabilité a été identifiée depuis quelques semaines, mais votre entreprise n’était pas informée.

TechEvening à Lyon sur la sécurité des applications Web

Ce lundi s’est déroulé à Lyon un TechEvening consacré à la sécurité des applications Web. Nous avons testé les différentes techniques et outils utilisés par les utilisateurs malveillants. Deux applications ont été utilisées, l’une en J2EE pour la plupart des techniques (WebGoat 5.3 de la fondation OWASP) et l’autre en ASP.NET MVC 3 pour un focus sur les perfides attaques CSRF.

Au programme:

  • Injection: diverses techniques d’injection SQL;
  • Cross-Site Scripting (XSS): techniques de phishing et de « session hijacking »;
  • Violation de gestion d’authentification et de session: technique de « session fixation »;
  • Références directes non sécurisées: techniques d' »AC Bypass » aux niveaux données et métier;
  • Cross-Site Request Forgery (CSRF): technique du « Token Bypass »;
  • Mauvaise configuration de sécurité: technique de « Malicious File Execution »;
  • Stockage cryptographique non sécurisé: sensibilisation au « hashing » et « salting »;
  • Manque de restriction URL: technique du « forced browsing »;
  • Protection insuffisante de la couche transport: « sniffing », « ARP spoofing » et « ARP poisoning »
  • Redirections et renvois non validés: techniques du « HTTP splitting » et du « cache poisoning »

Nous avons utilisé les outils suivants:

  • Firefox
  • Fiddler
  • Firebug
  • TamperData
  • WireShark

Vous pouvez retrouver ci-après tous les supports:

  • L’application WebGoat 5.3;
  • L’application CSRFDemo ASP.NET MVC 3;
  • Les slides (PPTX ou PDF) de présentation;
  • Quelques fichiers utilisés pour les attaques;

Pour ceux qui s’intéressent plus globalement à la sécurité des applications .NET (pas qu’en Web), je vous invite à lire l’article suivant sur l’altération des assemblages, l’injection de code et la suppression des signatures cryptographiques. Une vidéo est également disponible.

Sécurité des données ? Elémentaire mon cher Java !

Lors de l’introduction de la gestion de la sécurité en Java, les solutions se déclinaient sous forme d’extensions aux noms plus ou moins sympathique comme JAAS, JSSE et JCE, qu’il fallait venir rajouter dans ses applications. Et encore, suivant les régions, toutes n’étaient malheureusement pas disponibles.

Heureusement ce n’est plus que de l’histoire ancienne car désormais, Java propose en standard tous les outils qu’il vous faut pour sécuriser facilement vos données. Intéressons nous en particulier à deux aspects : La génération d’empreinte de fichier et le chiffrement de ces derniers.