Cédric BRASSEUR

Et vous ?

• Nom, prénom
• Etudes réalisées et niveau sur la sécurité logicielle

Plan du cours

• Introduction à la sécurité au sein d'un SI
• La sécurité au sein des cycles de vie
• Rappels de notions sur la sécurité dans le web
• Sécurité du code : Les différents types d'analyses sécurités
• Sécurité des API & Frameworks
• Sécurité des Bases de données

Summary

Objectifs du jour

• Acquérir les concepts de la sécurité dans les cycles projets et mettre en œuvre la sécurité dans les différentes phases d’un projet
• Appréhender la sécurité des API et des bases de données

Il est important de différencier ces deux aspects de la sécurité informatique

• Intégrité des données
• Confidentialité des données
  personnelles
• Authentification pour effectuer les actions qui me concernent
• Disponibilité immédiate
• Sauvegarde des données et altérations

Accompagne dans les choix stratégiques de l'entreprise et en est responsable

Gestion de l'infrastructure physique et logique de l'entreprise et en est responsable également

Responsable de la sécurité, de l'intégrité et de la disponibilité des données

Réalise le PSSI qui sera validé par le DSI

Responsable de la formation de ses équipes au développement sécurisé

Dev(Sec)Ops

Le cycle de vie de la sécurité d'une application

1. Versionning
2. Build
3. Intégration
4. Tests
5. Déploiement
6. Configuration
7. Monitoring

Et vôtre rôle à vous ?

Normes et législations

Bibliothèques, projet et recommandations

• MITRE CWE 
• BSIMM
• OpenSAMM
• SDL Microsoft
• OWASP CLASP
• ANSSI + CLUSIF

Intégration au cycle de développement

Dans un cycle en V, la sécurité vient s'intégrer généralement entre la phase de coding et celle de tests.

Aujourd'hui, les méthodes agiles sont de plus en plus utilisées… Dans ce contexte, on rajoute dans le cycle une phase de sécurisation composée de plusieurs sprints.

S-SDLC

Secure-Software Development Life Cycle

Le S-SDLC concerne à la fois les manageurs et les développeurs dans une entreprise. Ce procédé n'est pas encore très répandu dans les entreprises, bien qu'il soit très efficace. Nous allons voir les différentes étapes de mise en place d'un S-SDLC.

les développeurs

S-SDLC

Seconde étape

Exigences : phase importante où l'on défini les besoins en sécurité de l'organisation ainsi que l'élaboration du plan d'action et l'analyse de coût de la mise en place d'un S-SDLC

S-SDLC

Troisième étape

Conception : cartographie de l'architecture autour de l'application pour en modéliser les menaces. On va anticiper pour réduire les menaces potentielles.

Mieux vaut prévenir que guérir ! "

Secure by design

Réduire les surfaces d'attaques : L'objectif de cette étape est de diminuer au maximum les possibilités afin de n'autoriser que ce qui est nécessaire au bon fonctionnement de l'application.

Plus on réduit les surfaces d'attaques, plus il est simple de maîtriser les éléments constituants notre système. Par exemple, refuser l'accès à tous les ports excepté une whitelist nécessaire à l'application.

Inclus également : La défense en profondeur (données, application, hôte, réseau, physique, politique de sécurité), la séparation des privilèges, la paramètres par défauts (mots de passes, etc...) 

Modélisation des menaces

La modélisation des menaces est également une étape importante pour s'assurer de la sécurité de son projet.

Diagrammes

Identification

Atténuation

Validation

Documentation et validation entre les parties prenantes

Utilisation du modèle STRIDE

Déterminer les points d'entrées et les interactions

Interventions sur les éléments identifier en phase précédente

S-SDLC

Quatrième étape

Code : Déterminer les règles de développement à suivre et penser à effectuer une analyse de code statique !
Ces règles devront être respectées par toutes les parties prenantes de votre projet.

S-SDLC

Cinquième étape

Test : S'assure de la sécurité de manière dynamique avec l'utilisation de scans de vulnérabilités (dynamique), tests de fuzzing, ou tests de pénétrations.

S-SDLC

Sixième et dernière étape

Permet l'analyse des écarts entre les principes définis lors de l'étape 2 et la réalité du code applicatif de notre application.
On réalise également un plan de réponse aux incidents (écarts), puis on réalise une revue finale de sécurité.

Architecture d'une application web (rappel)

Les requêtes http

HTTP Request

Demande du client à effectuer une action via le protocole HTTP 

HTTP Response

Réponse formatée par le serveur pour retourner l'information voulue au client via HTTP

La sécurité des navigateurs et serveurs web

SOP (Same Origin Policy)

CORS (Cross Origin
Resource Sharing)

Autorisé:

Non Autorisé :

Origine : 

http://www.exemple.com/test/index.html

http://www.exemple.com/test/toto/page.html

http://www.exemple.com/test/autrePage.html

http://exemple.com/test/page2.html

https://www.exemple.com/...

http://www.exemple.com:8081/...

Permet de définir quelques options supplémentaires souvent nécessaires !

Telles que

• host,
• origin,
• allow-origin,
• allow-methods (pour les types de méthodes GET, POST, PUT, DELETE,...)

HSTS

CSP

HTTPOnlyCookie & Authentification HTTP

HTTPOnlyCookie

Permet d'éviter toute récupération du cookie via autre chose qu'une requête HTTP. On empêche donc un script javascript contenant document.cookie d'être exécuté par exemple.

Authentification HTTP

Permet de sécuriser un peu plus une connexion utilisateur via un protocole HTTP en rajoutant du hashage par exemple. Mais ça n'empêche pas qu'il est contournable par un brute force.
Donc mon conseil c'est simplement de forcer HTTPS.

Pare-feu WAF

Module d'une application web, serveur ou machine virtuelle, un WAF permet de protéger contre les attaques HTTP malveillantes.

Challenge "hacking"

Hacking de session simple

Rendez-vous sur                                                                              https://www.hackthissite.org/missions/basic/

Vous allez être contraint de créer un compte… 

Votre but est d'aller le plus loin possible dans les 11 challenges basics disponibles.

Pour ceux qui finissent vite, n'hésitez pas à fouiner sur les autres challenges du site.
 

Challenge "hacking"

Hacking using JavaScript

Rendez-vous sur                                                                              https://www.hackthissite.org/missions/javascript/

Votre but est d'aller le plus loin possible dans  les 7 challenges JavaScripts disponibles.

Pour ceux qui finissent vite, n'hésitez pas à fouiner sur les autres challenges du site.
 

Les analyses automatisées

SAST

Static Application Security Testing : Analyse statique du code

DAST

Dynamic Application Security Testing : Analyse dynamique de l'application

IAST

Interactive Application Security Testing : Analyse interactive de l'application, ici on va également tester de manière interactive les frameworks et dépendances utilisées en continue sur notre application

L'analyse statique

S'effectue via :

• Scripts
• Analyse à la frappe dans l'IDE
• Scans ponctuels,
• ...

Remonte les vulnérabilités :

• Top 10 OWASP
• Certaines normes PCI-DSS
• Inclus la qualité de votre code (pour la qualité SonarQube est meilleur)

Permet de :

• Détecter au plus tôt les vulnérabilités
• Propose des corrections ciblées
• Associe une criticité à chaque vulnérabilité
• Aide à la découverte des nœuds communs aux failles pour déterminer efficacement le "Best Fix Location"

Explications

Analyse statique

Comment ça marche ?

Transforme le code de votre application en arbre syntaxique pour en définir les interactions et y déceler de potentielles vulnérabilités.
Un arbre syntaxique se représente sous forme de nœuds liés les un aux autres. Permet par exemple de vérifier que les entrées utilisateurs sont bien purgées par une méthode d'assainissement.

Attention :

• De nombreux faux positifs sont à prévoir avec l'analyse statique
• Il faut parfois développer ou surcharger les règles de base pour s'adapter aux normes de votre entreprise 

Analyse statique

Exemples d'analyseurs

• sonarqube
• checkmarx
• appscan
• bandit (Bandit)
• eslint (ESLint (JavaScript and React))
• flawfinder (Flawfinder)
• kubesec (Kubesec)
• nodejs-scan (NodeJsScan)
• phpcs-security-audit (PHP CS security-audit)
• pmd-apex (PMD (Apex only))
• security-code-scan (Security Code Scan (.NET))
• semgrep,...

Analyse dynamique

En quoi c'est différent de l'analyse statique ?

Contrairement à l'analyse statique qui ne va analyser que les sources, l'analyse dynamique va tenter de profiter de failles plus poussées et liées également à la configuration de votre infrastructure sécurisée (tests de pénétration automatisés). Sera plus enclin à détecter des failles de types Cross-Site Scripting & les problèmes de gestion autour de l'authentification.

Attention :

• Plutôt complexe à mettre en place (même si depuis peu DAST peu être intégré à une CI)
• Attention à ne pas laisser trainer les résultats de ce genre de tests (ceux de l'analyse statique non plus)

Tests de pénétration

C'est là où on fait appel à des experts pour tester notre application de bout en bout !

Plusieurs types :

• White-box : Avec un accès total, pour identifier des vulnérabilités
• Black-box : Le mode criminel qui s'infiltre
• Grey-box : Le pentester a l'adresse IP du serveur et un compte utilisateur (= Man in the middle)
• Red-team : Deux équipes dans votre entreprise se challengent, l'une en temps que hacker, l'autre en tant que protecteur de l'application

(Manuel)

Revue de code

Pratique très courante et à réaliser en continue, la sécurité n'échappe pas au besoin de réaliser des revues de code.

Plusieurs types :

• Inter équipe : Un responsable de revue de code est défini pour le projet afin de pouvoir vérifier en continue ce qui est livré.
• Externe : Faire intervenir un externe pour réaliser des revues de code poussées
• Soi-même, sur son propre code : C'est souvent le plus oublié, mais c'est la première revue de code à réaliser !

Systématique

Installation & exercice SonarQube

- Téléchargez https://www.sonarqube.org/downloads/

- Suivez la documentation https://docs.sonarqube.org/latest/setup/get-started-2-minutes/

- Analysez cette application, utilisez git clone ou récupérez le zip sur https://github.com/EditionsENI/securiteWEB

- Analysez les résultats dans SonarQube et tentez de comprendre où sont les vulnérabilités et rendez-vous dans le code de DVWA et / ou bWAPP pour trouver des solutions.

Sécuriser sa base de données

• Contrôler les accès à votre base au maximum et limiter l’accès aux données confidentielles
   
• Identifier les données sensibles et critiques
   
• Chiffrer les données en base
   
• Prendre le soin de ne pas donner de copie de la base de données de production
   
• Suivre l'activité sur votre base de données en continue

BDD

Contrôler l'accès

Vos systèmes de gestion de bases de données doivent idéalement gérer les droits et utilisateurs directement dans leurs propres systèmes. Ceci vous permettra de bien vérifier qui accède à quoi et surtout contrôler les accès de chaque utilisateur (ou pour chaque rôle).

Identifier les données sensibles

Identification des données sensibles : 

• Mots de passes : Hacher et saler
• Données d'environnement (clé d'api, versions...)
• Données de config
• Données personnelles
• Données de cartes bancaires
• Informations médicales (secret médical)
• Point de vue religieux, idéologique,
• ...

Chiffrer les données sensibles

C'est s'assurer de rendre une information confidentielle en la chiffrant, tout en s'assurant que seule la source de destination sera capable de décrypter le contenu sécurisé.

On va donc rendre une donnée illisible le temps du transport (quelque soit le protocole) et seul le destinataire possède la clé de décryptage pour rendre lisible la donnée envoyée.

Quelques algorithmes de chiffrage

Il existe différents types d'algorithmes de chiffrages, nous allons en lister quelques un et réaliser un exemple d'algorithme de César.

Les différents algorithmes

• DES,
• Triple DES,
• Algorithme de César,
• Vigenère,                                                                                
• Chiffrement symétrique / asymétrique,
• RSA/DSA,
• fonctions de hachages (MD5, SHA-0, SHA-1,...) 

Exercice simple (César)

Réalisez un script en php qui transforme une chaîne en une chaine chiffrée grâce à l'algorithme de César.

L'algorithme de César :

• Décalage de la lettre courante de 3 caractères vers la gauche dans l'alphabet ("BONSOIR" ==> "ERQVRLU")
• (optionnel) Découpage de la chaîne en tronçons de 5 caractères. Attention, cette étape rend le déchiffrage automatisé plus complexe pour une phrase !

                     Exemple : "BONSOIR" ==> "ERQVR LU"

& Réalisez le script de décryptage d'une chaine chiffré par l'algo de César (Exemple : "ERQVRLU" => "BONSOIR")

Production

Cet environnement doit être sécurisé en permanence et aucune copie ne devrait être réalisée

Pré-production

Attention aux données de production

Cet environnement doit avoir des données cohérentes par rapport à celles de production, mais ne doit pas en être une copie (Exemple carte de crédit). Et dans l'idéal rester sécurisé.

Développement

Environnement avec aucune sécurité !
Ne surtout pas utiliser de copie de la base de production sur cet environnement non sécurisé

Tracker en continu

Plusieurs outils permettent de surveiller en continue tout ce qu'il se passe sur votre base de données.
 

Ceci devrait être systématique pour chacun de vos projets ayant un besoin en sécurité élevé. 

L'objectif est de :

• Contrôler qui accède
• Connaître toutes les requêtes effectuées et par qui !
• Être alerté en cas de tentatives d'accès à une ressource non accessible
• (Hors sécurité) Permet aussi l'optimisation de votre base de données car vous pourrez aisément connaître les requêtes les plus réalisées et donc les optimiser.

APIs

• Les APIs sont de plus en plus utilisées depuis que l'on tend à utiliser des systèmes décentralisés
• Une API doit être sécurisée, testée et intégrée en continue
• Une API peut utiliser un Framework (dans l'idéal, sécurisé)
• Une API doit toujours être disponible
• Les données transitant par une API doivent être contrôlées

Frameworks

• L'utilisation d'un Framework a de nombreux avantages en matière de sécurité :
  • Faciliter la gestion des droits et rôles,
  • Logger à votre place, 
  • Sécuriser le nombre d'appels
  • Sécuriser les données sensibles,...
• Mais il faut s'assurer d'utiliser un Framework sécurisé et maintenu ! Sinon, vous n'avez pas la main pour corriger une éventuelle faille.

La sécurité des APIs

Gestion des sessions

Pour réaliser des opérations sécurisées sur vos APIs, il vous faut pouvoir authentifier et maintenir les sessions de vos utilisateurs. Le maintient de la session est à considérer comme temporaire.

On recharge la session régulièrement et surtout on recharge la session avant une opération critique !
(même si l'idéal est d'éviter qu'un utilisateur lambda puisse réaliser une opération critique sur votre API)

Identifier les données sensibles

• Cloisonnement des environnements : Et sécurisation des variables de configuration
   
• Sécurisation des clés d'APIs "Secrets" : Utilisation de clé différentes pour l'environnement de test et sécurisation maximale de celle de l'environnement de production. (Exemple Stripe !)
   
• Données sensibles : CB, mots de passes,...
   
• Hachage efficace : Utiliser le hachage pour sécuriser vos données

RGPD

Gestion des erreurs

• Gestion cohérente des erreurs dans votre API (code retour, message, type d'erreur,...)
   
• Journalisation des erreurs (logs)
   
• Intercepter les erreurs et les traiter
   
• Alerter en continue (lors du déploiement continue)

Gestion de la mémoire

• Gestion de la mémoire souvent oubliée dans la sécurité
   
• Souvent géré directement par le Framework (Garbage collector)
   
• Très impactant dans d'anciens langages tels que le C ou le Cobol
   
• Superviser la consommation mémoire en continue

Vérification des entrées / sorties

Vérifier les entrées utilisateurs !

N'importe qui peut modifier le payload, c'est à vous de vous assurer de la cohérence des données qui vont pouvoir atteindre votre base.

Vérifier la présence d'une authentification

En étant en invité, l'utilisateur ne devrait uniquement que pouvoir créer un compte et lire les données accessibles aux visiteurs.

Encoder les données avant retour

Des données encodées sont des données qui, si elles peuvent être intercéptées, ne pourront pas être lues sans l'opération de décryptage.

Contrôler l'accès

Vos APIs doivent gérer les droits et utilisateurs également. Ceci vous permettra de bien vérifier qui accède à quoi et surtout contrôler les accès de chaque utilisateur (ou pour chaque rôle).
Le nombre d'appels maximum à votre API est également à contrôler.

OpenSAMM

Chaque sous domaine est divisé en 4 niveaux de maturité pour associer une "note" à votre application : 

• 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é

TOP 10 OWASP

Exercices supplémentaires

Rendez-vous sur

   https://www.root-me.org/fr/Documentation/Web/

Parcourez les cours, certains sont déjà vus mais les exemples de codes sont très complets sur ces documents.

Ensuite, rendez-vous sur la partie challenge Web-Client du site https://www.root-me.org/fr/Challenges/Web-Client/?tri_co=id_mot

Faites en le plus possible, pensez à trier par difficulté !
Vous pouvez aussi tenter les Web-Serveur Challenges.

Partie théorique

Envoyer fichier security_theory.docx

(sans confondre…)

Partie pratique

Déjà, dézippez les sources et mettez les dans le dossier wamp/www (ou équivalent).

Pour chaque exercice du zip envoyé votre objectif est de :

• Trouver quelle est la faille et où elle se trouve dans l'exercice. Veuillez mettre un commentaire avec la faille en question juste au dessus de la ligne ou l'élément de faille. (Si possible mettez dans un commentaire l'instruction qui provoque la faille (ou le contenu de l'entrée utilisateur))
• Corrigez cette faille en développant le correctif. Vous pouvez vous aider de ce que l'on a vu ensemble ! Normalement, ce sont des exemples de bases, vous devriez vous en sortir.

(après c'est fini)