← NSI — terminale spe

NSI · terminale spe

Chapitre 7 — Sécurité informatique

L'essentiel en 30 secondes

La sécurité repose sur trois piliers : confidentialité, intégrité, disponibilité. Le chiffrement symétrique (AES) utilise une seule clé partagée. Le chiffrement asymétrique (RSA) utilise une paire clé publique / clé privée. HTTPS = HTTP + TLS : le navigateur vérifie le certificat du serveur, puis établit un canal chiffré. L'injection SQL exploite les entrées non vérifiées pour exécuter du code SQL malveillant.

Notions clés

Chiffrement symétrique
Une seule clé pour chiffrer et déchiffrer. Rapide mais nécessite un échange sécurisé de la clé. Ex : AES.
Chiffrement asymétrique
Deux clés : publique (chiffrement) et privée (déchiffrement). Résout le problème de l'échange de clés. Ex : RSA.
HTTPS et TLS
HTTPS = HTTP chiffré par TLS. TLS combine asymétrique (échange de clé de session) puis symétrique (chiffrement des données).
Certificat numérique
Document signé par une autorité de certification (CA) qui garantit l'identité du serveur et sa clé publique.
Injection SQL
Attaque consistant à insérer du code SQL via un champ de saisie non filtré. Ex : ' OR 1=1 -- dans un formulaire de login.

Formules

Injection SQL — exemple d'attaque

‘−−Reque^tevulneˊrable:\nSELECT∗FROMusersWHERElogin=′"+saisie+"′ANDmdp=′"+mdp+"′\n−−Saisiemalveillante:′OR1=1−−\n−−Reˊsultat:SELECT∗FROMusersWHERElogin=′′OR1=1−−′ANDmdp=′′\n−−Le−−commentelafin:TOUSlesutilisateurssontretourneˊs.‘`-- Requête vulnérable :\nSELECT * FROM users WHERE login = '" + saisie + "' AND mdp = '" + mdp + "'\n-- Saisie malveillante : ' OR 1=1 --\n-- Résultat : SELECT * FROM users WHERE login = '' OR 1=1 --' AND mdp = ''\n-- Le -- commente la fin : TOUS les utilisateurs sont retournés.`

Condition : L'attaquant contourne l'authentification en injectant une condition toujours vraie

Protection contre l'injection SQL

`# BONNE PRATIQUE : requête paramétrée\ncurseur.execute(\n "SELECT * FROM users WHERE login = ? AND mdp = ?",\n (saisie_login, saisie_mdp)\n)`

Condition : Les requêtes paramétrées (ou préparées) empêchent l'interprétation du SQL injecté

Principe de TLS simplifié

‘1.Client→Serveur:demandedeconnexionseˊcuriseˊe\n2.Serveur→Client:certificat+cleˊpublique\n3.ClientveˊrifielecertificataupreˋsdelaCA\n4.Clientchiffreunecleˊdesessionaveclacleˊpubliqueduserveur\n5.Communicationchiffreˊeensymeˊtriqueaveclacleˊdesession‘`1. Client \to Serveur : demande de connexion sécurisée\n2. Serveur \to Client : certificat + clé publique\n3. Client vérifie le certificat auprès de la CA\n4. Client chiffre une clé de session avec la clé publique du serveur\n5. Communication chiffrée en symétrique avec la clé de session`

Condition : Asymétrique pour l'échange de clé, symétrique pour les données (plus rapide)

A retenir

  • HTTPS utilise les DEUX types de chiffrement : asymétrique pour échanger la clé de session, symétrique pour chiffrer les données.
  • La protection n°1 contre l'injection SQL : les requêtes paramétrées. Jamais de concaténation de chaînes avec des saisies utilisateur.
  • Un certificat numérique lie une clé publique à une identité, garantie par une autorité de certification.

Erreurs classiques

Erreur : Croire que HTTPS est 100% sécurisé

Correction : HTTPS chiffre le canal, mais ne protège pas contre le phishing, les failles côté serveur ou les malwares côté client.

Erreur : Penser que le chiffrement asymétrique est utilisé pour tout chiffrer

Correction : L'asymétrique est trop lent pour les données. Il sert uniquement à échanger la clé de session (symétrique).

Erreur : Construire des requêtes SQL par concaténation de chaînes

Correction : Toujours utiliser des requêtes paramétrées (? ou %s selon le driver). C'est la seule protection fiable.

Astuce méthode

Au bac, si on te donne un code SQL vulnérable, repère la concaténation de chaîne avec la saisie utilisateur, montre l'injection possible (ex : ' OR 1=1 --), puis propose la correction avec une requête paramétrée.