Cédric Bonnot

Après un aperçu de Fiddler, voici une présentation de l’outil IE Developer Toolbar.

Nous avons tous été confronté lors du développement d’un site web à une page dont la présentation nous pose problème.

Parfois le problème vient d’une hiérarchie d’éléments CSS altérant la page de manière inexacte, dans d’autres cas il s’agit d'une erreur dans les balises (X)HTML et malgré tous nos efforts ,le navigateur n’est pas capable d’effectuer le rendu de manière correcte.

Pour nous aider (et ce n’est rien de le dire), Microsoft met à notre disposition, et ce gratuitement, un outil nommé « Internet Explorer Developer Toolbar ». Cet outil permet de visionner non seulement de manière unitaire chaque élément d’une page Web mais aussi chaque aspect de celle-ci.

L’installation est aussi simple que celle de Fiddler ;-) Une fois installé, l'outils peut être activé via le menu « View – Explorer Bar – IE Developer Toolbar » ou plus directement par le bouton automatiquement ajouté à IE.

Figure 1 : ouverture de IE Developer Toolbar

Présentation générale

Lors de l’execution, trois panels sont ouvertes. Celle-ci sont, par défaut, positionnées en bas de l’écran.

Figure 2 : Présentation par défaut

Pour l’ouvrir sous forme d’application indépendante, il suffit de cliquer sur le bouton « Unpin » situé à droite de la barre d’outils de IE Toolbar.

Figure 3 : Ouverture sous forme d’application indépendante.

Le panel situé à gauche est composé d’un treeview listant chaque élément de la page. Cet écran nous permet ainsi de mieux comprendre la structure de la page en cours. La sélection d’un élément rempli automatiquement les deux autres panels. Ceux-ci contiennent alors l’ensemble des détails de l’élément tels que les attributs ou les styles.

Présentation des menus

Menu Find

Parce qu’une page peut être très complexe, deux méthodes sont possible pour sélectionner un élément particulier :
- En cliquant directement dessus après avoir choisi l’option « Select élément by click » depuis la barre d’outil ou le menu « Find - Select Elément By Click »
- En recherchant l’élément par son Id, Class ou Name en passant par le menu « Find – Search Elément »
Une fois l’élément sélectionné, il est possible de modifier un des attributs en double cliquant sur l’attribut choisi et ainsi en voir immédiatement le résultat. Vous pouvez même créer un attribut de toute pièce.

Menu Disable

Lorsqu’un problème surgit sur une page, la manière la plus simple de le trouver est parfois de simplifier la page.
Le menu Disable permet de désactiver certaines fonctionnalités du navigateur. Ces fonctionnalités sont :
- Les scripts clients (VB ou JS)
- Le popup blocker d’IE
- L’ensemble des styles CSS

Menu View

Ce menu permet d’afficher des détails concernant la page qui ne sont normalement pas disponibles. Ces options de menu sont :
- Class and ID information : affiche les ID et les classes CSS associés
- Link paths : indique l’URL des liens
- Links reports : ouvre une nouvelle page contenant l’ensemble des liens de la page
- Tab Indexes
- Access Keys
- Source : permet d’afficher le code source de la page
Revenons sur ce dernier menu. Le menu « View –Source » permet d’afficher le code source de la page entière ou bien d’une partie de la page (jusqu’au niveau élément ). Le code source est affiché dans un éditeur propriétaire. Celui-ci propose la coloration syntaxique, la numérotation des lignes, la notion de région dans le code (à l’instar de VS.NET) et le « word wrapping ».

Figure 4 : Page avec le menu Link Paths activé

Menu Outline

Comme les divers éléments d’une page peuvent être imbriqués de manière complexe. Il est donc nécessaire de pouvoir les identifier. Pour cela IE Dev Toolbar nous fournit de nombreuses options pour « souligner » différentes catégories d’éléments :
- Table Cells
- Table
- Div Elements
- Images
- Positioned Objects : sélectionne les éléments selon le mode de positionnement (relative, absolu, fixe, flottant)
- Any Elément : permet de définir sa propre liste d’éléments à surligner.

Figure 5 : page avec les balises DIV surlignées

Menu Picture

Ce menu contient plusieurs options permettant de travailler avec les images incluses dans la page.
- Disable Images
- Show Image Dimensions
- Show Image File Size
- Show Image Paths
- View Alt Text
- View Image Report : ouvre une nouvelle fenêtre affichant l’ensemble des images de la page contenant les informations des autres menus.

Figure 6 : fenêtre View Image Report

Menu Cache

Ce menu propose les options suivantes :
- Clear Browser Cache
- Clear Browser Cache for this domain
- Disable Session Cookies
- Clear Session Cookies
- Clear Cookies for this domain
- View Cookie Information : ouvre un fenêtre listant l’ensemble des cookies du domaine

Menu Tools

Ce menu propose une série d’outils très utile au quotidien :
- Resize : permet d’ajuster le navigateur à des tailles standards mais aussi personnalisées
- Show ruler : permet de mesurer la taille d’un élément
- Show Color Picker : permet d’obtenir la valeur hexadécimale et décimale d’une couleur.

Figure 7 : Outil Show Ruler

Menu Validate

Permet de vérifier que la page respecte les normes W3C (rare sont les pages les respectant). On peut valider :

- HTML
- CSS
- Feed
- Local HTML
- Local CSS

Conclusion

Même si ce projet n’est pas une nouveauté en soi, c’est la première application qui inclus l’ensemble des fonctionnalités généralement dispersées dans plusieurs applications.

Pour le télécharger :

Internet Explorer Developer Toolbar

Parmi les grandes évidences, un site web consomme de la bande passante et celle-ci bien baisse de manière constante, elle n'est pas infinie. Bien entendu il existe de nombreuses techniques pour en réduire son usage : compression, cache et meilleure gestion des appels serveurs en sont un exemple.
Malheureusement nous ne sommes pas toujours maitre de l'utilisation de la bande passante, particulièrement si l'on utilise des composants tiers ou la "technologie" AJAX.
Mais alors comment vérifier cela ? C'est là qu'un analyseur réseau tel que Fiddler devient indispensable.

A quoi sert Fiddler

Fiddler une fois installé sur un ordinateur client permet d'analyser exactement ce que contiennent (ou pas) les requêtes HTTP envoyées par le client au travers du réseau. Il capture les détails de chaque requête, postback, requête AJAX, ...
Il ne faut pas oublier que le chargement d'une page ne se fait pas en une seule requête mais en plusieurs parties (contenu html, images, fichiers JavaScript et CSS,...)
Fiddler permet de vérifier la manière dont chaque requête est gérée.
Fiddler trouve tout son intérêt avec les requêtes AJAX. En effet les requêtes AJAX étant invisibles à l'utilisateur, sans un outil comme Fiddler il est quasiment impossible de tracer les données échangées entre le serveur et le client.

Première utilisation

Le téléchargement et l’installation sont des plus simple. Une fois installé un bouton est disponible dans la barre de commandes d’Internet Explorer.

Figure1

Pour information, Fiddler est compatible avec IE et Firefox. Pour ce dernier il faut configurer son proxy sur l’adresse 127.0.0.1 et le port 8888 (merci à Améthyste pour cette info ;-) )
Un fois lancé, et sa fabuleuse interface apparue ;-) le trafic réseau est immédiatement loggé.

Figure 2

Sur la partie gauche on y retrouve la liste des « Web Sessions »
Un clic sur un des items de cette liste affiche l’écran « performance statistics ». A noter qu’il est possible de sélectionner plusieurs lignes afin d’agréger les résultats.
Cet écran permet de connaitre combien de bytes ont été envoyés et reçus et combien de temps cela a pris. Fiddler fournit une information assez originale puisqu’il est possible de connaitre le temps que cette même session aurait pris à d’autres endroits du monde et avec d’autres types de connexions.
Le lien « Show Chart » permet d’afficher un camembert

Figure 3

Lorsque qu’au moins une ligne est sélectionnée de nombreuses options sont proposées. On y retrouve la possibilité de :
- supprimer un, plusieurs ou tous les éléments.
- Marquer un ou plusieurs éléments avec une couleur différente.
- Enregistrer le ou les Requêtes/Réponses sous différent formats.
- Enregistrer la session sous plusieurs formats, ce qui inclus entres autres le format webtest de VS2005.

Un double clic sur une ligne affiche l’écran « Session Inspector ». Ce dernier ne compose de deux sous écrans. Celui du haut pour la requête et le celui du bas pour la réponse.

Figure 4

Pour chaque écran, on retrouve plusieurs onglets fournissant toutes les informations utiles :
- Header
- Text
- Forms
- Hexadecimal
- Authorization
- Raw
- XML

L’écran du bas (réponse) dispose en plus des onglets :
- Privacy
- Caching
- Image view

Analyse des événements

Chaque ligne de requête est composé de neuf colonnes pouvant être déplacées à souhait.

Figure 5

Les colonnes « Host » et « URL » contiennent les détails concernant le serveur, path et fichier de l’élément demandé. « Result » indique le code retourné par le serveur (ex : 200 - réponse OK et 404 - ressource non trouvée). « Body » contient la taille de la réponse. Cette valeur peut être égale à 0 si l’élément étant présent en cache dans le navigateur.
La colonne « Caching » indique le type de cache éventuellement appliqué à l’élément. « Content Type » donne le format du contenu associé à cette requête comme « text/html », « image/jpeg », « application/x-javascript », etc. On retrouve la valeur de ces deux colonnes dans l’écran « Session Inspector - Response»

Debug avec Fiddler

Une des fonctionnalités vraiment intéressante est la possibilité de créer des requêtes http à la volée. Pour cela il faut choisir l’onglet situé en haut à droite « Request Builder ».

Figure 6

Bien qu’il soit possible de tout saisir à la main, il est plus simple sélectionner une requête existante dans la liste de gauche en la faisant glisser sur la partie de droite. Ensuite libre à vous de modifier son contenu et d’exécuter la requête.

Une autre fonctionnalité est la possibilité de place un point d’arrêt avant que la requête soit envoyée au serveur ou juste après la réception de la réponse. Cela permet de modifier la requête après qu’elle soit générée mais avant son envoi au serveur.

Personnalisation de Fiddler

Pour tous ceux qui souhaite encore plus de fonctionnalités dans Fiddler, il est possible de le personnaliser afin de l’adapter à ses désidératas. Il est par exemple de possible de modifier les couleurs des éléments de la « Session List »
Pour « modifier » Fiddler, il faut utiliser le menu « Rules – Customize Rules… ». Cela ouvre le fichier CustomRules.js. Je vous laisse le découvrir mais pour information, il existe un éditeur spécialisé.

Resources en ligne

Le site Fiddler (http://www.fiddler2.com) met à disposition de nombreux outils et ressources. En voici une courte liste:
• Vidéos de démonstration: http://www.fiddlertool.com/fiddler/help/video/default.asp
• Editeur FiddlerScript: http://www.fiddlertool.com/fiddler/fse.asp
• FiddlerScript Cookbook : http://www.fiddlertool.com/fiddler/dev/scriptsamples.asp
• Etendre Fiddler avec du code personnalisé: http://www.fiddlertool.com/fiddler/dev/
• Fiddler FAQ: http://www.fiddler2.com/fiddler2/faq.asp
• Fiddler sur MSDN: http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/IE_Fiddler2.asp
• Fiddler Blog: http://insidehttp.blogspot.com
• Fiddler Forum: http://groups.msn.com/HTTPFiddler/

Après une longue absence, même très longue, me voiçi de retour sur les blogs DNG. J'espère que ma bonne résolution 2007 mais aussi mon temps libre me permettront de rédiger beaucoup plus souvent.

Et si on parlait d'obfuscation ?!?

Quoi de plus agaçant que de se faire voler son code source par son voisin de bureau afin qu'il en récolte la gloire !!!

Si si, je l'ai vécu il y a quelques semaines :-)))

Alors comment faire pour éviter (ou plutôt limiter) l'utilisation d'outils tiers tels que ILDASM.exe ou Reflector (pour les plus connus).

La technique pour limiter les menaces s'appelle "L'obfuscation" ou offuscation si l'on veut franciser le terme.

De quoi s'agit-il ?

Sans changer la finalité du code, l'offuscation protège le code source de la décompilation. Il s'agit d'une technologie qui rend beaucoup plus difficile la décompilation et freine considérablement les effets de reverse-engineering protégeant ainsi le code source de menaces éventuelles.

Il s'agit d'une technique, qui entre autre, renomme de manière automatique et transparente les symboles de l'assembly afin de les rendre plus compliqués à interpréter.

Quel est l'intérêt d'offusquer son code ?
Il y a plusieurs bonnes raisons de le faire :
- La taille de l'assembly s'en trouve réduit
- Les performances sont du coup meilleur
- Et surtout la propriété intellectuelle s'en trouve protégée.

Comment cela fonctionne t-il ?
Offuscation encrypte le code source et supprime les informations non nécessaire des métadonnées de l'assembly lorsque cela est possible et sûr. Les métadonnées de l'assembly et le manifeste sont utilisées par les désassembleurs pour décompiler et restituer le code source d'origine. A noter que même si l'application est compilé en code native lors de l'exécution, le runtime .NET nécessite encore que les métadonnées et le code IL soit inclus dans l'assembly avant de démarrer l'exécution.

L'offuscation ne change jamais, ni le code source, ni les fonctionnalités, mais transforme les assemblies en utilisant une méthode d'encryption spécifique.

Comment faire ?
De nombreux outils open source ou commerciaux existent pour cela. Un outil est fournit avec Visual Studio 2005 :

Dotfuscator Community Edition.
http://msdn2.microsoft.com/fr-fr/library/ms227240(VS.80).aspx

"Dotfuscator Community Edition est une version gratuite qui offre une offuscation de base. Son but principal est de renommer les identificateurs, en compliquant l'ingénierie à rebours. Dotfuscator Community Edition intègre des technologies avancées afin de faciliter cette protection."

Cet outil existe aussi en version Standard et Professionnel :

http://msdn2.microsoft.com/fr-fr/library/ms227255(VS.80).aspx

Est-ce la bonne solution ?
Malheureusement, aucun logiciel d'offuscation ne permet de protéger complètement le code source. Même si cela est un excellent moyen pour contrer la plupart des décompilateurs, si vous êtes déterminé et possédez un excellent niveau, vous serez toujours capable de piller le code depuis une assembly offusquée.

Une excellente présentation plus détaillée existe ici

Avant d'attaquer un projet nécessitant un haut niveau de sécurité applicative, j'avais comme beaucoup d'entre nous des connaissances plus ou moins avancées sur la sécurité applicative.

Cela m'a obligé à reprendre mes livres. Alors histoire de joindre l'utile à l'agréable, j'en profite pour préparer ma certification .

Comme je l'ai indiqué dans mon précédent article, voici un résumé des différents types d'attaques existants.

A. Attaque par débordement de buffer (Buffer Overflow)

Aussi connu comme « buffer overrun », le débordement de buffer est avéré lorsqu’une application tente de stocker plus de données dans un buffer que la mémoire allouée à ce dernier ne le permet. Le plus courant est le débordement de pile (stack overflow)

Le code suivant démontre ce type d’attaque en C :

main (int argc, char* argv[])
{
sub(argv[1]) ;
}

void sub(const char* input)
{
char buf[10];
strcpy(buf, input);
}

Lors de l’utilisation normale, tout se passe comme prévu : les données sont stockées dans la pile et récupérées en temps utile.

Par contre si on tente de passer plus de 10 caractères en entrée, sans contrôle supplémentaire, une partie des données contenues dans la pile va se retrouver écrasé par ce qui pourrait très bien être, dans le cas d’une attaque, du code « malveillant ». Ce dernier disposera des mêmes droits que l’application originale.

B. Attaque par erreur de parsing (Parsing Error)

Ce type d’erreur incluant les erreurs de canonisation, vulnérabilité CSS et vulnérabilité d’injection SQL est possible lorsqu’une application ne parvient pas à vérifier correctement les données saisies par l’utilisateur pouvant contenir du code « malveillant »

Erreur de canonisation (Canonicalization error)

Il s’agit d’une vulnérabilité autorisant à parser un nom de fichier avant que le système d’opération n’ait eu le temps de la canoniser.

Par exemple si une application bloque certains fichiers en téléchargement, il est possible d’essayer de forcer le filtre en utilisant des noms synonymes. Par exemple les noms suivants sont synonymes :

- NePasToucher.txt
- NePasT~1.txt
- NePasToucher.txt.
- NePasToucher.txt ::$DATA

Autre exemple dans le cas d’une requête web « GET /docs/index.htm ». Pourquoi ne pas essayer « GET /../../boot.ini ». La plupart des serveurs empêche les attaques les plus courantes de ce type.

Erreur dite Cross-Site Scripting

Il s’agit d’une erreur de parsing permettant à un utilisateur malveillant d’utiliser une zone de saisie afin d’afficher du code potentiellement dangereux pour les autres utilisateurs. Par exemple dans le cas d’un blog ou d’un guestbook on pourrait saisir :

Hi, great page ! <img src= ”attacker.site.com/counter.aspx » width=1 height=1”/> On peut même faire plus performant !

Erreur dite SQL Injection

Il s’agit d’une erreur de parsing permettant à un utilisateur malveillant d’utiliser une zone de saisie utilisée pour créer une requête SQL afin d’y insérer des commandes supplémentaires. Par exemple :

String requete = “Select HasShipped From orders Where ID=’” + Id + “’”;

Si “Id” est récupéré par l’intermédiaire d’un TextBox, si l’utilisateur renter “12345” tout va bien, mais que se passe t’il s’il rentre “12345’ drop table customers – “ ?

Dans le cas de droits permettant l’écriture, ce code va tout simplement supprimer la table concernée.

C. Attaque par déni de service (Denial-Of-Service)

Une attaque de type DoS empêche les utilisateurs légitimes d’accéder à un service réseau. Afin d’éviter à une application d’être trop vulnérable, il est par exemple indispensable, dans le cas d’une allocation mémoire par utilisateur, de ne pas allouer cette dite mémoire avant d’être sur de l’identité de l’utilisateur.

D. Attaque par « craquage » cryptographique

Il s’agit d’intercepter du contenu encrypté et d’essayer de le décrypter. Il s’agit de la méthode utilisée lorsque toutes les autres attaques ont échouées. Le décryptage peut prendre des années voir des milliers, donc l’attaquant compte plutôt sur la négligence du développeur qui a, par exemple, stocké la clé privé dans un emplacement insuffisamment protégé.

E. Attaque dite « Man-In-The-Middle »

Il s’agit d’une attaque sophistiquée dans laquelle un attaquant « simule » le serveur pour intercepter les requêtes d’un client légitime et ensuite se fait passer pour ce client auprès du serveur. Seul une application n’ayant ni authentification, ni encryptage des données peut subir ce type d’attaque.

F. Attaque par « craquage » du mot de passe

Il s’agit de découvrir un mot de passe en effectuant une multitude de tentatives. Les deux approches utilisées sont : brute et dictionnaire

Bonjour à tous,

Puisque sir Amethyste à de manière honteuse placé un lien vers mon blog désespérément vide, je me sens obligé de commencer à le remplir :oops: :roll:

Je travaille actuellement pour une société de service très étroitement liée à Microsoft.

Un de mes collègues de travail n'est entre autres que le grand spécialiste .NET et surtout grand amateur de blog aka Amethyste. Je conseille très fortement la lecture de ses différents articles ici

Quant à moi pour terminer mon cursus MCSD.NET j'ai décidé de m'attaquer à la certification 70-340. C'est une des plus "passionnantes" à préparer.

Je diffuserai au fur et à mesure de mon avancement le résumé de ma préparation.

En attendant voiçi les ressources que j'utilise en plus du site msdn :

- Implementing Security for Applications with Microsoft Visual Basic .NET and Microsoft Visual C# .NET
Contrairement à certains autres guides de préparation de chez MSPress, je trouve ce livre excellent. Et je ne suis pas le seul ...

- Tout sur le code
- Ecrire du code sécurisé
Ces deux livres reprennent en plus détaillé la majorité des thèmes abordée dans le livre Mspress

Bonne lecture

I'LL BE BACK

Cédric