X-Git-Url: http://git.nguyen.vg/gitweb/?a=blobdiff_plain;f=prog_internet%2Fprog_internet_09.xhtml;fp=prog_internet%2Fprog_internet_09.xhtml;h=e1a3e3aa0761295a8a2c049f46e8bf9ad4cbec11;hb=7c6ab96a4f7cd3b1ce5ab9695ddbc608c74836a2;hp=0000000000000000000000000000000000000000;hpb=11d5eeffd586cf2be5ed4e09b171be97c2f4a87b;p=hacks%2FsimpleWebSlides.git diff --git a/prog_internet/prog_internet_09.xhtml b/prog_internet/prog_internet_09.xhtml new file mode 100644 index 0000000..e1a3e3a --- /dev/null +++ b/prog_internet/prog_internet_09.xhtml @@ -0,0 +1,500 @@ + + + +
+⇒ Ãa ne va pas faire de vous des hackers, + juste vous sensibiliser aux problèmes de sécurité⦠+
+Alice et Bob veulent échanger des données + confidentielles.
+
+ Non sûr (Alice et Bob doivent se mettre d'accord sur une clé en
+ « clair », par email par exemple) ou non pratique
+ (ils doivent se rencontrer physiquement pour échanger la
+ clé).
+ Efficace: on peut implanter plusieurs algorithmes
+ de chiffrements en utilisant uniquement des opérations
+ logiques de bases
+ (AND, OR, XOR). Il est facile de
+ les implanter sur des puces dédiées (cartes de crédit,
+ processeurs mobiles). Ils sont « sûrs » tant que la clé
+ reste secrète.
+
Alice et Bob veulent échanger des données + confidentielles.
+
+ Sûr et pratique (Bob a généré une paire de clé, et a
+ déposé la clé publique sur une page Web)
+ Peu efficace: repose sur des problèmes
+ mathématiques difficiles (factorisation de grands entiers,
+ courbes eliptiques sur les corps finis). Chiffrer et
+ déchiffrer un message n'est pas réaliste pour des grands
+ messages (vidéo en streaming, requêtes Web, â¦).
+
On combine les deux méthodes. (Alice envoie un message à Bob)
+⇒ Ceci est à la base de protocoles tels que HTTPS
+Le chiffrement assymétrique permet aussi d'avoir la + preuve que quelqu'un est bien Bob!
+ ⇒ Comment garantir que la personne qui a généré
+ les clés au départ est bien Bob ?
+
HTTP est un protocole texte, les données ne sont + pas chiffrées (cf. TP3) et sans identification
+Alice représente le client, Bob le serveur et Eve (Eavesdropper) + l'attaquante
+On suppose que Eve est root sur la
+ machine. Il suffit de lire les paquets qui transitent par la
+ carte réseau (tcpdump sous Linux).
+
Ce problème touche tous les protocoles en clair: HTTP, POP, + IMAP, FTP, â¦. Il peut être résolu grace au chiffrement + de toute la connexion.
+Mallory se place entre Alice (cliente) et Bob (banque), par exemple au
+ moyen d'un e-mail frauduleux en HTML:
+
+ Bonjour,
+ veuillez vous connecter à votre banque en cliquant ici:
+ www.bob.com
+
+]]>
+ HTTP Secure
+Bob possède des clés publiques et privées + (KBpub + et KBpriv), Trent possède des clés + publiques et privées (KTpub + et KTpriv) +
+Bob et Trent se rencontrent. Trent signe + la clé publique de Bob en calculant +
Les tiers de confience sont des entités (états, associations, + compagnies privées) qui se chargent de vérifier les clés + publiques d'autres entitées. C'est une + vérification physique (documents administratifs, â¦). +
+Cette erreur s'affiche quand une signature n'est pas conforme + ou n'a pas pu être vérifiée
+Attaques contre les authorités de certifications
+ (tiers de confience): difficiles, mais pas impossible. Certains
+ tiers de confience sont douteux (états voyous, compagnie
+ piratées dont les clées privées sont compromises,â¦)
+ Attaques d'implémentation (plus probables) : on
+ exploite un bug dans le code des serveurs web ou des
+ navigateurs
+ Autres faiblesses: HTTPS est en « haut » dans la pile
+ IP (application). On peut donc avoir connaissance du nombre de
+ paquet échangés, des adresses IP des participants, la taille
+ et la fréquence des paquets⦠(même si on n'en connait pas le
+ contenu). Cela permet certaines attaques statisties ou de deni
+ de service.
+
Normalement, un cookie ne peut être + lu que que par le site émetteur (cf. cours 8). But:
+ <script src="http://marchand.com/pub.js"/>
+ Nouveau standard du W3C en préparation pour signifier à un + site qu'on ne souhaite pas être suivi (méthode « volontariste + » qui suppose que les sites commerciaux sont gentils et + respectent le protocole)
+On a vu que les sessions PHP (vrai aussi pour les autres + langages côté serveur) stockent dans un cookie un identifiant + unique. Que se passe-t-il si on vole ce cookie ? (démo) +
+Pas d'autre solution que de faire confiance
+ au root (solutions partielles basées sur le chiffrement
+ des disques dur)
+
Vulnérabilité: on exploite le fait qu'un site utilise
+ directement les entrées fournies par l'utilisateur.
+ Exemple: commentaires sur un blog.
+
+ Commentaire:
+ ]]><textarea rows="20" cols="60" name="zonetexte"/>
+
+]]>
+ echo "Commentaire #$i: <p>";
+ echo $_POST["zonetexte"];
+ echo "</p>";
+
+Debut du commentaire
+ <script type="text/javascript">
+ ... //code javascript malicieux
+ </script>
+ Fin du commentaire
+
+ Problème lié à l'utilisation de la fonction
+
+ command est une chaîne de caractères
+ considérée comme étant du code PHP et eval exécute
+ cette chaîne:
+ eval(command)
+ echo eval ("1 + 2 * 3"); // affiche 7
+ echo eval ('$x = 4;'); // définit la variable $x
+ echo $x; // affiche 4
+
+ Il ne faut jamais donner une chaine de caractère de
+ l'utilisateur comme argument à eval (sauf durant le
+ TP 9)
SQL: language de requête permettant d'interroger des bases de + données. Utilisation classique depuis PHP (on suppose un + formulaire qui met dans le champ "nom" le nom d'un + étudiant): +
+
+ $Q = "SELECT * FROM STUDENTS WHERE ";
+ $Q = $Q . "(NAME = '" . $_POST["nom"] . "');";
+ mysql_query($Q);
+
+ Si l'utilisateur donne comme nom « Toto », la requête envoyée + à la base est:
+ SELECT * FROM STUDENTS WHERE (NAME = 'Toto');
+ Affiche toutes les lignes de la table STUDENTS pour + lesquel le nom est Toto
+©xkcd
+
+
SELECT * FROM STUDENTS WHERE (NAME ='Robert');
+ DROP TABLE STUDENTS; --');'
+
+
+