• Comment gérer les dysfonctionnements ?
• Comment gérer les déploiements et leurs emplacements ?
• Comment gérer le scaling ?
• Comment gérer les mises à jours ?
• Comment gérer la communication entre les conteneurs ?
• Comment gérer le stockage nécessaire à la persistance des données ?
• Comment gérer les secrets et la configuration ?
• etc.

Tout gérer de manière manuelle et sans surcouche au système de conteneurs n’est pas viable, maintenable et pérenne.

Présentation de Kubernetes

Kubernetes (k8s en abrégé) est un orchestrateur de conteneurs initialement développé par Google en 2015 puis offert à la CNF (Cloud Native Computing Foundation). La solution est développée avec le langage Go (aussi à l’origine de Google).

k8s est leader sur le marché de l’orchestration de conteneurs mais dispose quand même de quelques concurrents: Docker Swarm et Apache Mesos/Marathon.

Comment fonctionne Kubernetes ?

Kubernetes propose une surcouche aux moteurs de conteneurs (ex : Docker, rkt ou CRI) en introduisant la notion de pod.

Un pod est un élément composé généralement d’un conteneur, une configuration réseaux et une configuration sur le stockage. Les pods doivent être considérés comme jetable, ils sont instanciés et détruits au cours de la phase de run d’une application.

Ces pods sont gérés par des deployments. Un deployment définit la configuration des pods, le nombre de répliquas souhaités, la stratégie de mise à jour des pods, etc. C’est grâce au deployment que le nombre de pods actifs demandé est maintenu sur un environnement. En cas de défaillance d’un pod, il est supprimé et un nouveau pod est instancié.

Pour gérer le load balancing et la communication avec les pods, k8s introduit la notion de service comme point unique de communication avec plusieurs pods. Les pods étant « mortels », il n’est pas possible de se baser directement sur leurs IPs.

Pour la même raison, aucune donnée persistante ne peut être stockée au niveau des pods. Pour persister de la donnée, des PersistentVolumes pointant vers des volumes réseaux, des volumes sur AWS (EBS), Azure, etc sont créés au niveau du cluster k8s. Une fois ces volumes créés, un PersistentVolumeClaim doit être créé pour réserver un espace sur un PersistentVolume.

La vision présentée ci-dessus est une introduction. De nombreux autres paramètres et concepts sont proposés par k8s pour définir de manière très fine la gestion des conteneurs.

Exemple concret :
– Création d’un deployment spécifiant 3 répliquas de pods basés sur l’image Docker d’un service web en Java exposant le port 9000.
– Création d’un service exposant le port 80 et redirigeant vers le port 9000 des 3 pods du service web.
– Création d’un PersistentVolume de 100Go basé sur un volume EBS de AWS
– Création d’un PersistentVolumClaim de 10Go avec le mode d’accès « ReadOnlyMany » permettant au volume d’être monté en lecture seul sur plusieurs nodes (worker K8s).

Pour simplifier la compréhension, les exemples ci-dessus sont basés sur l’utilisation du moteur de conteneurs Docker et de son format d’images associé. Kubernetes gère également le runtime rkt de CoreOS.

Pour faciliter l’intégration des moteurs de conteneurs, Kubernetes propose la CRI (Container Runtime Interface) composée d’un API, de spécifications et de librairies. CRI-O est une implémentation de CRI proposant une alternative plus légère au runtime Docker tout en supportant son format d’image. L’utilisation de CRI-O dispense donc de l’utilisation du runtime Docker au niveau des nodes k8s.

Concernant l’installation de Kubernetes, il peut être installé on-premises ou sur un cloud public (AWS, Azure, IBM, etc.). Un bon moyen de tester Kubernetes est de l’installer sur un poste local via minikube.

Comment Kubernetes répond aux questions posées en introduction ?

Les Deployments répondent aux problématiques :

• de dysfonctionnement en assurant que le nombre de répliquas actifs demandé soit toujours respecté.
• de déploiement sur des emplacements spécifiques (node) avec la notion d’affinity et de nodeSelector
• de scaling en ajustant le nombre de répliquas en fonction des besoins
• de mise à jour en spécifiant la stratégie adéquate et en utilisant les mécanismes de rollback

Les Services répondent aux problématiques de communication avec les conteneurs.

Les PersistentVolumes et PersistentVolumeClaims répondent aux problématiques de persistance des données.

Les ConfigMaps répondent aux problématiques de configuration en sortant ces éléments liés aux environnements (préproduction, production, etc.) des conteneurs.

Enfin, la notion de Secrets permet de garder le contrôle sur les données sensibles de type mot de passe, clé d’API, etc.

Ressources

• Site officiel
• CRI-O
• GitHub

Cet article Introduction à l’orchestrateur de conteneurs Kubernetes est apparu en premier sur Blog de Aymeric Lagier.

Le projet propose de découper le développement logiciel en 4 domaines divisés en 12 sous-domaines. On retrouve globalement les différentes étapes du SDLC.

Fonctionnement

Chaque sous domaine est divisé en 4 niveaux de maturité.

• 0 : Niveau implicite de départ
• 1 : Compréhension initiale et mise en place de pratiques de sécurité
• 2 : Amélioration de l’efficacité/efficience des pratiques de sécurité
• 3 : Maîtrise complète des pratiques de sécurité

Pour chaque sous-domaine, plusieurs éléments sont associés à chaque niveau de maturité :

Note : les exemples associés ci-dessous proviennent du niveau de maturité 1 du sous-domaine « Education and Guidance » du domaine « Governance ».

• L’objectif à atteindre pour compléter le niveau de maturité
  exemple :
  – Fournir aux collaborateurs des ressources documentaires sur le développement et de déploiement sécurisés d’applications

• Les activités à mener pour atteindre l’objectif
  exemple :
  – Faire une formation de sensibilisation à la sécurité
  – Ecrire et maintenir des guides techniques

• Les questions à se poser pour évaluer la stratégie de sécurité en place
  exemple : 
  – Les développeurs ont-ils reçu une sensibilisation à la sécurité ?
  – Les membres des équipes projet savent-elles où chercher les guides et bonnes pratiques de développement sécurisé ?

• Résultats attendus après avoir satisfait les objectifs
  exemple : 
  – Prise de conscience des développeurs sur les problèmes de développement les plus communs
  – Application des règles de sécurité de base sur les logiciels
  – Définition d’un niveau de connaissance minimum en sécurité pour les collaborateurs techniques
  – Mise en place de contrôles de ce niveau minimum de sécurité

• Les métriques à mesurer et leurs seuils d’acceptation
  exemple :
  – Plus de 50% des développeurs a été sensibilisé durant la dernière année
  – Plus de 75% des développeurs seniors/architectes a été sensibilisé durant la dernière année
  – Commencer le guide technique dans les 3 mois après la 1re formation

• Les coûts associés
  exemple :
  – Coût de la formation (à construire ou via une prestation)
  – Maintenance du guide technique

• Les acteurs impliqués
  exemple :
  – Développeurs
  – Architectes

• Les autres sous-domaines liés avec les niveaux associés
  exemple :
  – Policy & Compliance niveau 2
  – Security Requierement niveau 1
  – Secure Architecture niveau 1

Comment mettre en place OpenSAMM ?

Pour mettre en place OpenSAMM il faut suivre les différentes étapes proposées :

• 1 – Prepare – Préparer
  objectif : s’assurer de bien démarrer le projet
  activités :
  – Définir le périmètre
  – Identifier les collaborateurs
  – Communiquer sur l’initiative

• 2 – Assess – Evaluer
  objectif : identifier et comprendre le niveau de maturité actuel
  activités :
  – Evaluer les pratiques déjà en place
  – Déterminer le niveau de maturité actuel

• 3 – Set the target – Définir la cible souhaitée
  objectif : définir le niveau cible dans chaque sous-domaine
  activités :
  – Définir la cible souhaitée
  – Estimer les impacts

• 4 – Define the plan – Définir le plan
  objectif : définir le plan pour arriver à l’objectif souhaité
  activités :
  – Définir le nombre de phases pour atteindre l’objectif
  – Définir le planning

• 5 – Implement – Mettre en place
  objectif : réaliser le plan défini
  activités :
  – Mettre en place les mesures nécessaires

• 6 – Roll-out – Mettre à disposition
  objectif : S’assurer que ce qui a été mis en place est utilisé
  activités :
  – Communiquer sur les améliorations
  – Mesurer l’efficacit

Calcul du niveau de maturité d’une organisation

Le niveau de maturité se définit par sous-domaine (« Education & Guidance » par exemple). Il est calculé en fonction d’un barème lié aux réponses aux questions de chaque niveau de maturité.

L’exemple ci-dessous expose le nombre de points à ajouter pour chaque réponse.

Pour le sous-domaine « Education & Guidance », un exemple de réponses serait  :

• Have developers been given high-level security awareness training?
  réponse : Once => 0,2 point
• Does each project team understand where to find secure development best-practices and guidance?
  réponse : Half=> 0,5 point
• Are those involved in the development process given role-specific security training and guidance?
  réponse : No => 0 point
• Are stakeholders able to pull in security coaches for use on projects?
  réponse : Some => 0,2 point
• Is security-related guidance centrally controlled and consistently distributed throughout the organization?
  réponse : Per Team => 0,2 point
• Are developers tested to ensure a baseline skillset for secure development practices?
  réponse : No => 0 point

Dans ce cas le score est de 1,1, ce qui se traduit par un niveau de maturité 1+.

Aide à la mise en place

Pour aider à la mise en place d’OpenSAMM, l’OWASP met à disposition un fichier Excel permettant de :

• Evaluer le niveau de maturité par sous-domaine en répondant aux questions. En fonction des réponses, le score par sous-domaine est automatiquement calculé.

• Proposer en fonction des réponses données ci-dessus une roadmap pour améliorer les scores. Cette roadmap est composée de 4 phases et propose dans chaque itération d’améliorer un ou plusieurs point. L’évolution du score par phase est indiqué.

• Proposer des statistiques sur la situation actuelle et la situation cible.

Ainsi que des graphiques sur l’avancement proposé par la roadmap

Ressources

• Site du projet
• Page sur le site de l’OWASP
• Github du projet
• Contenu du modèle (définitions, barèmes, questions, etc.)
• How to
• Guide de démarrage
• Fichier Excel de calcul
• Fichier Excel d’exemple

Cet article [Cybersécurité] OpenSAMM, modèle de maturité pour le développement d’applications sécurisées est apparu en premier sur Blog de Aymeric Lagier.

L’intégration de la sécurité dans le SDLC intervient à chaque étape de celui-ci et se matérialise de plusieurs manières (threat modeling, review, SAST, DAST, etc.).

Ci-dessous, une liste non-exhaustive d’actions à mener au sein du SDLC pour délivrer une application sécurisée.

Ressources

• Secure Agile Development
  • https://www.owasp.org/images/5/54/Owasp_stuttgart_agile_secure_20150803.pdf
  • https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf
• Code reviews
  • https://www.owasp.org/images/5/53/OWASP_Code_Review_Guide_v2.pdf
• SAST/DAST
  • http://www.veracode.com/solutions/by-need/streamlining-compliance
  • https://www.checkmarx.com/2015/04/29/sast-vs-dast-why-sast-3
• Analyse de dépendances
  • https://info.blackducksoftware.com/rs/872-OLS-526/images/OSSAReportFINAL.pdf
• Plan de réponse à incident
  • https://www.owasp.org/images/9/92/Top10ConsiderationsForIncidentResponse.pdf
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Security_Guide/s1-response-plan.html
• OpenSAMM
  • https://github.com/OWASP/samm/tree/master/v1.5/Final
• ASVS
  • https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf

Cet article [Cybersécurité] Secure Software Development Life Cycle (SSDLC) est apparu en premier sur Blog de Aymeric Lagier.

Malheureusement, lorsqu’une dépendance est installée pour un besoin spécifique, le suivi est rarement fait pour se tenir à jour des nouvelles versions et encore moins des vulnérabilités qui pouvant l’affecter.

Dependency Check

L’OWASP propose un outil nommé Dependency Check permettant de lister et vérifier automatiquement pour toutes les dépendances d’une application si une CVE (Common Vulnerabilities and Exposures) a été publiée pour la version utilisée. La base de données utilisée par Dependency Check est le NVD Data Feeds proposée par le NIST.

Dependency Check est actuellement mature pour Java, .NET et expérimental pour Ruby, Node.js, Python et C/C++. Il est disponible sur la forme d’un plugin Maven, un plugin Gradle, une tâche Ant, un plugin Jenkins ou un executable en ligne de commande. Il existe également un plugin Sonarqube permettant d’intégrer directement les résultats dans les « issues » et les « measures ».

Glossaire

• CVE (Common Vulnerabilities and Exposures) : Dictionnaire public maintenu par le MITRE et permettant d’identifier des vulnérabilités sur des composants logiciel

Exemple :

CVE-2017-9787 – When using a Spring AOP functionality to secure Struts actions it is possible to perform a DoS attack when user was properly authenticated. Solution is to upgrade to Apache Struts version 2.5.12 or 2.3.33.

• CWE (Common Weakness Enumeration) : Classe de vulnérabilités

Exemple : SQL Injection

• CPE Confidence : Indice de confiance sur la reconnaissance d’une dépendance et de sa version
• Evidence : Preuve permettant de déterminer le nom et la version d’une dépendance

Exécution via Jenkins

En intégrant le plugin Jenkins (mode job et pipleline disponibles), Dependency Check peut être exécuté à chaque fois qu’une build est déclenchée.

Les résultats sont ensuite mis à disposition via un lien sur la page « status » de la build :

L’intégration peut être directement faite dans Sonarqube via un plugin :

Les métriques sont disponibles dans l’onglet « Measures » de chaque projet. Suite aux changements intervenus sur Sonarqube 6.x, le détail des vulnérabilités ne peut pas être consulté directement en cliquant sur les liens proposés mais doit être accédé depuis l’onglet « Issues ».

Les métriques Dependency Check peuvent également être intégrées dans le calcul des « quality gates ».

Ligne de commande

Pour télécharger l’exécutable, rendez-vous ici.

Pour lancer une analyse sur une application java, utilisez la commande suivante :

$ ./bin/dependency-check.sh --project Testing --out . --scan [path to jar files to be scanned]

Le résultat est un fichier HTML. Exemple : dependency-check-report

On retrouve une vue un peu plus détaillée que dans les rapports Jenkins ou Sonarqube avec notamment la notion de « confiance » dans l’analyse d’une dépendance.

Pour déterminer qu’un projet utilise ou non une dépendance dans une version donnée, Dependency Check va analyser certains éléments de l’application (pom.xml, Manifest, nom des jars, etc.) et récolter des preuves (evidence) permettant de dresser une liste des dépendances avec leurs versions.

Le nombre de preuves (Evidence Count) est donc mentionné dans les rapports ainsi qu’un indice de confiance dans l’identification de la dépendance et de sa version.

Conclusion

La mise en place d’un outil comme Dependency Check dans une plateforme d’intégration continue permet d’être alertée sans effort sur la présence de vulnérabilités liées à des dépendances au sein d’un application. N’oubliez pas qu’environ 80% du code de votre application n’a pas été écrit par vous.

Ressources

• https://jeremylong.github.io/DependencyCheck/index.html
• https://www.owasp.org/index.php/OWASP_Dependency_Check
• https://github.com/jeremylong/DependencyCheck

Cet article [Cybersécurité] Surveiller vos dépendances avec Dependency Check de l’OWASP est apparu en premier sur Blog de Aymeric Lagier.

Le 27 juin dernier s’est déroulé l’AWS Summit 2017 d’Amazon à Paris dédié à la présentation des services AWS et aux retours d’expériences de différents clients sur l’utilisation de ces services.

Voici des notes sur quelques-unes des sessions présentées :

#Keynote

Vidéo : https://www.youtube.com/watch?v=Fn5jpD_Utn4

Mise en avant

• Clients d’AWS mis en avant : Société Générale, Danone, Veolia, Engie
• 80% des entreprises du CAC40 utiliseraient AWS
• L’ouverture d’un datacenter en France est toujours prévu pour la fin 2017

Retour d’expérience Radio France

• Suite aux attentats de Charlie Hebdo, l’infrastructure en place n’a pas supporté le trafic et les services ont été dégradés pendant 3 semaines
• Suite à ces incidents l’ensemble de l’infrastructure est maintenant sur AWS
• Chiffres :
  • Base de données : 1,5 millions de pages, 1,4 millions de sons et plus de 10To de données
  • Sur un mois : 170 millions d’écoutes, 1000To d’audio écoutés, 150 millions de visites et plus de 20 millions d’internautes

Produits

• AWS Shield pour la protection contre les DDOS : https://aws.amazon.com/fr/shield/
• Athena : Système de requêtes SQL pour interroger S3 (stockage de données) : https://aws.amazon.com/fr/athena/

Session#1 Casser son application pour construire l’esprit devops de son équipe ?

• Retour d’expérience fait par Veolia sur l’organisation de « gameday » pour construire un esprit devops
• Constat initial : « Everything fails all the time »

Organisation d’un gameday

• Objectifs : Casser certains éléments d’un environnement dédié et voir comme se comportent les équipes
• Un gameday doit être ludique

Etapes

• Préparer : création des scenarii, kickoff, cadrage du périmètre, planning
• Faire
• Débriefer :
  • Comment améliorer l’architecture, le monitoring, la configuration des services AWS, etc.
  • Un exemple intéressant : Ils se sont rendus compte dans un scenario que toute l’application était hors service, sauf le endpoint monitoré. Aucune alerte n’était remontée.

Exemples de scenarii

• DROP Table d’une table au hasard
• Arrêt d’un service AWS
• Problème de permission sur un bucket S3
• Charge soudaine sur l’application
• Crash applicatif

Session#2 Patterns et bonnes pratiques des architectures Big Data en Serverless

3 manières d’utiliser le cloud AWS

• EC2
  • Création de VM, installation, gestion du scaling, etc. à la charge de l’utilisateur
• Services managés classique (ex:  Hadoop)
  • L’infrastructure et l’installation sont gérés par Amazon mais l’infrastructure utilisée reste visible de l’utilisateur. Il lui reste des éléments à gérer lui même (scaling par exemple).
• Serverless (ex: Lambda)
  • L’infrastructure est complètement masquée de l’utilisateur.

 Lambda

• L’instanciation et l’exécution des fonctions est faite sur base d’événements (ex : ajout d’un objet dans S3)
• Les fonctions doivent être stateless
• Les fonctions pouvant être supprimées à tout moment, il faut faire attention au temps d’initialisation engendré par un démarrage à froid (cold start)
• Il est recommandé de n’utiliser les VPC (réseau virtuel) qu’en cas de nécessité pour éviter les problèmes de performance
• Si des erreurs se produisent avec Lambda, elles sont remontées dans Cloudwatch
• Utiliser les step functions pour coordonner les functions Lambda

Big data/Machine learning

• Démonstration faite par Corexpert sur la reconnaissance faciale avec Amazon Rekognition.
• Vidéo disponible ici

Session#3 Le continuous delivery au service de la performance

• Objectif : Ajuster le dimensionnement de l’infrastructure en fonction des événements. Par exemple, la finale de la ligue des champions.
• Retour d’expérience de la part de BeINSport

• Chiffres : En 2016, ils ont fait 121 MEP et fait 813 créations de VM

• A retenir, le déploiement doit être :
  • un non-événement
  • indolore
  • pas consommateur en temps

Session#4 Intégrez votre Amazon Lex Chatbot avec vos services de messagerie

• Amazon Lex : interface de création de Chatbot pour de multiples plateformes (SMS, Messenger, Slack, etc.)
• Amazon Polly : Text to Speech
• Ces 2 services ne sont actuellement disponibles que pour l’anglais

Etapes

1- Traduction de la voix en texte
2- Découpage des mots
3- Reconnaissance de mots clés pour correspondre à un scénario (ex : « hôtel » => scénario de réservation d’hôtel)
4- Reconnaissance de mots clé pour pré-remplir certains paramètres nécessaires au déroulement du scénario (ex : Paris => localisation)
5- Pose des questions pour remplir les autres paramètres attendus (ex : date de départ et d’arrivée)
6- Confirmation
7- Amazon Polly pour Text to Speech et pour répondre

Cet article Retour sur l’AWS Summit Paris du 27 juin 2017 est apparu en premier sur Blog de Aymeric Lagier.

Types de scans

Arachni permet de faire des scans actifs ou passifs.

Scans actifs

Ils testent la présence de failles sur les pages web visitées, par exemple :

• Envoie de code malicieux dans les formulaires pour tester les injections SQL ou XSS
• Injection de chemins vers des fichiers locaux dans les URLs (/etc/passwd par exemple)

Scan passifs

Ils sont non intrusifs et ne laissent pas de traces dans les bases de données des application testées. Ils se décomposent en 3 types de détection :

• Vérification de configuration (utilisation de HSTS, présence du flag HTTP_ONLY sur les cookies, etc.)
• Récupération d’informations (méthodes HTTP autorisées, dossiers communs, listing de répertoires, etc.)
• Présence d’informations sensibles (présence d’adresses IP, de numéros de sécurité sociales américains, emails dans les pages HTML)

Configuration

La configuration d’Arachni fonctionne avec des « checks » et des profils.

Checks

Les checks correspondent aux actions qui seront effectuées par Arachni. Ils sont divisés en 2 catégories : Actif et Passif

Actifs

• Code injection
• Code injection (php://input wrapper)
• Code injection (timing)
• CSRF
• File Inclusion
• LDAPInjection
• NoSQL Injection
• Blind NoSQL Injection (differential analysis)
• OS command injection
• OS command injection (timing)
• Path Traversal
• Response Splitting
• Remote File Inclusion
• Session fixation
• Source code disclosure
• SQL Injection
• Blind SQL Injection (differential analysis)
• Blind SQL injection (timing attack)
• Trainer
• Unvalidated redirect
• Unvalidated DOM redirect
• XPath Injection
• XSS
• DOM XSS
• DOM XSS in script context
• XSS in HTML element event attribute
• XSS in path
• XSS in script context
• XSS in HTML tag
• XML External Entity

Plus d’informations sur Github

Passifs

• Allowed methods
• Backdoors
• Backup directories
• Backup files
• CAPTCHA
• Common administration interfaces
• Common directories
• Common files
• Cookie set for parent domain
• Credit card number disclosure
• CVS/SVN users
• Directory listing
• E-mail address
• Form-based File Upload
• HTTP Strict Transport Security
• .htaccess LIMIT misconfiguration
• HTML objects
• HttpOnly cookies
• HTTP PUT
• Insecure client-access policy
• Insecure cookies
• Insecure CORS policy
• Insecure cross-domain policy (allow-access-from)
• Insecure cross-domain policy (allow-http-request-headers-from)
• Interesting responses
• localstart.asp
• Mixed Resource
• Origin Spoof Access Restriction Bypass
• Password field with auto-complete
• Private IP address finder
• SSN
• Unencrypted password forms
• WebDAV
• Missing X-Frame-Options header
• XST

Plus d’informations sur Github

Profils

Les profiles rassemblent ensuite un ou plusieurs « checks » au sein de la configuration d’un scan. Parmi les autres options disponibles, on retrouve par exemple :

• Exclure des paths
• Configuration de l’audit du site web
• Configuration du fingerprinting pour ne jouer que les payloads correspondants aux applications ou technologies utilisées sur le site web audité (gain de performance)
• Gestion des plugins
• Gestion des paramètres HTTP (proxy, nombre de requêtes, etc.)

Lors du lancement d’un scan, il suffit ensuite de renseigner l’URL a auditée et le profil choisi.

Interfaces web

L’interface web est complète en permettant les actions suivantes :

• Configuration des comptes utilisateurs
• Gestion des profiles
• Gestion des agents permettant de déporter la charge sur d’autres machines
• Planification des scans
• Lancement et consultation des scans

Lancement d’un scan

A noter qu’il est possible de déporter la charge du scan sur une ou plusieurs autres machines en fonction des agents configurés (dispatchers).

Liste des vulnérabilités détectées

Les vulnérabilités sont regroupées en fonction de leurs sévérités et de leurs types.

Détails d’une vulnérabilité

Dans chaque détail, il y a la requête HTTP envoyée ainsi que la réponse reçue avec une mise en évidence de la faille détectée (ici du XSS).

Mon avis

J’ai testé initialement Arachni pour effectuer une recherche automatisée de failles XSS sur une application volontairement vulnérable. Après avoir tester ZAP et xsser, Arachni semble être l’outil qui a détecté les failles que j’attendais. Attention toutefois à correctement configurer les profiles pour ne sélectionner que les éléments pertinents. Sans une configuration spécifique, le scan pourra durer plusieurs heures pour un site très simple. Les rapports sont complets et permettent l’identification et la correction rapide des problèmes.

Sources

• Github : https://github.com/Arachni
• Site web : http://www.arachni-scanner.com/
• wiki : https://github.com/Arachni/arachni/wiki
• benchmarks avec les autres outils : http://sectoolmarket.com/wivet-score-unified-list.html

Notes

Attention, les tests automatisés ne remplacent pas les tests manuels

Cet article [Cybersécurité] Scanner les vulnérabilités d’un site web avec Arachni est apparu en premier sur Blog de Aymeric Lagier.

Je suis gêné quand Google lit mes emails lorsque je réserve un hotel ou un avion et me propose les informations sur le terminal de l’aéroport ou l’heure à laquelle je dois partir de chez moi pour ne pas rater mon vol. Ces services sont certes pratiques mais très intrusifs dans ma vie. De la même manière, lorsque je fais des recherches sur un produit qui m’intéresse (ex : une perceuse), je me retrouve avec des pubs de perceuses sur tous les sites que je visite.

Beaucoup de questions peuvent ainsi être posées : Où partent mes données ? Qui peut y avoir accès ? En suis-je encore le propriétaire ? Les services liés à ces informations qui me sont proposés ne sont-ils pas qu’un leurre ? Pourquoi Google, Facebook, etc. sont-ils gratuits ? Pourquoi dit-on de plus en plus souvent « Si c’est gratuit, c’est toi le produit » ?

Le livre surveillance proposé par Tristan Nitot tente de répondre à une bonne partie de ces questions en illustrant les réponses avec beaucoup d’exemples concrets et compréhensibles par tous.

Le livre est présenté en 2 axes majeurs. Le premier dresse un bilan de la réalité concernant les données personnelles (données collectées par les GAFAM, la NSA, pourquoi dois-je me préoccuper de mes données, les lois en vigueur, etc.). Le deuxième axe donne les outils et les philosophies à adopter pour contrôler nos données (l’open source, les outils à utiliser, les configurations à mettre en place, les projets à suivre, etc.).

J’ai trouvé ce livre intéressant pour les raisons suivantes :

• Il peut être lu et être utile aussi bien à un ingénieur en informatique qu’à une mère au foyer
• Il n’est pas extrémiste, c’est à dire que le but n’est pas d’empêcher complétement la collecte des données et donc de se priver d’un outils formidable qu’est internet mais de prendre conscience et reprendre le contrôle
• La liste des contre-mesures est intéressante et bien détaillée
• Tout est illustré par des exemples concrets

Bref, ce livre est à mettre entre toutes les mains.

Vous pouvez le commander sur Amazon et sur le site de l’éditeur C&F.

Cet article Retours sur le livre surveillance:// de Tristan Nitot est apparu en premier sur Blog de Aymeric Lagier.

Pour rappel, la mise en place du protocole HTTPS est maintenant facilitée par l’initiative Let’s Encrypt.

Problématique

Traditionnellement, sur un site web implémentant HTTPS, un utilisateur qui souhaite accéder à la version HTTP est redirigé via une HTTP 301 sur la version HTTPS :

Par exemple sur LinkedIn :

Ce scenario sera répété à chaque fois que l’utilisateur tente d’accéder au site web en utilisant le protocole HTTP.

Le problème avec ce mécanisme de redirection c’est que la première requête sur http://monsite.com est transmise en clair sur le réseau. On imagine qu’elle peut contenir des cookies sans le flag « secure », des données de formulaires, etc. Toutes ces données peuvent être interceptées par une attaque de type « Man in the middle ».

Pour éviter cet aller/retour, il faut indiquer au navigateur que le site souhaité doit être accédé en HTTPS et qu’il doit donc remplacer le HTTP par le HTTPS.

Implémentation

Pour avertir le navigateur que le site doit être utilisé en HTTPS, il faut rajouter le header « Strict-Transport-Security » dans les réponses HTTP renvoyées par le site web.

Ce header dispose de plusieurs paramètres :

• max-age (obligatoire) : durée pendant laquelle le navigateur va accéder au site web uniquement en HTTPS. La valeur conseillée étant généralement de 1an (31536000s).
• includeSubDomains (facultatif) : permet d’appliquer HSTS aux sous-domaines
• preload (facultatif) : permet d’être ajouté à la liste de preloading

Le scenario est donc maintenant le suivant :

Grâce à ce mécanisme, seul le premier accès au site web contient un aller/retour en HTTP. Tout le reste se fait en HTTPS. Afin d’éliminer ce dernier échange non sécurisé, nous allons utiliser le preloading.

Les navigateurs Chrome, Firefox, IE et Edge intègre une liste de sites web implémentant HSTS. Ils savent donc que ces sites web doivent être accédés uniquement en HTTPS. Pour s’inscrire sur cette liste, il faut se rendre sur la page mise à disposition par l’équipe Chromium : https://hstspreload.appspot.com.

Certains pré-requis doivent être satisfaits pour être éligible :

• Avoir un certificat valide
• Rediriger le HTTP vers le HTTPS (comme décrit ci-dessus)
• Tous les sous-domaines doivent être en HTTPS
• le sous-domaine www doit exister
• Avoir le header HSTS (comme décrit ci-dessus) avec les paramètres « includeSubDomains » et « preload ».

Une fois inscrit, il faut attendre la mise à jour de chaque navigateur. Une fois chargé dans les différents navigateurs, le scenario est le suivant :

Compatibilité

HSTS est supporté par les derniers navigateurs (http://caniuse.com/#feat=stricttransportsecurity):

Sur les navigateurs ne supportant par HSTS, le header est simplement ignoré.

Vérification

Pour vérifier que le site web dispose d’un header HSTS valide et qu’il est bien préloadé dans les différents navigateurs, il est possible d’utiliser des outils en ligne comme https://www.ssllabs.com.

Liens utiles

• Documentation : https://developer.mozilla.org/fr/docs/S%C3%A9curit%C3%A9/HTTP_Strict_Transport_Security
• Vérification HTTPS : https://www.ssllabs.com
• Observatoire Mozilla : https://observatory.mozilla.org

Cet article [Cybersécurité] Principe et implémentation de HSTS (HTTP Strict Transport Security) est apparu en premier sur Blog de Aymeric Lagier.

Principe

Une autre manière de se protéger de ce type de faille est de mettre en place le header HTTP Content-Security-Policy définissant la stratégie mise en place pour contrôler les contenus récupérés et envoyés par une page web côté client. Le principe du CSP est de définir quelles sources pourront être utilisées pour les scripts javascript, les styles CSS, les fonts, les POST de formulaires, les requêtes AJAX, etc.

Les sources disponibles sont les suivantes :

• self  : domaine courant
• none : aucun domaine
• all : tous les domaines
• liste de domaines séparés par un espace.

Si un élément n’a pas de configuration, la valeur du paramètre default-src sera utilisée.

default-src dispose de 2 valeurs supplémentaires disponibles :

• unsafe-inline : autorise l’exécution de scripts inline (<script></script). Avec CSP ils sont par défaut interdits
• unsafe-eval : autorise l’utilisation de la méthode eval()

En plus des types de ressources énumérés ci-dessus, d’autres options sont disponibles, entre autres :

• Manipulation du module Anti-XSS des navigateurs
• Gestion de nonce pour les scripts inline (CSP v2)

Récupération de contenu

La quasi totalité des éléments (font, fichiers de style CSS, fichiers javascript, images, iframe, etc.) pouvant être téléchargés et/ou exécutés par une page web peuvent être contrôlés par CSP. Pour chacun de ces éléments il est possible de définir une ou plusieurs sources de confiance.

Par exemple :

• Javascript et CSS : tous les fichiers doivent provenir du domaine suivant : https://cdn.azure.com
• Images : toutes les images doivent provenir du domaine : http://images.azure.com
• Les scripts inline (<script></script>) sont interdits
• Pour tous les autres contenus, n’autoriser que le domaine de la page courante

Se traduira par le header HTTP suivant :

La liste des paramètres est disponible ici.

Envoi de contenu

De la même manière, il est possible de définir une politique pour l’émission de requêtes depuis la page cliente. C’est principalement le cas pour les requêtes AJAX et les formulaires (CSP v2).

Par exemple :

• Requêtes AJAX/WebSocket : N’autoriser les requêtes que vers les domaines : https://api.monsite.com et https://api.sitetiers.com
• Envoi de formulaire : N’autoriser les requêtes que vers le domaine courant

Se traduira par le header HTTP suivant :

Les paramètres sont cumulables avec l’exemple précédent.

Mode reporting

Mettre en place CSP avec une mauvaise configuration peut avoir de lourdes conséquences sur un site web. Si une source est oubliée, on peut facilement se retrouver avec des fichiers javascript qui ne se chargent pas, un site sans style CSS ou sans images par exemple.

A des fins de tests, le header Content-Security-Policy-Report est disponible. Il se comporte comme le header Content-Security-Policy mais ne bloque pas réellement les ressources.

Exemple :

CSP met également à disposition un paramètre report-uri pour notifier une url des violations de stratégies CSP via une requête POST.

Exemple de requête report reçue :

Compatibilité et versions

En terme de compatibilité, la version 1 de ce header est pris en charge par les dernières versions de principaux navigateurs :

Source : http://caniuse.com/#feat=contentsecuritypolicy

La version 2 n’est quant à elle pas encore disponible partout :

Source : http://caniuse.com/#feat=contentsecuritypolicy2

Sur les navigateurs non compatibles, le header est simplement ignoré.

Un draft de la version 3 est sorti et est disponible ici.

Implémentation

Pour implémenter le CSP sur un site web, il suffit de rajouter des headers HTTP personnalisés sur les réponses faites par notre serveur. Ce type de mécanisme est intégré à la plupart des frameworks de développement web.

Afin de faciliter la mise en place et la maintenabilité des règles CSP, certaines librairies sont disponibles en fonction des frameworks. Par exemple :

• ASP.NET : NWebSec
• Node.JS : Helmet (pour Express et Koa)

Le serveur web peut également être configuré pour ajouter automatiquement ce header HTTP à toutes les requêtes sortantes.

Liens utiles

• Documentation : http://content-security-policy.com/
• Générateur : https://report-uri.io/home/generate
• CheatSheet : https://scotthelme.co.uk/csp-cheat-sheet/
• Article sur le blog de GitHub : http://githubengineering.com/githubs-csp-journey/
• Articles sur le blog de DropBox :
  • https://blogs.dropbox.com/tech/2015/09/on-csp-reporting-and-filtering/ 
  • https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/ 
  • https://blogs.dropbox.com/tech/2015/09/csp-the-unexpected-eval/ 
  • https://blogs.dropbox.com/tech/2015/09/csp-third-party-integrations-and-privilege-separation/

Cet article [Cybersécurité] Se protéger des failles XSS avec les headers CSP (Content Security Policy) est apparu en premier sur Blog de Aymeric Lagier.

Pour réaliser cette étape, le mapping du champ contenant ces caractères doit spécifier le filtre « asciifolding » fourni nativement par le moteur Elasticsearch.

Exemple de création d’index avec déclaration de notre analyzer avec asciifolding :

PUT /my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_analyzer": {
          "tokenizer": "standard",
          "filter":  [ "standard", "asciifolding" ]
        }
      }
    }
  }
}

On créé ensuite le type en indiquant que notre champ utilisera notre nouvel analyzer :

PUT /my_index/_mapping/fruit
{
  "properties": {
    "name": {
      "type": "string",
      "fields": {
        "asciifolding": {
          "type": "string",
          "analyzer": "my_analyzer"
        }
      }
    }
  }
}

Enfin, on ajoute un document contenant une valeur accentuée dans le champ « name » :

POST my_index/fruit 
{
  "name": "pêche"
}

Les exemples de recherche suivants illustrent l’utilité de notre analyzer.

GET my_index/fruit/_search
{
  "query": {
    "match": {
      "name": "peche"
    }
  }
}

{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 0,
      "max_score": null,
      "hits": []
   }
}

GET my_index/fruit/_search
{
  "query": {
    "match": {
      "name.asciifolding": "peche"
    }
  }
}

{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 5,
      "successful": 5,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 1,
      "hits": [
         {
            "_index": "my_index",
            "_type": "fruit",
            "_id": "AVR4VgBfRZI8D8Bc982h",
            "_score": 1,
            "_source": {
               "name": "pêche"
            }
         }
      ]
   }
}

A noter que si on est en présence de mots français, il est plus intéressant d’utiliser l’analyzer « french » fourni dans Elasticsearch qui procède aussi à cette étape d’asciifolding mais ajoute également le stemming, les stopwords, etc. (analyzers de langues).

Pour tester un analyzer (ou un tokenizer ou un filtre), il est possible d’appeler « _analyze » sur un index via une requête HTTP GET.

Par exemple :

http://localhost:9200/my_index/_analyze?analyzer=my_analyzer&text=pêche

va renvoyer

{
  "tokens": [
    {
      "token": "peche",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Alors que

http://localhost:9200/my_index/_analyze?analyzer=standard&text=pêche

va renvoyer

{
  "tokens": [
    {
      "token": "pêche",
      "start_offset": 0,
      "end_offset": 5,
      "type": "<ALPHANUM>",
      "position": 1
    }
  ]
}

Attention, n’exécutez pas la requête « _analyze » dans Sense. L’encodage ne sera pas correct lors de la requête et la réponse sera fausse.

Requête :

GET /my_index/_analyze?analyzer=my_analyzer&text=pêche

Réponse :
{
   "tokens": [
      {
         "token": "p",
         "start_offset": 0,
         "end_offset": 1,
         "type": "<ALPHANUM>",
         "position": 1
      },
      {
         "token": "che",
         "start_offset": 2,
         "end_offset": 5,
         "type": "<ALPHANUM>",
         "position": 2
      }
   ]

Cet article ASCII Folding dans Elasticsearch et appel de _analyze est apparu en premier sur Blog de Aymeric Lagier.