Le berger, la tête dans les nuages

J’ai fait plusieurs fois référence à SecurityShepherd dans ce blog.Bien que l’outil ne soit pas parfait car chaque attaque semble être codée “en dur”, je le trouve très intéressant pour organiser un CTF ou simplement animer une formation.
Mais pour cela il faut un serveur capable d’encaisser les essais plus ou moins offensifs des étudiants à la recherche de vulnérabilités avec leurs outils préférés tels que BurpSuite ou Zap. C’est pourquoi l’installation de ce serveur dans le “cloud” permet d’adapter les performances à vos besoins, et de ne payer que lorsque le serveur est utilisé.
Personnellement j’ai opté pour la formule “Pay On The Go” de Microsoft Azure, et je suis totalement satisfait.
Voici donc les étapes de cette installtion et la description du contournement des difficultés que j’ai pu rencontrer.

• Télécharger “Security Shepherd Manual Pack”

wget http://sourceforge.net/projects/owaspshepherd/files/SecurityShepherd%20v2.1%20Manual%20Pack.zip

• Installer Apache Tomcat 7

   1: sudo apt-get install tomcat7

   2: sudo apt-get install tomcat7-docs tomcat7-admin tomcat7-examples

• Installer MySql, en utilisant le mot de passe par défaut (contenu dans “readme.txt”) ou pas (c’est préférable)

 

   1: sudo apt-get install mysql-server 

• Extraire la contenu du package

 

   1: sudo apt-get install unzip

   2: unzip SecurityShepherd%20v2.1%20Manual%20Pack.zip

• Copier les fichiers “sql” que l’on vient d’extraire dans le répertoire “bin” de MySql

 

   1: sudo cp *.sql /usr/bin

• Ouvrir MySql en ligne de commande et exécuter les fichiers “SQL”

 

   1: mysql -u root

   2: source core.sql 

   3: source exposedSchema.sql 

• Aller dans le répertoire “webapps” de votre Tomcat et supprimer tous les répertoires déjà présents, puis déplacer les fichiers “WAR” dans le répertoire “webapps”

 

   1: cd /var/lib/tomcat7/webapps

   2: sudo rm -rf ROOT

   3: sudo cp /home/azureuser/securityshepherd/*.war .

• Démarrer Tomcat

 

   1: sudo service tomcat7 restart

Si vous regrettez de ne pas avoir donné un mot de passe spécifique pour MySql, il est encore possible de le changer de la manière suivante:

 

   1: mysqladmin -u root password VotreMotDePasse

Puis de modifier le mot de passe  MySql dans le fichier “site.properties”

 

   1: cd /var/lib/tomcat7/webapps/ROOT/WEB-INF

   2: vi site.properties

   3:    ...

   4:    databasePassword=VotreNouveauMotDePasse

Connectez-vous ensuite sur le portail de SecurityShepherd et authentifiez-vous avec “admin / password” (valeurs par défaut) pour changer votre mot de passe

http://votre_environnement.cloudapp.net/

Si comme moi vous n’arrivez pas à changer le mot de passe de vos utilisateurs dans l’interface web, voici une proposition de contournement temporaire qui vous permet d’associer à vos utilisateurs le mot de passe de l’utilisateur “admin”:

 

   1: mysql -u root

   2: show databases;

   3: use core;

   4: show tables;

   5: select * from users where userName="admin";

Vous pouvez alors récupérer la valeur du champ “userPass”, puis affecter cette valeur au champ “userPass” de votre utilisateur:

 

   1: update users set 

   2: userPass="302c.................................ab4a" 

   3: where userName="admin"

Source: OWASP Security Shepherd (https://www.owasp.org/index.php/OWASP_Security_Shepherd)

Punkspider, ça décoiffe…

En lisant le document de l'OWASP intitulé OWASP Testing Guide 4.0 (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents), dans la catégorie "Information Gathering" j'ai eu la surprise de découvrir PunkSpider.
Si vous installez le plug-in dans votre browser Firefox ou Chrome, PunkSpider vous permet de savoir en temps-réel si des vulnérabilités sont présentes.
Dans l’exemple ci-dessous on voit en haut à droite une croix rouge (dans le plug-in de Punkspider) qui indique la présence de vulnérabilités. C'est plutôt bien fait!

Par contre si vous utilisez PunkSpider pour tester vos propres sites et que ces sites sont vulnérables alors il y a une forte chance que ces sites se retrouvent dans la “Blacklist” de PunkSpider (cette liste, qui énumère tous les sites vulnérables est téléchargeable sur le site de Punkspider).

Et dans ce cas votre site devient visible pour tous les script-kiddies du monde! A bon entendeur!
Par contre, encore une fois, cet outil peut être utilisé avantageusement pour la sensibilisation à la sécurité des applications web!

Vous expliquez le XSS et hop vous montrez l’existence de failles en "live" sur des sites existants, comme sur le site ci-dessous !

Attention restez dans la légalité! Gaffe aux dérives!

Suivre le berger par sécurité (Security Shepherd 101)

Il y a quelques temps déjà l’OWASP nous proposait Security Shepherd, une application permettant de découvrir les vulnérabilités des applications web sous la forme amusante d’un CTF (Capture The Flag) ou bien sous la forme plus classique permettant un accès à toutes les vulnérabilités.

Depuis peu l’OWASP fournit également une machine virtuelle contenant Security Shepherd. Et ça c’est plutôt sympathique.

On peut ainsi très facilement publier sur internet le CTF pour jouer avec des amis ou bien proposer des exercices aux étudiants.

L’OWASP devrait également fournir prochainement la possibilité d’ajouter ces propres exercices.

Ce que l’on reproche généralement à ce type d’outil c’est la nécessité de trouver la vulnérabilité telle qu’elle a été pensée par les concepteurs. Et généralement le hacker en herbe n’a pas la possibilité de faire preuve d’imagination et de sortir du carcan du concepteur. C’est en particulier le cas de Webgoat (de l'OWASP également) qui reste malgré tout un très bon outil pédagogique (pour plus d’informations sur Webgoat vous pouvez jeter un œil à Un bug dans Webgoat 5.2? Non! Pas un mais deux…).

Au travers des premiers tests que j’ai pu réaliser avec Security Shepherd, il ne semble pas être aussi contraignant que Webgoat.

Dans ce qui suit nous allons décrire les étapes permettant de mettre en place un petit CTF entre amis.

Je ne m’attarde pas sur la mise en place de la VM, et la publication de Security Shepherd sur internet. C’est assez standard !

1^ère étape : Créer une classe

2^ème étape : Créer vos participants dans une classe

Vous pouvez ensuite visualiser ou changer la liste des participants à une classe donnée.

3^ème étape : Configurer le mode « Capture The Flag »

4^ème étape : Jouer

Après la connection, le participant doit impérativement changer son mot de passe pour pouvoir commencer les exercices.

Un premier exercice est proposé au participant qui peut choisir ses propres outils pour le résoudre.

Une fois l'exercice résolu, une clef est affichée. Cette clef doit ensuite être copiée dans la champ rservé à cet effet en haut de la page, puis soumise au serveur pour que le résultat de l'exercice soit finalement pris en compte.

5^ème étape : Visualiser les résultats en temps réel

L'administrateur peut suivre en direct les résultats du concours. on voit ici que c'est le participant "student1" qui vient de prendre la tête de la course!

Amusez-vous bien !

Note : comme vous pouvez le constater je ne vous donne pour l’instant aucune information sur comment résoudre les exercices pour vous permettre de prendre plus de plaisir dans la recherche des solutions ! Les solutions devraient faire l'objet d'un prochain article très certainement !

Damn Vulnerable Web App…

Au cours de mes ballades dans le web profond, ma route a croisé une vielle VM qui semblait avoir eu un certain succès en son temps! C’était bien avant l’arrivée de Backtrack, enfin je crois!

Cette vielle VM c’est celle de Web Security Dojo de chez Maven Security (http://www.mavensecurity.com/web_security_dojo/)! Et j’ai découvert quelques applications intéressantes que je ne connaissais pas comme par exemple Google’s Gruyere, Hacme Casino et Damn Vulnerable Web App.

A l’instar de Webgoat, ces applications permettent d’apprendre en trouvant et corrigeant les failles de sécurité parsemées çà et là au travers de ces applications web.

Nous allons nous intéresser plus particulièrement à Damn Vulnerable Web App (DVWA) au travers de l’injection SQL à l’aveugle proposée (Blind SQL Injection ou Blind SQLi).

Certains puristes disent qu’une “Blind SQL Injection” se base uniquement sur le temps de traitement de la requête qui indique une réponse positive (e.g. le traitement est plus long) ou négative. Mais certains parlent aussi de “Blind SQLi” lorsque l’affichage change en fonction des résultats. Avec DVWA nous sommes dans ce deuxième cas de figure.

La vidéo ci-dessous détaille la démarche que l’on peut suivre pour ce type d’injection:



C’est fini! Mais nous devrions retrouver les applications de Web Security Dojo dans de prochains articles!

Comprendre Esapi de l'OWASP, en s’amusant

Enfin je trouve le temps de vous présenter "Swingset interactive 1.0.1" de l'OWASP, et j’en suis ravi!
L'OWASP propose de APIs très bien faites permettant de gérer vos problèmes de  sécurité sans avoir à réinventer la roue (généralement on fait moins bien…). Pour faciliter l'adoption et la formation des développeurs, l'OWASP propose une interface interactive appelée "Esapi Swingset" permettant de comprendre et d'implémenter les fonctions de sécurité en se basant sur les APIs d'Esapi.
La marche à suivre pour mettre en œuvre ce serveur est la suivante:

1. Télécharger le “zip” sur le site de l'OWASP sur https://www.owasp.org/index.php/ESAPI_Swingset
2. Télécharger Eclipse sur http://www.eclipse.org/downloads/. Dans mon cas je dispose d'une version de Webgoat fonctionnant avec Eclipse et je vais donc réutiliser cette version pour y ajouter le projet Esapi (plus d’informations dans l’article Modifier le source de Webgoat, oui c’est possible!)
3. Lancer Eclipse via Webgoat
4. Configurer Esapi dans Eclipse. Pour cela il est nécessaire de suivre tranquillement la procédure décrite dans le fichier:
   ”.../Swingset_Interactive_1.0.1/README.txt”. Si vous avez des problèmes avec les directives de ce fichier, n'hésitez pas à me contacter.

On note le déplacement du ficher ".keystore" et du répertoire ".esapi" dans le répertoire de l'utilisateur avec lequel vous vous êtes connecté (par exemple "C:\Documents and Settings\votre_utilisateur"). Cela signifie que les fichiers générés au cours de vos tests et les fichiers de configuration se trouvent probablement à cet emplacement.
Comme décrit dans la documentation, le lancement du serveur Esapi se fait dans la vue "Serveurs" d’Eclipse. Faire un clic droit sur "Tomcat v6 Server at localhost" et choisir "Start".

Une fois que le status de ce serveur est dans l'état "Started", on peut commencer à jouer avec Esapi dans votre browser préféré (mais il est conseillé d'utiliser Firefox). Entrer l'URL suivante:
https://localhost:8443/SwingSet/main

Puisque l’objectif de cet article est de vous aider à prendre en main l'outil, nous allons le faire avec le premier exemple proposé qui est l'"Authentification".
On note que chaque thème est scindé en 3 parties:

• un tutoriel

• un “lab” vous permettant de réaliser votre propre implémentation en vous basant sur le tutoriel

• la solution

Après avoir lu le tutoriel on comprend qu'il est nécessaire de créer un utilisateur puis de s'authentifier avec ce même utilisateur en suivant les règles des APIs.
Dans le “lab” on apprend que le fichier "jsp" à modifier se trouve sous:
”\WebContent\WEB-INF\jsp\LoginLab.jsp”
On ouvre le fichier dans Eclipse et on découvre que les parties du code à modifier sont signalées par "//TODO 1" pour la création de l'utilisateur et "//TODO 2" pour la phase d'authentification avec ce même utilisateur.
En observant le code on note que les paramètres suivants sont utilisés:

• create_username
• create_password1
• create_password2

1ère phase: la création de l'utilisateur (TODO1)
Le code à modifier est le suivant (c’est un exemple fonctionnel mais perfectible):
User user = null;
Authenticator instance = ESAPI.authenticator();
   
try {
    if (request.getParameter("create_username")!=null){           
       // TODO 1: Use ESAPI to Create a User Account
       instance.createUser(request.getParameter("create_username"), request.getParameter("create_password1"), request.getParameter("create_password2"));
       instance.getUser(request.getParameter("create_username")).enable();
       instance.getUser(request.getParameter("create_username")).unlock();
Il faut noter qu'un utilisateur créé est par défaut désactivé et bloqué. Dans la vraie vie l'activation et le déblocage nécessiterait une intervention d'un administrateur par exemple.
Pour tester il est simplement nécessaire de sauvegarder le fichier "jsp" et de recharger la page dans le browser (Firefox dans notre cas).
Si votre utilisateur ”john” est créé vous obtenez le message "User Created : john". Vous pouvez ensuite consulter le fichier pour voir quelles sont les informations générées pour la création d'un utilisateur dans “C:\Documents and Settings\votre_utilisateur\.esapi\users.txt”
Notez en passant le chiffrement du mot de passe.

2ème phase: l'authentification avec ce même utilisateur (TODO2)
Le code à modifier est le suivant:
//user = ESAPI.authenticator().login();
//TODO 2: Login using ESAPI                    
user = ESAPI.authenticator().login(request, response);
Rien à dire. La solution est assez simple.

Optionnel: ajout du bouton "logout"
On peut en plus de l’exercice s’amuser à gérer le bouton “logout”.
On trouve le fichier "jsp" à modifier:
”\WebContent\WEB-INF\jsp\LogoutLab.jsp”
On y ajoute:
<%
Authenticator instance = ESAPI.authenticator();
instance.logout();
%>
User logout
Il est également nécessaire de modifier le fichier:
”\WebContent\WEB-INF\jsp\LoginLab.jsp”
On remplace la ligne:
<a href="main?function=Login&logout&lab">logout</a>par
<a href="main?function=Logout&lab">logout</a>

Puis après l'authentification, lorsque l'on clique sur le lien "logout",
l'utilisateur est déconnecté.
Enfin on peut corriger avec la version proposée par l'OWASP. Le code source se trouve sous:
”\WebContent\WEB-INF\jsp\LoginSolution.jsp”
Remarque: si vous sortez de votre session alors toutes vos données peuvent être perdues et vous devrez alors recommencer depuis la création de l'utilisateur (le fichier "users.txt" peut être est vide). Ce comportement semble aléatoire!
Amusez-vous bien! Et surtout utilisez Esapi dans vos implémentations!

Les failles Cross-Site Scripting: si communes et pourtant si méconnues !

Comme l’indique le site xss attacks information, les failles Cross-Site Scripting (aussi appelé XSS) sont toujours d’actualité bien qu’elles soient connues comme le "loup blanc" depuis de nombreuses années. Mais comme parfois avec ce qui nous est familier, nous en perdons le véritable signification et en oublions le risque. Je ne sais pas pour vous, mais pour moi c'est le cas!

A titre d’exemple, voici une capture d’écran du site de BP ayant subi une attaque XSS:

Nous allons dans ce qui suit décrire ce qu'est le XSS et les différentes formes qu'il peut prendre.

L'attaque "Stored XSS" ou “XSS permanent” dans laquelle le code injecté est stocké de manière définitive sur le serveur cible. Cette attaque peut être réalisé à deux conditons:

• quand les informations transmises par un utilisateur sont stockées côté serveur (par exemple dans une base de données ou des fichiers)
• quand ces informations stockées sont ensuite affichées de nouveau sans que les caractères spéciaux HTML aient été encodés.
  

C’est le cas d’un message écrit dans un forum qui peut être lu par des milliers de personnes.

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS permanent” sur le site Webgoat de l’OWASP:

L'attaque "Reflected XSS" ou “XSS non-permanent” dans laquelle le code injecté est transmis dans la requête et renvoyé par le serveur cible (i.e. utilisation d’un message d’erreur ou d’un outil de recherche).

Mais vous allez me dire que ce n’est pas un problème car l’utilisateur malicieux ne peut injecter du code que dans ses propres pages. Eh bien non! Prenons l’exemple d’un mail de phishing qui vous propose d’aller sur une page avec une URL qui contient le code XSS!

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS non-permanent” sur le site Webgoat de l’OWASP:

L'attaque "DOM Based XSS" ou “XSS local” dans laquelle le code injecté permet de modifier l’arbre DOM dans le browser de la victime permettant à la page web de se comporter différemment (i.e. phase d’authentification court-circuitée).

Comme précédemment un mail de phishing avec une URL prenant en compte la faille peut vous piéger.

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS local” sur le site Webgoat de l’OWASP:

Le XSS est également utilisé dans une attaque nommée Cross-Site Request Forgery ou CSRF. Un précédent article décrit précisément en quoi consiste cette faille et comment la mettre en oeuvre (voir l’article Cross Site Request Forgery par l'image!).

Source: toujours l’OWASP !http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Un bug dans Webgoat 5.2? Non! Pas un mais deux…

Eh bien oui, il faut le voir pour le croire mais il y a bien quelques bugs dans la version 5.2 de Webgoat. Webgoat ne fait pas exception à la règle! Dans les développements de sites web il y a des bugs qui parfois échappent à la validation et qui peuvent devenir des vulnérabilités exploitables par des personnes mal intentionnées. Mais heureusement nous ne sommes pas dans ce cadre, Webgoat est fait pour être faillible! Ouf! L’honneur est sauf!

L'objectif de cet article est simplement de vous montrer qu'il est possible de modifier le code de Webgoat. Vous avez toujours la possibilité de récupérer Webgoat 5.3 si vous le souhaitez.

On peut trouver tous les bugs de Webgoat à l’URL suivante: http://code.google.com/p/webgoat/issues/list

Mais puisque nous disposons du code source et d’Eclipse (voir “Modifier le code source de Webgoat, c’est possible!”), nous n’allons pas nous priver du plaisir de faire les corrections.

Bug 1 dans la leçon DOM injection de Ajax Security(référence 28)

Dans le code source de la page, on trouve:

<input name='key' value='' type='TEXT' onkeyup='validate();' >

Or plus loin on trouve:

var keyField = document.getElementById('key');

Il n’y a pas de paramètre “id” avec la valeur ‘key’ mais un paramètre “name”, il est donc nécessaire d’ajouter le paramètre “id” et de lui donner la valeur ‘key’

Dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java), on ajoute donc la ligne ci-dessous qui permet d’ajouter un tag “id” et de lui donner la valeur ‘key’:

Input input1 = new Input(Input.TEXT, KEY, "");
input1.addAttribute("onkeyup", "validate();");

// Fix
input1.setID(KEY);

tr.addElement(new TD(input1));
t1.addElement(tr);

Bug 2 dans la leçon DOM injection de Ajax Security(référence 32)

Dans le code source de la page on trouve:

var result = req.responseXML.getElementsByTagName('reward');

Mais la valeur req.responseXML est nulle lors de l’exécution avec Firebug

Par ailleurs on peut observer que la variable result n’est pas utilisée.

Pour résoudre notre problème on peut donc simplement commenter la ligne dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java)

Environnement de développement

Lorsque vous sauvegardez une modification dans Eclipse, le “build” est automatiquement lancé et le serveur est mis à jour (cf. Project/Build automatically).

Il ne reste alors qu’à recharger la page dans le browser et votre correction est immédiatement prise en compte.

Etonnant non!

Tags:

- Technorati Tags: Webgoat,OWASP

- del.icio.us Tags: Webgoat,OWASP

- BuzzNet Tags: Webgoat,OWASP

Modifier le source de Webgoat, oui c’est possible!

Si comme moi vous avez eu le besoin ou l’envie de modifier le code de Webgoat, soit pour y ajouter votre propre leçon, soit pour corriger un bug (eh oui il y en a parfois!), alors vous allez être ravi. Oui, l’OWASP permet aux utilisateurs de Webgoat de modifier le code source.

Tout d’abord un petit rappel sur les principales versions de Webgoat actuellement disponibles:

• Webgoat 5.3 est disponible en RC1 (première Release Candidate de cette nouvelle version) depuis le 10 novembre 2009


• Webgoat 5.2 est disponible en version finale depuis le 12 juillet 2008

Contrairement à la version 5.2, la récente version 5.3 ne propose pas encore une version incluant le code source. C’est pourquoi nous allons nous intéresser à Webgoat 5.2.

Dans cet article nous allons voir comment installer Webgoat 5.2 fournit avec le code source et l’éditeur Eclipse. Puis dans un prochain article, nous essaierons de corriger un petit bug de la version 5.2.

Installation de Webgoat 5.2 avec le code source

Sur http://sourceforge.net/projects/owasp/files/WebGoat/ choisir le répertoire Webgoat 5.2 et télécharger le fichier WebGoat-OWASP_Developer-5.2.zip

Extraire le fichier sous “C:”. Vous devez alors trouver dans “C:\WebGoat-5.2”, le fichier “Eclipse-Workspace.zip”

Extraire ce zip dans ce répertoire. Vous devez alors avoir le nouveau répertoire suivant: “C:\WebGoat-5.2\eclipse”

Lancer alors “C:\WebGoat-5.2\eclipse.bat”. Vous avez alors accès au projet Webgoat.

Sélectionner “Window/Open perspective/Java” ou “Window/Open perspective/Other/Java” et vérifier que les projets “Servers2” et “Webgoat” sont bien présents dans l’onglet “Project Explorer”. Vous pouvez faire un clique droit sur “Servers2” et sélectionner “Refresh” (idem pour le projet “Webgoat”).

Lancer Webgoat via Eclipse. Pour cela sélectionner “Window/Open perspective/Resource” ou “Window/Open perspective/Other/Resource” et dans l’onglet “Servers” séléctionner la ligne “Webgoat Tomcat v5.5 server at localhost”, faites un clique droit et sélectionner “Start”. L’état de ce serveur doit alors passer à “Started”

Enfin dans votre browser préféré, vous pouvez entrer l’URL: http://localhost/WebGoat/attack

Tags:

- Technorati Tags: Webgoat,OWASP

- del.icio.us Tags: Webgoat,OWASP

- BuzzNet Tags: Webgoat,OWASP

Membre de l'OWASP! Yes!

Faîtes comme votre serviteur, devenez membre (ou devrais-je dire adhérent) de l'OWASP.

Pour la modique somme de 50 dollars soit environ 35 euros (en fonction des fluctuations du cours), vous pouvez rejoindre la communauté OWASP de ceux qui se sentent concernés par la sécurité des applications web et qui veulent que les choses changent!

En retour vous ne serez pas en reste car vous recevrez, un magnifique T-Shirt pour les étés torrides...

une vraie carte de membre pour impressionner...

et un merveilleux diplôme à afficher au dessus de votre bureau.

Rejoignez le mouvement...!

Source: Open Web Application Security Project http://www.owasp.org/

Challenge Webgoat 5.2: la solution en vidéo

Vous connaissez tous Webgoat, le site web permettant de faire des tests de pénétration fournit par l'OWASP.

Et vous savez également tous que les solutions des exercices de pénétration proposés par Webgoat se trouvent à l'adresse suivante: http://yehg.net/lab/pr0js/training/webgoat.php

Et comme moi, il ne vous a pas échappé que certains exercices n'étaient pas corrigés. C'est en particulier le cas du challenge proposé par Webgoat 5.2.

C'est pourquoi je vous propose de vous donner la solution du challenge avec l'aide d'une vidéo (que vous pouvez visualiser ICI).

La solution est composée de 3 étapes:

- la découverte d'une fonctionnalité de visualisation du code Java n'apparaissant pas dans la barre de menu mais malgré tout disponible
- une injection SQL classique
- et enfin une injection de commande DOS

Bien entendu, nous utilisons Webscarab pour observer et modifier les requêtes HTTP.

Bon film!

Comment connaître les types de failles?

Un bon moyen de connaître les failles possibles consiste à consulter les listes des failles les plus répandues publiées par l'OWASP ou par le SANS Institute.

Le "Top 10" de l'OWASP a pour but premier d'éduquer les développeurs, concepteurs, architectes et entreprises sur les conséquences des vulnérabilités de sécurité les plus communes des applications web. Le "Top 10" fournit des méthodes de base pour se protéger contre ces vulnérabilités - première étape indispensable à votre programme sécurité de programmation sécurisée.

L'édition précédente du "Top 10" contenait un mélange d'attaques, de vulnérabilités et de contre-mesures. Cette fois-ci, le document de l'OWASP se concentre essentiellement sur les vulnérabilités, bien que la terminologie généralement utilisée combine parfois vulnérabilités et attaques.

Vous trouverez le document décrivant ces failles à l'adresse suivante (document en français):

https://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf


Le document de SANS Institute est plus proche de la programmation. Un groupe d'experts internationaux s'est mis d'accord sur le"Top 25" des plus dangereuses erreurs de programmation qui mènent à des bugs de sécurité contribuant au cyber-espionnage et au cyber-crime. Etonnament la plupart de ces erreurs ne sont pas bien comprises par les programmeurs; la manière d'éviter ces erreurs n'est pas largement enseignée dans les écoles; et leur présence est rarement testée par les organisations vendant des logiciels.

Vous trouverez le document décrivant ces erreurs de programmation à l'adresse suivante (document en anglais):

http://www.sans.org/top25errors/

Comment détecter les failles de type XSS?

Si vous souhaitez automatiser la recherche des champs de saisie permettant de réaliser des attaques de type "XSS", vous pouvez utiliser l'outil "XSS Me" (add-on de Firefox)

Voici le résultat des tests avec "XSS Me" sur l'exercice "Reflected XSS attacks" de Webgoat:



On découvre que le champ "field1" est faillible.

L'inconvénient de la démarche automatisée est que de nombreux "faux-positifs" peuvent apparaître. Les outils automatisés ne sont généralement pas capables de détecter si la validation des paramètres est réalisée ou non.

L'approche manuelle est plus précise. Vous pouvez pour cela utiliser le script suivant:




Il suffit alors de saisir ce script dans les champs à tester. Si vous obtenez le pop-up ci-dessous alors le champ testé est faillible.


Il ne vous reste plus qu'à développer votre attaque en écrivant le script de votre choix. Vous trouverez un tutorial JavaScript sur le site:

http://www.w3schools.com/JS/default.asp

Par ailleurs vous trouverez les vidéos décrivant les solutions des exercices de Webgoat sur le site:

http://yehg.net/lab/pr0js/training/webgoat.php

Vous y trouverez également des scripts équivalents à ceux utilisés pendant le séminaire.

Outils utilisés lors du cours sur la sécurité des applications web

Firefox et ses plug-ins peuvent être utilisés pour mettre en évidence les failles d'un site web.

Lors du cours les plug-ins suivants sont utilisés:

• Firebug: pour parcourir l'arbre DOM, le modifier, débugger le JavaScript
• TamperData: pour modifier les requêtes HTTP
• LiveHTTPHeader: pour analyser les headers HTTP
• SwitchProxy: pour changer de proxy et passer par WebScarab par exemple

L'OWASP propose également des outils très intéressants tels que le proxy WebScarab. Lors du cours WebScarab permet d'intercèpter et de modifier les requêtes et les réponses HTTP.

Bien entendu il existe de nombreux outils disponibles pour Firefox et Internet Explorer également. L'important est de choisir ceux qui correspondent le mieux aux technologies mises en oeuvre dans le site web cible.