Qu’est-ce qui rend une application vulnérable aux injections SQL?
Les requêtes SQL construites dynamiquement avec des paramètres provenant directement de l’utilisateur (input non sanitisé), sans utiliser de requêtes paramétrées ou d’ORM.
Comment exploiter une injection SQL avec UNION?
1) S’assurer que la première requête retourne rien (ex: id=666),
2) Utiliser UNION pour ajouter une requête sur la table cible,
3) Matcher le nombre de colonnes, 4) Commenter la fin de la requête originale avec –
Exemple d’injection SQL pour extraire des passwords?
666 UNION SELECT id, password, 1, name FROM user WHERE id > 1;
Comment injecter plusieurs requêtes SQL (si executescript est utilisé)
Terminer la première requête avec ‘);, ajouter la nouvelle requête malveillante, puis commenter le reste avec –. Ex: somefaketask’,’False’,’someuser’); INSERT INTO user (…) VALUES (…)–
Quelles sont les 2 solutions principales contre les injections SQL?
1) Requêtes paramétrées - utiliser des placeholders (?) et passer les valeurs séparément,
2) ORM - utiliser un framework qui génère les requêtes (ex: SQLAlchemy) SANS écrire de SQL manuel
Pourquoi MD5 est-il dangereux pour les mots de passe?
1) Très rapide à calculer = facile à brute-force,
2) Pas de salt = même password = même hash (vulnérable aux rainbow tables),
3) Considéré cryptographiquement cassé
Quelle est la bonne pratique pour hasher les mots de passe?
Utiliser un algorithme de hashing sécuritaire et lent comme Bcrypt ou PBKDF2, TOUJOURS avec un salt unique par mot de passe.
Qu’est-ce qu’un salt et pourquoi est-il important?
Une valeur aléatoire unique ajoutée à chaque mot de passe avant le hashing. Empêche les rainbow tables et fait en sorte que deux users avec le même password auront des hash différents.
Quelle est la différence entre authentification et autorisation?
Authentification = vérifier l’identité (qui es-tu?),
Autorisation = vérifier les permissions (qu’as-tu le droit de faire?)
Pourquoi utiliser JWT plutôt que BasicAuth à chaque requête?
1) Évite d’envoyer username/password à chaque requête,
2) JWT peut contenir des infos (claims) sur l’user,
3) Peut être révoqué/expiré,
4) Plus sécuritaire si le token est volé (password pas exposé)
Où stocker un JWT côté client pour qu’il soit transmis automatiquement?
Dans un cookie HttpOnly (plus sécuritaire) ou dans localStorage (plus simple mais vulnérable au XSS). Le cookie HttpOnly est préférable.
Pourquoi ne JAMAIS faire sa propre implémentation JWT en production?
Très risqué - facile de faire des erreurs cryptographiques (algorithme faible, pas de validation de signature, mauvaise gestion des clés). Toujours utiliser une librairie éprouvée!
Pourquoi utiliser un ORM ne garantit PAS l’absence d’injections SQL?
Parce que même avec un ORM, on peut toujours écrire des requêtes SQL manuelles (raw queries) qui sont vulnérables. Il faut utiliser uniquement les méthodes de l’ORM sans SQL manuel.
Différence entre requêtes paramétrées et concaténation de strings SQL?
Paramétrées: cur.execute(“SELECT * FROM task WHERE id = ?”, [task_id]) - sécuritaire, le driver échappe les valeurs.
Concaténation: “SELECT * FROM task WHERE id = “ + task_id - vulnérable aux injections!
Qu’est-ce qu’un JWT et à quoi sert-il?
JWT (Json Web Token, prononcé “JOT”) est un token d’authentification émis au login pour éviter de répéter le processus de login à chaque requête. Il est transporté dans toutes les requêtes de l’application pour identifier l’utilisateur. Le JWT est encodé en base64 et composé de 3 parties séparées par des points.
Quelles sont les 3 parties d’un JWT?
Partie 1 (Header): Map JSON contenant les métadonnées (type de token, algorithme de chiffrement utilisé).
Partie 2 (Payload): Map JSON contenant les données du token (username, id, rôle, etc.).
Partie 3 (Signature): Signature cryptographique des deux premières parties pour empêcher le forgeage de tokens malveillants.
Comment fonctionne la signature JWT (3e partie)?
On combine les deux premières parties (header + payload), on signe avec l’algorithme indiqué dans le header, et on ajoute le résultat comme 3e partie. En mode symétrique, la clé secrète reste sur le serveur et sert à créer ET valider la signature. Sans cette clé, impossible de forger un token valide.
Quels sont les problèmes cryptographiques fondamentaux de JWT?
1) L’algorithme “None” est valide dans les specs et permettrait de forger des tokens (mais les librairies modernes rejettent cet algo).
2) En mode asymétrique, on peut spécifier où trouver la clé publique dans le header, donc un attaquant peut pointer vers sa propre clé.
3) Pas de certificat ni point d’ancrage pour valider les clés publiques. Pour ces raisons, on utilise JWT en mode symétrique seulement.
Pourquoi ne JAMAIS implémenter JWT soi-même en production?
Très risqué de faire des erreurs cryptographiques : algorithme faible, pas de validation de signature, mauvaise gestion des clés, vulnérabilités aux attaques par manipulation du header. TOUJOURS utiliser une librairie JWT éprouvée et bien maintenue.
Où peut-on stocker un JWT côté navigateur et quelle est la meilleure option?
Deux options : Local storage ou Cookie.
Les cookies sont la solution à privilégier, surtout avec les flags HttpOnly et Secure, car ils sont moins accessibles au JavaScript malveillant (protection contre XSS).
Le localStorage est plus simple mais complètement accessible au JavaScript.
Pourquoi utiliser un UUID au lieu d’un ID séquentiel dans le JWT?
Un ID séquentiel (1, 2, 3…) est prévisible, ce qui permet à un attaquant de deviner les IDs d’autres utilisateurs même sans forger le token. Un UUID est aléatoire et non-devinable, ajoutant une couche de sécurité supplémentaire.
Que se passe-t-il si quelqu’un vole un JWT?
L’attaquant peut usurper l’identité de la victime et accéder à son compte tant que le token est valide. Le JWT volé fonctionne exactement comme l’original puisque le serveur ne peut pas distinguer qui l’utilise. C’est pourquoi il faut protéger le JWT contre le vol (cookies HttpOnly, expiration courte, etc.).
Qu’est-ce qu’une attaque XSS (Cross-Site Scripting)?
XSS est l’injection d’un script JavaScript malicieux dans un site légitime. Le script est exécuté dans le navigateur de la victime lorsqu’elle visite la page compromise. Il existe 3 types : stored (sauvegardé en BD), reflected (dans l’URL), et blind (exécuté sans être visible).
Comment fonctionne une attaque XSS de type “stored”?
Le script malicieux est sauvegardé dans la base de données (par exemple via un champ de formulaire comme “Create Task”). Lorsqu’un utilisateur visite une page qui affiche ce contenu, son navigateur exécute le script. C’est le type le plus simple et le plus dangereux car il affecte tous les visiteurs.
