diff --git a/TPSecurite/README.md b/TPSecurite/README.md
new file mode 100755
index 0000000..b52c7cc
--- /dev/null
+++ b/TPSecurite/README.md
@@ -0,0 +1,143 @@
+
+# Introduction à la sécurité des applis web en PHP.
+
+
+Le tp utilise une application de mini-blog. Le code PHP est
+volontairement simplifié et suffisamment laxiste pour illustrer les
+failles de sécurité abordées en cours.
+
+Le site est à télécharger et déployer sur votre site local.
+Il utilise un base de données sql. Vous pouvez directement
+l'importer (répertoire `extra`). Les paramètres (à modifier) pour l'accès à la base
+de données sont dans `lib/common.php`.
+
+Avant de démarrer, consultez les pages existantes, créez un compte et
+authentifiez-vous.
+
+#### Formulaires et html
+
+##### Modification de contenu
+
+1. Postez un commentaire sur un article.
+2. Modifiez votre commentaire. Modifiez le commentaire d'un autre
+ utilisateur.
+ Aide
+ Regardez l'url !
+
+
+3. Sécurisez l'écriture du formulaire `comment_create.php` afin qu'on
+ ne puisse pas accéder à un commentaire d'un autre utilisateur.
+ Aide
+ Dans la requête de modification d'un commentaire, ajoutez à la
+ clause WHERE la vérification du user.
+
+
+4. Le client peut-il modifier le formulaire, en changeant par exemple
+ l'id du commentaire à modifier ? comment ?
+ Aide
+ Il suffit d'écrire son propre formulaire, avec la possibilité de
+ saisir le champ id du commentaire !
+
+
+5. Pour se prémunir contre cela, on va, dans le formulaire, rajouter un
+ code d'authentification (hash avec une clé secrète) du champ
+ `id_comment` pour être sur que les données proviennent du formulaire
+ de l'application. Utilisez la fonction
+ [hash_mac](http://php.net/manual/fr/function.hash-hmac.php). Rajoutez,
+ dans le formulaire, un hash que vous pourrez comparé au hash re-calculé après l'envoie des données.
+ Aide
+
+ générez un hash avec une clé secrète :
+ $hashCode = hash_hmac("sha256",$_REQUEST['id_comment'],"Ma clé");
+ echo '';
+ Au moment du traitement du formulaire, quand on reçoit le champ `id_comment`, on recalcule et compare le hash avec celui reçu.
+
+
+
+##### XSS
+
+1. Ajoutez un commentaire qui masque tout ce qui suit son affichage
+ (uniquement de l'html svp !). Revenez à un fonctionnement normal.
+
+ Aide
+ Pensez à fermer des balises, et à en ouvrir une qui cachera tout le
+ reste au moyen d'une propriété css.
+
+
+2. Ajoutez un commentaire qui modifie le titre `h1` de la page de
+ l'article.
+
+ Aide
+
+ Le javascript permet de modifier le contenu HTML d'un élément :
+ document.querySelector("h1").innerHTML = "hey !!!!";
+
+
+3. Empêchez la saisie de balises HTML (les supprimer) pour éviter les
+ attaques ci-dessus. Est-ce suffisant ?
+
+4. Echappez (protéger) les textes affichés dans le html
+ (htmlspecialchars).
+
+5. Créez un compte en donnant une url de façon à exploiter une faille
+ XSS sur la page `article_view.php`.
+ Aide
+
+ javascript:alert(/XSS !/);
+
+
+6. Proposez une url vers la page `user_login.php` qui affiche dans un
+ popup les login/mots de passe saisies dans le formulaire (cela
+ pourrait être plus dangereux, en les envoyant sur un serveur par
+ exemple ...)
+ Aide
+ La valeur de la variable login est écrite dans le formulaire, dans
+ l'attribut value du champ texte correspondant.
+ Il donc tout à fait possible d'injecter du code javascript via un
+ attribut html, par exemple onchange ...
+
+
+
+##### CSRF
+
+Les vunérabilités de type CSRF (Cross-Site Request Forgery) consiste à
+forger de fausses requêtes à partir d'url authentifiées et à pousser le
+client à exécuter des actions sans le savoir.
+
+Le client authentifié exécute à son insu une requête (suppression par
+exemple) par un formulaire dissimuler ou une balise image contrôlée par
+du javascript.
+
+1. Se rendre sur la page `csrf.html` (soyez authentifié). Que s'est-il
+ passé ?
+2. Passer les données en POST résoudra le problème précédent.
+ Malheureusement, on pourra quand même créer une attaque avec du
+ javascript. (vous verrez l'année prochaine qu'on peut faire une
+ requête http à partir de javasscript.
+3. Résoudre le problème en utilisant un token unique dans le
+ formulaire.
+
+#### Injection SQL {#injection-sql .alert}
+
+1. Sur la page `user_login.php`, connectez-vous sans mot de passe,
+ juste avec un login valide.
+2. connectez-vous sans mot de passe ni login.
+3. "Sécurisez" avec la méthode `quote` de PDO.
+4. Sur la page `comment_create.php`, malgré l'échappement SQL,
+ prouvez que l'on peut toujours modifier les commentaires d'autrui.
+
+ Aide
+ Regerdez la clause WHERE dans la requête d'update d'un
+ commentaire.
+
+
+5. Utilisez le [filtrage](http://fr.php.net/manual/fr/book.filter.php)
+ en entrée des données.
+6. Sécurisez la page `comment_create.php` avec des requêtes
+ préparées.
+
+#### Sessions
+
+1. Utilisez une faille XSS pour afficher le contenu du cookie. Volez
+ alors la session associée. (Il suffit d'écrire depuis un autre
+ navigateur la valeur du cookie récupéré)
diff --git a/TPSecurite/article_list.php b/TPSecurite/article_list.php
new file mode 100755
index 0000000..8b9d9a9
--- /dev/null
+++ b/TPSecurite/article_list.php
@@ -0,0 +1,40 @@
+
+
+
+
+