Information Security Consultant<br>

Previous experience : Chief Information Security Officer for 6 years
and more than 20 years in IT development, audit, computer operation,
communication and network security, security operations

Knowledge : Security and Risk Management, Asset Security,
Security Engineering, Communications and Network Security, Security Operations,
Software Development Security

CISSP-CISA-
Computer Engineer-
Master «Security,Cryptology and Coding of Information Systems»<br />

Contribution to French translation of the «OWASP TOP TEN 2013» :
[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20French.pdf OWASP TOP 10 2013 en Français]<br /><br>

Contribution to French translation of the «OWASP Testing Guide v4» :<br />

[[4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)]]

[[4.3.4 Revue des fichiers obsolètes, de sauvegarde, non référencés pour recherche d'informations sensibles (OTG-CONFIG-004)]]

[[4.3.6 Test des Methodes HTTP (OTG-CONFIG-006)]]

[[4.5.8 Test de Questions-Reponses Faibles (OTG-AUTHN-008)]]

[[OWASP Guide de Test v4-Annexe B-Conseils de Lecture]]

2015-10-06T19:18:48Z

Vall:

4.3.4 Revue des fichiers anciens, non references, ou de sauvegarde pour recherche d'informations sensibles (OTG-CONFIG-004)

2015-10-06T19:02:06Z

{{Template:OWASP Testing Guide v4}}

== Sommaire ==

Alors que la plupart des fichiers d’un serveur web sont stockés sur le serveur lui-même, il n’est pas inhabituel d’y trouver des fichiers sans référence,
ou oubliés, qui permettent d’obtenir des informations sensibles sur l’infrastructure ou, même, des justificatifs d’accès.

Le plus souvent, on retrouve des anciennes versions de fichiers modifiés, renommés en «.old », la mention de fichiers qui sont chargés suivant le choix du
langage et qui peuvent être téléchargés comme source, ou même des sauvegardes automatiques, ou manuelles, telles que des archives compressées. Des fichiers
de sauvegarde peuvent aussi être générés automatiquement par le système de fichiers sur lequel l’application est hébergée, une fonction habituellement
appelée "copie instantanée" ou "snapshot".

Tous ces fichiers peuvent permettre au testeur d’accéder au fonctionnement interne, aux portes dérobées, aux interfaces d’administration, ou même aux comptes
privilégiés permettant les accès administrateur et aux bases de données.

Il y a une source importante de vulnérabilités parmi les fichiers n’ayant aucun lien avec l’application, sauf d’avoir été générés par l’édition de fichiers
d’application, ou issus de copies de sauvegarde instantanées, ou fichiers anciens ou non référencés laissés dans l’arborescence du serveur web.
Editer des fichiers sur le serveur de production ou, y faire d’autres actions de type administrateur, peut y laisser malencontreusement des copies de sauvegarde
ou des fichiers générés par l’édition de fichiers, ou par l’administrateur créant un fichier zippé d’un ensemble de fichiers pour faire une sauvegarde.

C’est facile d’oublier de tels fichiers et cela peut présenter de sérieuses menaces de sécurité pour l’application.
Cela arrive parce que les copies de sauvegarde peuvent générer des extensions de sauvegarde différentes des fichiers originaux.
Une archive .tar, .zip ou .gz que nous générons (et oublions) a, bien sûr, une extension différente, et il arrive la même chose
avec les copies générées par plusieurs éditeurs (par exemple, emacs génère une copie de sauvegarde nommée ''file~'' lorsqu’on édite ''file'').
Une copie manuelle peut aboutir au même effet (comme copier ''file'' en ''file.old''). Le système de fichier sous-jacent peut faire des «copies instantanées»
de vos applications, à différents moments, sans que vous le sachiez, et ils peuvent être accessibles par le web, ce qui présente une menace de type
«fichiers de sauvegarde», différente mais similaire, pour votre application.

Ainsi, ces activités peuvent générer des fichiers non nécessaires à l’application qui peuvent être utilisés différemment des fichiers originaux par le serveur web. Par exemple, si nous faisons une copie du fichier ''login.asp'' vers ''login.asp.old'', nous permettons aux utilisateurs de télécharger le code source de ''login.asp''. Ceci parce ''login.asp.old'' sera habituellement ouvert comme un fichier texte ou brut plutôt qu’exécuté à cause de son extension.

En d’autres mots, l’accès au fichier ''login.asp'' entraîne l’exécution sur le serveur du code ''login.asp'' tandis que l’accès au fichier ''login.asp.old'' entraîne le contenu du fichier ''login.asp.old'' (qui est, là aussi, le code du serveur) à être affiché clairement sur le navigateur de l’utilisateur. Cela présente des risques de sécurité puisque des informations de sécurité peuvent ainsi être révélées.

Généralement, exposer le code du serveur n’est pas une bonne idée. Non seulement, vous exposez inutilement la logique de l’entreprise mais vous pouvez divulguer sans le savoir des informations relatives à l’application qui peuvent aider l’attaquant (chemin d’accès, structures des données, etc...).

Ceci sans mentionner le fait qu’on trouve beaucoup trop de scripts avec des comptes et mots de passe en clair (ce qui est une pratique imprudente et dangereuse).

D’autres causes de fichiers non référencés sont dues aux choix d’architecture et de configuration quand ceux-ci permettent au serveur web d’accéder à toutes sortes de fichiers relatifs à l’application tels que des fichiers de données, de configuration, de logs stockés dans des répertoires du système de fichier.

Ces fichiers n’ont normalement rien à faire dans l’espace du système de fichiers accessible par le web puisqu’ils ne devraient être accessibles qu’au niveau de l’application, par l’application elle-même (et non par un utilisateur occasionnel qui navigue autour).

=== Menaces ===

Les fichiers de sauvegardes et, les fichiers anciens ou non référencés, représentent diverses menaces à la sécurité d’une application web :

* Les fichiers non référencés peuvent dévoiler des informations sensibles qu peuvent faciliter une attaque ciblée d’une application ; par exemple cela comprend les bases de données de justificatifs d’accès, les fichiers de configuration contenant des références à des contenus cachés, chemins d’accès complets, etc...

* Des pages non référencées peuvent contenir de puissantes fonctionnalités pouvant être utilisées pour attaquer l’application ; par exemple une page d’administration non publiée mais qui peut être accédée par n’importe quel utilisateur qui sait où la trouver.

* D’anciens fichiers ou des fichiers de sauvegarde peuvent contenir des vulnérabilités qui ont été corrigées dans des versions plus récentes ; par exemple ''viewdoc.old.jsp'' peu contenir une vulnérabilité de type «traversée de répertoires» ou "Path Traversal" qui a été corrigée dans ''viewdoc.jsp'' mais peut toujours être exploitée par celui qui trouve cette vieille version.

* Les fichiers de sauvegarde peuvent dévoiler le code source des pages prévues pour être exécutées sur le serveur ; par exemple, ouvrir ''viewdoc.bak'' peut renvoyer le code source de ''viewdoc.jsp'', qui peut être analysé pour en rechercher les vulnerabilités qui seraient difficiles à trouver en faisant des requêtes à l’aveugle vers la page exécutable. Alors que cette menace s’applique évidemment au langages de script, tels que Perl, PHP, ASP, shell scripts, JSP, etc., cela ne se limite pas à eux seuls, comme nous le verrons dans l’exemple du prochain paragraphe.

* Les fichiers de sauvegarde peuvent contenir des copies de tous les fichiers sous la racine (ou même en dehors) du site web. Cela permet à l’attaquant de rapidement énumérer l’application entière, dont les pages non référérencées, le code source, les fichiers inclus, etc... par exemple, si vous avez oublié un fichier nommé ''myservlets.jar.old'' qui contient (une copie de sauvegarde de) vos classes de servlet implémentées, vous exposez beaucoup d’informations sensibles pouvant faire l’objet de décompilation ou de rétro-ingénierie.

* Dans certains cas, éditer ou copier un fichier ne modifie pas l’extension de fichier mais modifie le nom du fichier. Cela arrive, par exemple dans les environnements Windows, où les opérations de copie de fichier génèrent des fichiers suffixés avec «-Copie» ou des versions locales de cette chaîne. Puisque l’extension de fichier reste inchangée, ce n’est pas le cas où le fichier exécutable est renvoyé comme texte en clair par le serveur web, donc pas un cas de divulgation de code source. Malgré tout, ces fichiers aussi sont dangereux car il y a une possibilité qu’ils contiennent une logique incorrecte ou obsolète et peuvent, s'ils sont accédés, déclencher des erreurs d’application, qui donnent de précieuses informations à l’attaquant, si le message d’erreur s’affiche.

* Les fichiers journaux peuvent contenir des informations sensibles à propos des usages de l’application par les utilisateurs, par exemple les données sensibles passées en paramètre aux URL, les ID de session, les URL visités (qui peuvent divulguer d’autres contenus non référencés), etc... D’autres fichiers journaux (ex. les journaux ftp) peuvent contenir des informations sensibles à propos de la maintenance de l’application par les administrateurs système.

* Les copies instantanées de système de fichiers peuvent contenir des copies de code ayant des vulnérabilités corrigées dans les versions plus récentes. Par exemple, ''/.snapshot/monthly.1/view.php'' peut contenir une vulnérabilité de type « traversée de répertoire » qui a été corrigée dans ''/view.php'' mais qui peut toujours être exploitée par celui qui trouve la vieille version du fichier.

== Comment Tester==

=== Test en Boite Noire ===

Le test des fichiers non référencés utilise à la fois des techniques manuelles et automatiques et typiquement combine les suivantes :

==== Déductions du schéma de nommage du contenu publié ====

Dénombrer toutes les pages et les fonctionnalités de l’application. Cela peut être fait manuellement avec un navigateur ou en utilisant un outil d’exploration (« spidering ») d’application. La plupart des applications utilisent un schéma de nommage identifiable, et organisent les ressources en pages et répertoires en utilisant des mots décrivant leurs fonctions. A partir du schéma de nommage utilisé pour le contenu publié, il est souvent possible d’en déduire le nom et l’emplacement des fichiers non référencés. Par exemple, si on trouve une page ''viewuser.asp'', alors il faut chercher ''edituser.asp'',''adduser.asp'' et ''deleteuser.asp''. Si on trouve un répertoire ''/app/user'', il faut aussi chercher ''/app/admin'' et ''/app/manager''.

==== Autres indices dans le contenu publié ====

Beaucoup d’applications web laissent des indices dans leur contenu publié qui peuvent conduire à découvrir des fonctionnalités ou des pages cachées. Ces indices se retrouvent souvent dans le code source HTML et dans les fichiers JavaScript. Le code source de tous les contenus publiés devrait être revu manuellement pour identifier les indices laissés concernant les fonctionnalités et les pages.
Par exemple :

Les commentaires et les sections commentées du code source par les programmeurs peuvent faire référence à du contenu caché :
<pre>


</pre>

JavaScript peut contenir des liens sur des pages qui sont uniquement émises dans l’interface graphique de l’utilisateur dans certaines circonstances :
<pre>
var adminUser=false;
:
if (adminUser) menu.add (new menuItem ("Maintain users", "/admin/useradmin.jsp"));
</pre>

Les pages HTML peuvent contenir des FORMs qui ont été cachées en désactivant l’élément SUBMIT :
<pre>
<FORM action="forgotPassword.jsp" method="post">
<INPUT type="hidden" name="userID" value="123">

</FORM>
</pre>

Une autre source d’indices concernant les répertoires non référencés est le fichier ''/robots.txt'', fichier utilisé pour donner des instructions aux robots d’indexation du web :
<pre>
User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include
</pre>

==== Recherche à l'aveugle ====

Dans sa forme la plus simple, il s'agit de lancer une recherche de noms de fichiers usuels via un moteur de requêtes dans le but de deviner quels sont les fichiers et les répertoires existant sur le serveur.
Ce "wrapper" script netcat lira une liste de mots à partir de stdin et réalisera une attaque élémentaire par conjecture ou "guessing attack" :

<pre>
#!/bin/bash

server=www.targetapp.com
port=80

while read url
do
echo -ne "$url\t"
echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile

</pre>

Suivant la configuration du serveur, on pourra remplacer la commande GET par une commande HEAD pour avoir des résultats plus rapides. On pourra ensuite faire une commande grep sur le fichier de sortie pour y rechercher des codes de réponse “interessants”. Le code de réponse "200" (OK) indique habituellement qu'une ressource valide a été trouvée (a priori, un serveur ne renvoie pas une page “not found” avec un code "200").

Rechercher aussi les codes "301" (Déplacé), "302" (Trouvé), "401" (Non autorisé), "403" (Interdit) and 500 (Erreur Interne), qui peuvent aussi référencer des ressources et des répertoires qui méritent plus d'investigation.

L'attaque élémentaire par conjecture doit s'effectuer sur le répertoire racine du serveur, le "webroot", et aussi sur tous les répertoires identifiés par d'autres méthodes d'énumeration.
Des attaques par conjecture, plus avancées et efficaces, peuvent être réalisées comme ceci:

* Identifier les extensions de fichiers utilisées dans les espaces connus de l'application (ex. jsp, aspx, html), et prendre une liste de mots de base ajoutés à ces extensions ou prendre une plus longue liste des extensions communes si les ressources le permettent).

* Pour chaque fichier identifié par d'autres techniques d'énumeration, créer une liste de mots personnalisés dérivés du nom de fichier.
Prendre une liste des extensions de fichier usuels (incluant les ~, bak, txt, src, dev, old, inc, orig, copy, tmp, etc.) et utiliser chaque extension avant, après, et à la place de l'extension actuelle du fichier.

Note: Les opérations de copie de fichiers Windows generent des noms de fichiers postfixés par “-Copie“ ou par des versions localisées de cette chaîne, mais ne change pas l'extension du fichier.
Quoique les fichiers “-Copie“ ne divulguent pas habituellement le source code quand on y accède, ils peuvent néanmoins apporter des informations sensibles dans le cas où ils génèrent des erreurs quand on y accède.

==== Informations obtenues grâce aux vulnérabilités et aux mauvaises configurations du serveur ====

Le cas le plus flagrant où une mauvaise configuration du serveur peut divulguer des pages non référencées est l'énumération des répertoires.
Rechercher dans tous les répertoires énumérés pour identifier ceux qui listent des répertoires.

On trouve de nombreuses vulnerabilités sur des serveurs web personnels qui permettent aux attaquants de lister du contenu non référencé, comme par exemple:

* Apache ?M=D directory listing vulnerability.
* Various IIS script source disclosure vulnerabilities.
* IIS WebDAV directory listing vulnerabilities.

==== Utilisation de l'information accessible au public ====

Les pages et les fonctionnalités, des applications web sur Internet, qui ne sont pas référencées par l'application elle-même peuvent être référencées par d'autres sources du domaine public.
Il existe plusieurs sources de ces références :

* Les pages habituellement référencées peuvent toujours apparaître dans les archives des moteurs de recherche Internet. Par exemple, ''1998results.asp'' peut ne plus être lié à un site web d'entreprise,
mais cependant rester sur le serveur et dans les bases de données des moteurs de recherche. Ce vieux script peut contenir des vulnérabilités qui peuvent permettre de compromettre le site entier.
L'opérateur de recherche Google ''site:'' peut être utilisé pour faire une recherche sur un seul domaine choisi, comme dans : ''site:www.example.com''. Utiliser les moteurs de recherche de cette façon a permis un large éventail de techniques que vous pourrez trouver utiles et qui sont décrites dans la section ''Google Hacking'' de ce Guide. Lisez-le pour affûter vos compétences de test via Google.

les fichiers de sauvegarde ne sont probablement pas référencés par d'autres fichiers et ainsi ne doivent pas été indexées par Google mais s'ils se trouvent dans des répertoires accessibles par votre navigateur,le moteur de recherche peut en avoir connaissance.

* De plus, Google et Yahoo conservent des versions en cache des pages trouvées par leurs robots. Même si ''1998results.asp'' a été supprimé du serveur cible, une version de ses résultats peut toujours être stockée par ces moteurs de recherche. Ces versions en cache peuvent contenir des références ou, des indices ou, un autre contenu additionnel caché, qui existent toujours sur le serveur.

* Du contenu, non référencé par une application cible, peut être lié à des sites web d'un tiers. Par exemple, une application qui gère les paiements en ligne pour le compte d'un site marchand peut contenir une diversité de fonctionnalités sur mesure qui ne doivent, normallement, être retrouvées qu'en suivant les liens des sites web de leurs clients.

==== Contournement du filtrage des noms de fichiers ====

Comme les filtres de liste noire sont basés sur des expressions régulières, on peut parfois profiter de fonctionnalités d'expansions opaques de noms de fichiers qui fonctionnent d'une façon que le développeur n'imagine pas.

Le testeur peut parfois exploiter la différence dans la façon dont les noms de fichiers sont analysés par l'application, le serveur web, et le système d'exploitation sous-jacent et ses conventions de nommage de fichiers.

Exemple: Expansion des noms de fichiers sous Windows 8.3
"c:\program files" devient "C:\PROGRA~1"

<pre>
– Supprime les caractères incompatibles
– Convertit les espaces en caractère souligné bas "_"
- Prend les six premiers caractères du nom
– Ajoute “~<chiffre>” pour différencier les fichiers dont les noms ont les mêmes six premiers caractères
- Cette convention change après les 3 premières collisions de noms
– Tronque les extensions de fichiers à trois caractères
- Mets tous les caractères en lettres majuscules
</pre>

=== Test en Boite Grise ===

Réaliser un test en boite grise sur les vieux fichiers et les fichiers de sauvegarde nécessite l'examen des fichiers contenus dans les répertoires appartenant à l'ensemble des répertoires
web servis par le(s) serveur(s) internet de l'infrastructure de l'application. Théoriquement, l'examen devrait être réalisé manuellement pour être exhaustif.

Quoiqu'il en soit, comme la plupart du temps les copies ou les sauvegardes de fichiers utilisent les mêmes conventions de nommage, la recherche peut être effectuée facilement par script.
Par exemple, les éditeurs nomment les copies de sauvegardes avec une extension reconnaissable et les humains tendent à les nommer en .old ou une autre extension similaire prédictible.

Uune bonne stratégie consiste à planifier une tâche de fond périodique à la recherche de fichiers avec des extensions qui les identifient comme de probables copies ou des sauvegardes de fichiers
et à faire aussi des vérifications manuelles sur des périodes plus longues.

== Outils ==

* Les outils d'évaluation de vulnérabilités tendent à inclure des vérifications pour repérer les répertoires web avec des noms standard (tels que “admin”, “test”, “backup”, etc.), et à remonter tout répertoire web qui autorise l'indexation.

Si vous ne pouvez pas lister les répertoires, vous devriez essayer de vérifier les extensions probables des fichiers de sauvegarde.
Regarder par exemple Nessus (http://www.nessus.org), Nikto2(http://www.cirt.net/code/nikto.shtml)
ou les nouveaux dérivés Wikto (http://www.sensepost.com/research/wikto/),qui supportent les stratégies de base du Google hacking.

* Robots d'exploration du Web "spider tools":

wget (http://www.gnu.org/software/wget/, http://www.interlog.com/~tcharron/wgetwin.html);
Sam Spade (http://www.samspade.org);
Le proxy Spike comprend une fonction d'exploration de site web (http://www.immunitysec.com/spikeproxy.html);
Xenu (http://home.snafu.de/tilman/xenulink.html);
curl (http://curl.haxx.se).
Certains de ces outils sont compris en standard dans les distributions Linux.

* Les utilitaires de développement Web ont généralement des outils pour identifier les liens cassés et les fichiers non référencés.

== Remediation ==

Pour garantir une stratégie de protection efficace, les tests doivent être complétés par une politique de sécurité qui interdit clairement des pratiques dangereuses telles que :

* Editer des fichiers directement sur le serveur web ou sur le système de fichiers de l'application. C'est vraiment une mauvaise habitude car il est prévisible que les éditeurs génèrent des fichiers de backup non souhaités. C'est étonnant de voir comme c'est fréquent, même dans les grandes organisations. Si vous avez absolument besoin d'éditer un fichier sur un serveur de production,assurez-vous de n'y laisser que ce qui est explicitement nécessaire, et considérez que vous le faites à vos propres risques.

* Vérifier soigneusement toute autre acticité réalisée sur le système de fichiers exposé par le serveur web, telles que les activités d'administration.
Par exemple, si vous avez occasionnellement besoin de faire une "copie instantanée" de quelques répertoires (ce que vous devriez pas faire en production), vous pouvez être tenté de les zipper d'abord.
Faites attention de ne pas oublier de ne pas laisser l'archive derrière vous.

* Une politique de gestion de configuration devrait permettre de ne pas laisser traîner des fichiers obsolètes ou non référencés.

* Les applications devraient être concues pour ne pas créer (ou s'appuyer sur) des fichiers stockés sous l'arborescence de répertoires mis à disposition par le serveur web. Les fichiers de données, de trace, de configuration, etc..., devraient être stockés dans des répertoires inacessibles au serveur web, pour contrer les possibilités de divulgation d'information (pas pour mentionner des modifications de données si les permissions sur les répertoires web permettent d'écrire).

* Les "copies instantanées" ou "snapshot" de système de fichiers ne devraient pas être accessibles par le web si l'emplacement du document est sur un système de fichiers utilisant cette technologie.

Configurer votre serveur web pour refuser l'accès à de tels répertoires, par exemple, sous apache une directive <location>, comme indiqué ci-dessous, devrait être mise en place :

<pre>
<Location ~ ".snapshot">
Order deny,allow
Deny from all
</Location>
</pre>

User:Vall

2015-10-06T18:48:44Z

Vall:

Information Security Consultant

Previous experience : Chief Information Security Officer for 6 years
and more than 20 years in IT development, audit, computer operation,
communication and network security, security operations

Knowledge : Security and Risk Management, Asset Security,
Security Engineering, Communications and Network Security, Security Operations,
Software Development Security

CISSP-CISA-
Computer Engineer-
Master «Security,Cryptology and Coding of Information Systems»<br />

Contribution to French translation of the «OWASP TOP TEN 2013» :
[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20French.pdf OWASP TOP 10 2013 en Français]<br />

Contribution to French translation of the OWASP Testing Guide v4 :<br />

[[4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)]]

[[4.3.4 Revue des fichiers anciens, non references, ou de sauvegarde pour recherche d'informations sensibles (OTG-CONFIG-004)]]

[[4.3.6 Test des Methodes HTTP (OTG-CONFIG-006)]]

2015-10-02T09:12:04Z

Vall:

User:Vall

2015-10-02T09:10:29Z

Vall:

4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)

2015-10-02T09:09:11Z

Vall:

{{Template:OWASP Testing Guide v4}}

== Sommaire ==

C’est très courant, et même recommandé, que les programmeurs mettent des commentaires détaillés et des métadonnées dans leur code source. Cependant des commentaires et des métadonnées, dans du code HTML, peuvent révéler des informations internes qui ne devraient pas être accessibles à de potentiels attaquants.
Il faut faire une revue des commentaires et des métadonnées pour déterminer s’il y a des fuites d’information.

== Objectifs du test ==

La revue des commentaires et métadonnées permet de mieux comprendre l’application et de trouver d’éventuelles fuites d’information.

== Comment Tester ==

Les commentaires HTML sont souvent utilisés par les programmeurs pour déboguer une application. Parfois, ils oublient ces commentaires et les laissent en exploitation. Les testeurs doivent rechercher les commentaires HTML qui commencent par <pre> </pre>

=== Test en Boite Noire ===

Rechercher, dans le code source HTML, les commentaires contenant des informations sensibles qui pourraient aider l’attaquant à mieux comprendre l’application. Cela peut être du code SQL, des identifiants et des mots de passe, des adresses IP internes ou des informations de débogage.
...
<pre>
<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

Le testeur peut même trouver des informations telles que :

<pre>

</pre>

Vérifier la version HTML et les URLs de Définition de Type de Document (DTD) pour connaître les versions applicables :
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents
</pre>

Certaines balises META ne fournissent pas de vecteur d’attaque active mais peuvent permettre à un attaquant d’obtenir des informations à propos de l’application comme, par exemple :
<pre>
<META name="author" content="Andrew Muller">
</pre>
Certaines balises META modifient les entêtes des réponses HTTP comme, par exemple, la balise META http-equiv qui met dans l’entête de la réponse HTTP, la valeur de l’attribut «content».

Ainsi la balise :
<pre>
<META http-equiv="expires" content="Fri, 21 Dec 2012 12:34:56 GMT">
</pre>
générera dans l’entête HTTP de réponse :
<pre>
expires: Fri, 21 Dec 2012 12:34:56 GMT
</pre>
Et la balise suivante :
<pre>
<META http-equiv="cache-control" content="no-cache">
</pre>
génèrera dans l’entête HTTP :
<pre>
cache-control: no-cache
</pre>
Tester si cela peut permettre de réaliser une attaque par injection (par ex. une attaque CRLF). Cela peut aussi aider à déterminer le niveau de fuites de données à partir du cache du navigateur.

Une balise META usuelle, mais non conforme aux lignes directrices sur l'accessibilité des contenus Web(WCAG), est "refresh" :
<pre>
<META http-equiv="refresh" content="15; URL=https://www.owasp.org/index.html">
</pre>
Une utilisation usuelle de la balise META permet de spécifier les mots-clés que le moteur de recherche peut utiliser pour améliorer la qualité des résultats :
<pre>
<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">
</pre>
Bien que la plupart des serveurs web gèrent l’indexation des moteurs de recherche avec le fichier robots.txt, cela peut aussi être géré avec des balises META.
La balise suivante informe les robots de ne pas indexer et de ne pas suivre les liens sur les pages HTML contenant cette balise :
<pre>
<META name="robots" content="none">
</pre>

Les recommandations, élaborées par le consortium international W3C, telles que PICS «plate-forme de sélection du contenu Internet» ou, POWDER «protocole de description des ressources du Web» fournissent une infrastructure d’association des métadonnées avec un contenu Internet.

=== Test en Boite Grise ===

Non applicable.

== Outils ==

* Wget
* Fonction du navigateur "voir le code source"
* Eyeballs
* cURL

== Références ==

[1] http://www.w3.org/PICS/ PICS, plate-forme de sélection du contenu Internet<br>
[2] http://www.w3.org/2009/09/powder-pr.html.fr POWDER, protocole de description des ressources du Web

'''Livres Blancs'''
[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01<br>
[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (pour petits appareils)<br>
[3] http://www.w3.org/TR/html5/ HTML version 5

4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)

2015-10-02T09:07:43Z

Vall:

{{Template:OWASP Testing Guide v4}}

== Sommaire ==

C’est très courant, et même recommandé, que les programmeurs mettent des commentaires détaillés et des métadonnées dans leur code source. Cependant des commentaires et des métadonnées, dans du code HTML, peuvent révéler des informations internes qui ne devraient pas être accessibles à de potentiels attaquants.
Il faut faire une revue des commentaires et des métadonnées pour déterminer s’il y a des fuites d’information.

== Objectifs du test ==

La revue des commentaires et métadonnées permet de mieux comprendre l’application et de trouver d’éventuelles fuites d’information.

== Comment Tester ==

Les commentaires HTML sont souvent utilisés par les programmeurs pour déboguer une application. Parfois, ils oublient ces commentaires et les laissent en exploitation. Les testeurs doivent rechercher les commentaires HTML qui commencent par <pre> </pre>.

=== Test en Boite Noire ===

Rechercher, dans le code source HTML, les commentaires contenant des informations sensibles qui pourraient aider l’attaquant à mieux comprendre l’application. Cela peut être du code SQL, des identifiants et des mots de passe, des adresses IP internes ou des informations de débogage.
...
<pre>
<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

Le testeur peut même trouver des informations telles que :

<pre>

</pre>

Vérifier la version HTML et les URLs de Définition de Type de Document (DTD) pour connaître les versions applicables :
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents
</pre>

Certaines balises META ne fournissent pas de vecteur d’attaque active mais peuvent permettre à un attaquant d’obtenir des informations à propos de l’application comme, par exemple :
<pre>
<META name="author" content="Andrew Muller">
</pre>
Certaines balises META modifient les entêtes des réponses HTTP comme, par exemple, la balise META http-equiv qui met dans l’entête de la réponse HTTP, la valeur de l’attribut «content».

Ainsi la balise :
<pre>
<META http-equiv="expires" content="Fri, 21 Dec 2012 12:34:56 GMT">
</pre>
générera dans l’entête HTTP de réponse :
<pre>
expires: Fri, 21 Dec 2012 12:34:56 GMT
</pre>
Et la balise suivante :
<pre>
<META http-equiv="cache-control" content="no-cache">
</pre>
génèrera dans l’entête HTTP :
<pre>
cache-control: no-cache
</pre>
Tester si cela peut permettre de réaliser une attaque par injection (par ex. une attaque CRLF). Cela peut aussi aider à déterminer le niveau de fuites de données à partir du cache du navigateur.

Une balise META usuelle, mais non conforme aux lignes directrices sur l'accessibilité des contenus Web(WCAG), est "refresh" :
<pre>
<META http-equiv="refresh" content="15; URL=https://www.owasp.org/index.html">
</pre>
Une utilisation usuelle de la balise META permet de spécifier les mots-clés que le moteur de recherche peut utiliser pour améliorer la qualité des résultats :
<pre>
<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">
</pre>
Bien que la plupart des serveurs web gèrent l’indexation des moteurs de recherche avec le fichier robots.txt, cela peut aussi être géré avec des balises META.
La balise suivante informe les robots de ne pas indexer et de ne pas suivre les liens sur les pages HTML contenant cette balise :
<pre>
<META name="robots" content="none">
</pre>

Les recommandations, élaborées par le consortium international W3C, telles que PICS «plate-forme de sélection du contenu Internet» ou, POWDER «protocole de description des ressources du Web» fournissent une infrastructure d’association des métadonnées avec un contenu Internet.

=== Test en Boite Grise ===

Non applicable.

== Outils ==

* Wget
* Fonction du navigateur "voir le code source"
* Eyeballs
* cURL

== Références ==

[1] http://www.w3.org/PICS/ PICS, plate-forme de sélection du contenu Internet<br>
[2] http://www.w3.org/2009/09/powder-pr.html.fr POWDER, protocole de description des ressources du Web

'''Livres Blancs'''
[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01<br>
[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (pour petits appareils)<br>
[3] http://www.w3.org/TR/html5/ HTML version 5

4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)

2015-10-02T08:59:08Z

Vall:

{{Template:OWASP Testing Guide v4}}

== Sommaire ==

C’est très courant, et même recommandé, que les programmeurs mettent des commentaires détaillés et des métadonnées dans leur code source. Cependant des commentaires et des métadonnées, dans du code HTML, peuvent révéler des informations internes qui ne devraient pas être accessibles à de potentiels attaquants.
Il faut faire une revue des commentaires et des métadonnées pour déterminer s’il y a des fuites d’information.

== Objectifs du test ==

La revue des commentaires et métadonnées permet de mieux comprendre l’application et de trouver d’éventuelles fuites d’information.

== Comment Tester ==

Les commentaires HTML sont souvent utilisés par les programmeurs pour déboguer une application. Parfois, ils oublient ces commentaires et les laissent en exploitation. Les testeurs doivent rechercher les commentaires HTML qui commencent par "".

=== Test en Boite Noire ===

Rechercher, dans le code source HTML, les commentaires contenant des informations sensibles qui pourraient aider l’attaquant à mieux comprendre l’application. Cela peut être du code SQL, des identifiants et des mots de passe, des adresses IP internes ou des informations de débogage.
...
<pre>
<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

Le testeur peut même trouver des informations telles que :

<pre>

</pre>

Vérifier la version HTML et les URLs de Définition de Type de Document (DTD) pour connaître les versions applicables :
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents
</pre>

Certaines balises META ne fournissent pas de vecteur d’attaque active mais peuvent permettre à un attaquant d’obtenir des informations à propos de l’application comme, par exemple :
<pre>
<META name="author" content="Andrew Muller">
</pre>
Certaines balises META modifient les entêtes des réponses HTTP comme, par exemple, la balise META http-equiv qui met dans l’entête de la réponse HTTP, la valeur de l’attribut «content».

Ainsi la balise :
<pre>
<META http-equiv="expires" content="Fri, 21 Dec 2012 12:34:56 GMT">
</pre>
générera dans l’entête HTTP de réponse :
<pre>
expires: Fri, 21 Dec 2012 12:34:56 GMT
</pre>
Et la balise suivante :
<pre>
<META http-equiv="cache-control" content="no-cache">
</pre>
génèrera dans l’entête HTTP :
<pre>
cache-control: no-cache
</pre>
Tester si cela peut permettre de réaliser une attaque par injection (par ex. une attaque CRLF). Cela peut aussi aider à déterminer le niveau de fuites de données à partir du cache du navigateur.

Une balise META usuelle, mais non conforme aux lignes directrices sur l'accessibilité des contenus Web(WCAG), est "refresh" :
<pre>
<META http-equiv="refresh" content="15; URL=https://www.owasp.org/index.html">
</pre>
Une utilisation usuelle de la balise META permet de spécifier les mots-clés que le moteur de recherche peut utiliser pour améliorer la qualité des résultats :
<pre>
<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">
</pre>
Bien que la plupart des serveurs web gèrent l’indexation des moteurs de recherche avec le fichier robots.txt, cela peut aussi être géré avec des balises META.
La balise suivante informe les robots de ne pas indexer et de ne pas suivre les liens sur les pages HTML contenant cette balise :
<pre>
<META name="robots" content="none">
</pre>

Les recommandations, élaborées par le consortium international W3C, telles que PICS «plate-forme de sélection du contenu Internet» ou, POWDER «protocole de description des ressources du Web» fournissent une infrastructure d’association des métadonnées avec un contenu Internet.

=== Test en Boite Grise ===

Non applicable.

== Outils ==

* Wget
* Fonction du navigateur "voir le code source"
* Eyeballs
* cURL

== Références ==

[1] http://www.w3.org/PICS/ PICS, plate-forme de sélection du contenu Internet<br>
[2] http://www.w3.org/2009/09/powder-pr.html.fr POWDER, protocole de description des ressources du Web

'''Livres Blancs'''
[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01<br>
[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (pour petits appareils)<br>
[3] http://www.w3.org/TR/html5/ HTML version 5

4.2.5 Revue des commentaires et metadonnees des pages web pour recherche de fuite d'information (OTG-INFO-005)

2015-10-02T08:54:10Z

Vall: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == C’est très courant, et même recommandé, que les programmeurs mettent des commentaires détaillés et des métadonnée..."

{{Template:OWASP Testing Guide v4}}

== Sommaire ==

C’est très courant, et même recommandé, que les programmeurs mettent des commentaires détaillés et des métadonnées dans leur code source. Cependant des commentaires et des métadonnées, dans du code HTML, peuvent révéler des informations internes qui ne devraient pas être accessibles à de potentiels attaquants.
Il faut faire une revue des commentaires et des métadonnées pour déterminer s’il y a des fuites d’information.

== Objectifs du test ==

La revue des commentaires et métadonnées permet de mieux comprendre l’application et de trouver d’éventuelles fuites d’information.

== Comment Tester ==

Les commentaires HTML sont souvent utilisés par les programmeurs pour déboguer une application. Parfois, ils oublient ces commentaires et les laissent en exploitation. Les testeurs doivent rechercher les commentaires HTML qui commencent par "".

=== Test en Boite Noire ===

Rechercher, dans le code source HTML, les commentaires contenant des informations sensibles qui pourraient aider l’attaquant à mieux comprendre l’application. Cela peut être du code SQL, des identifiants et des mots de passe, des adresses IP internes ou des informations de débogage.
...
<pre>
<div class="table2">
<div class="col1">1</div><div class="col2">Mary</div>
<div class="col1">2</div><div class="col2">Peter</div>
<div class="col1">3</div><div class="col2">Joe</div>



</div>
...
</pre>

Le testeur peut même trouver des informations telles que :

<pre>

</pre>

Vérifier la version HTML et les URLs de Définition de Type de Document (DTD) pour connaître les versions applicables :
<pre>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
* "strict.dtd" -- default strict DTD
* "loose.dtd" -- loose DTD
* "frameset.dtd" -- DTD for frameset documents
</pre>

Certaines balises META ne fournissent pas de vecteur d’attaque active mais peuvent permettre à un attaquant d’obtenir des informations à propos de l’application comme, par exemple :

<META name="author" content="Andrew Muller">

Certaines balises META modifient les entêtes des réponses HTTP comme, par exemple, la balise META http-equiv qui met dans l’entête de la réponse HTTP, la valeur de l’attribut «content».

Ainsi la balise :

<META http-equiv="expires" content="Fri, 21 Dec 2012 12:34:56 GMT">

générera dans l’entête HTTP de réponse :

expires: Fri, 21 Dec 2012 12:34:56 GMT

Et la balise suivante :

<META http-equiv="cache-control" content="no-cache">

génèrera dans l’entête HTTP :

cache-control: no-cache

Tester si cela peut permettre de réaliser une attaque par injection (par ex. une attaque CRLF). Cela peut aussi aider à déterminer le niveau de fuites de données à partir du cache du navigateur.

Une balise META usuelle, mais non conforme aux lignes directrices sur l'accessibilité des contenus Web(WCAG), est "refresh" :

<META http-equiv="refresh" content="15; URL=https://www.owasp.org/index.html">

Une utilisation usuelle de la balise META permet de spécifier les mots-clés que le moteur de recherche peut utiliser pour améliorer la qualité des résultats :

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

Bien que la plupart des serveurs web gèrent l’indexation des moteurs de recherche avec le fichier robots.txt, cela peut aussi être géré avec des balises META.
La balise suivante informe les robots de ne pas indexer et de ne pas suivre les liens sur les pages HTML contenant cette balise :

<META name="robots" content="none">

Les recommandations, élaborées par le consortium international W3C, telles que PICS «plate-forme de sélection du contenu Internet» ou, POWDER «protocole de description des ressources du Web» fournissent une infrastructure d’association des métadonnées avec un contenu Internet.

=== Test en Boite Grise ===

Non applicable.

== Outils ==

* Wget
* Fonction du navigateur "voir le code source"
* Eyeballs
* cURL

== Références ==

[1] http://www.w3.org/PICS/ PICS, plate-forme de sélection du contenu Internet
[2] http://www.w3.org/2009/09/powder-pr.html.fr POWDER, protocole de description des ressources du Web

'''Livres Blancs'''
[1] http://www.w3.org/TR/1999/REC-html401-19991224 HTML version 4.01
[2] http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/ XHTML (pour petits appareils)
[3] http://www.w3.org/TR/html5/ HTML version 5

User:Vall

2015-10-02T08:53:32Z

Vall:

4.3.6 Test des Methodes HTTP (OTG-CONFIG-006)

2015-10-01T20:40:54Z

Vall: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == HTTP propose plusieurs méthodes pour réaliser des actions sur le serveur web. Plusieurs de ces méthodes sont prévues po..."

{{Template:OWASP Testing Guide v4}}

== Sommaire ==
HTTP propose plusieurs méthodes pour réaliser des actions sur le serveur web. Plusieurs de ces méthodes sont prévues pour aider le développeur à déployer et à tester les applications HTTP. Si le serveur est mal configuré, ces méthodes HTTP peuvent être utilisées dans des buts malveillants. On examinera aussi le Cross Site Tracing (XST), une sorte d’attaque de type Cross Site Scripting (XSS) qui utilise la méthode HTTP TRACE.<br>
Bien que GET et POST soient, de loin, les méthodes les plus employées pour accéder aux informations des serveurs web, HTTP en permet plusieurs autres moins connues. La version HTTP/1.1, qui est le standard actuel, est décrite par le RFC 2616 (ou, les RFC 723x depuis 2014).
En particulier, le RFC 7231 décrit les huit méthodes suivantes :
* GET
* HEAD
* POST
* PUT
* DELETE
* CONNECT
* OPTIONS
* TRACE

Certaines de ces méthodes présentent des risques pour les applications web car elles permettent à un attaquant de modifier des fichiers stockés sur le serveur web et, dans certains scénarios, de voler des justificatifs d’accès d’utilisateurs légitimes. En particulier, les méthodes, qui devraient être désactivées, sont les suivantes :
* PUT: Cette méthode permet à un client de charger un nouveau fichier sur le serveur web. Un attaquant peut l’exploiter pour charger du contenu malveillant (ex. un fichier .asp qui exécute une commande en lançant cmd.exe) ou, simplement en utilisant le serveur de la victime comme un dépôt de fichiers.
* DELETE: Cette méthode permet à un client de supprimer un fichier sur le serveur web. Un attaquant peut l’exploiter comme moyen simple et direct pour défigurer un site web ou concevoir une attaque de Déni de Service-DoS.
* CONNECT: Cette méthode peut permettre à un client d’utiliser un serveur web comme proxy.
* TRACE: Cette méthode renvoie en écho au client toute chaîne qui a été envoyée au serveur et est utilisée principalement pour du débogage. Cette méthode, supposée à l’origine être inoffensive, peut être utilisée pour préparer une attaque de type “Cross Site Tracing”, attaque découverte par Jeremiah Grossman (voir le lien en bas de page).<br>

Si une application a besoin d’au moins une de ces méthodes, comme les services Web REST (qui peuvent nécessiter PUT ou DELETE), il est important de vérifier que l’utilisation qui en est faite est correctement limitée à des utilisateurs approuvés et effectuée dans un environnement sûr.

=== Méthodes HTTP arbitraires ===
Arshan Dabirsiaghi (voir les liens) a découvert que beaucoup de frameworks d’applications web permettent d’utiliser des méthodes HTTP ciblées ou arbitraires pour contourner l’environnement de vérification de contrôle d’accès :
* Beaucoup de frameworks et de langages gèrent la méthode "HEAD" comme une requête "GET", bien que la réponse à la requête "HEAD" ne devrait pas contenir de corps de message. Ainsi, si on a mis en place une contrainte de sécurité sur les requêtes "GET" telle que, seuls les utilisateurs authentifiés peuvent accéder à une servlet ou à une ressource particulière, cette contrainte sera contournée dans l’appel à la méthode "HEAD". Cela permet, à l’aveugle et sans autorisation, d’accéder à toute requête "GET" privilégiée.
* Certains frameworks autorisent que des méthodes HTTP arbitraires telles que "JEFF" ou "CATS" soient utilisées sans aucune limitation. Celles-ci sont traitées comme des méthodes "GET" et se trouvent, dans certains langages et frameworks, ne pas être soumises aux vérifications d’accès fondées sur les rôles des méthodes standard, permettant, une fois encore, un accès, à l’aveugle et sans autorisation, à des ressources "GET" privilégiées.
Dans bien des cas, le code qui vérifiera explicitement que la méthode est un "GET" ou un "POST", sera sûr.

== Comment Tester ==
'''Découvrir les Méthodes Supportées'''<br>
Pour réaliser ce test, le testeur devra savoir quelles méthodes HTTP sont supportées par le serveur à évaluer. La méthode HTTP "OPTIONS" donne au testeur un moyen direct et efficace pour le faire. Le RFC 2616 indique ainsi que «La méthode "OPTIONS" est une demande d’information sur les options de communications supportées dans la séquence des requêtes/réponses déterminées par l’URI de la requête.»
La méthode de test est très simple et une commande netcat (ou telnet) suffit :
<pre>
$ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

</pre>

Comme on peut le voir dans cet exemple, OPTIONS renvoie la liste des méthodes supportées par le serveur web, et on remarque ici que la méthode "TRACE" est activée. Le danger, que cela représente, est illustré dans la section suivante.<br><br>

'''Test de vulnérabilité XST'''<br>
Note: pour bien comprendre la logique et le but de l’attaque XST, il faut être familier des attaques de type Cross Site Scripting (XSS).
La méthode "TRACE", apparemment inoffensive, peut être utilisée dans certains scénarios pour voler des justificatifs d’accès d’utilisateurs légitimes. Cette technique d’attaque a été découverte par Jeremiah Grossman en 2003, dans une tentative de contournement de la balise HTTPOnly que Microsoft a introduite dans Internet Explorer 6 SP1 pour empêcher Javascript d’accéder aux cookies. En effet, l’un des motifs récurrents d’attaques de type XSS (Cross Site Scripting) concerne l’accès à l’objet document.cookie qui est renvoyé à un serveur web contrôlé par l’attaquant pour qu’il puisse détourner la session de la victime. Marquer un cookie avec l’attribut HTTPOnly interdit à Javascript d’y accéder, le protégeant ainsi d’un envoi à une partie tierce. Malgré cela, même dans ce cas, la méthode "TRACE" peut être utilisée pour contourner cette protection et accéder aux cookies.
Comme indiqué précédemment, TRACE renvoie simplement chaque chaîne de caractères envoyée au serveur web. Pour vérifier sa présence sur le serveur (ou confirmer les résultats de la requête OPTIONS précédente), le testeur peut effectuer la commande suivante :
<pre>
$ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>

Le corps de la réponse est une copie exacte de notre requête initiale, ce qui signifie que la cible accepte la méthode "TRACE". Alors, où se cache le danger ? Si le testeur indique au navigateur d’envoyer une requête TRACE au serveur web et si le navigateur a un cookie pour ce domaine, ce cookie sera automatiquement inclus dans les entêtes de requêtes et donc renvoyé en écho dans la réponse.
A partir de là, la chaîne représentant le cookie sera accessible par JavaScript et, il sera finalement possible de l’envoyer à une partie tierce, même s’il a l’attribut HTTPOnly.

Il y a différents moyens pour qu’un navigateur envoie une requête "TRACE", en particulier, il y a le contrôle ActiveX XMLHttpRequest dans Internet Explorer et XMLDOM dans Mozilla. Quoiqu’il en soit, pour des raisons de sécurité, le navigateur ne peut initier une connexion que sur le domaine où se trouve le script malveillant. C’est un facteur qui en limite les possibilités car l’attaquant devra combiner la méthode "TRACE" avec une autre vulnérabilité pour réaliser cette attaque.
Un attaquant a deux moyens de réussir une attaque de type Cross Site Tracing :
* Profiter d’une autre vulnérabilité du serveur : l’attaquant injecte un code JavaScript malveillant, qui contient une requête "TRACE", dans l’application vulnérable comme pour une attaque standard de type XSS-Cross Site Scripting
* Profiter d’une autre vulnérabilité du client : l’attaquant crée un site web malveillant qui contient le code JavaScript hostile et exploite une vulnérabilité inter-domaine du navigateur de la victime, de façon à ce que le code JavaScript réalise avec succès une connexion au site qui supporte la méthode "TRACE" et qui a généré le cookie que l’attaquant convoite.

Vous pourrez trouver plus d’informations, ainsi que des exemples de code, dans le document original de Jeremiah Grossman.

Note du traducteur : Depuis la divulgation de cette attaque, les navigateurs récents stoppent les requêtes "TRACE" effectuées via Javascript.

=== Test des Méthodes HTTP arbitraires ===
Chercher une page, avec une contrainte de sécurité qui devrait normalement conduire à une redirection "302" vers une page de connexion, ou à une connexion directe. L’URL de test de l’exemple fonctionne ainsi, comme beaucoup d’applications web.
Néanmoins, si le testeur reçoit une réponse "200" qui n’est pas une page de connexion, il est possible de contourner l’authentification et donc les autorisations d’accès :
$ nc www.example.com 80
<pre>
JEFF / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...

</pre>

Si le framework, le pare-feu ou l’application ne prend pas en compte pas la méthode "JEFF", il devrait envoyer une page d’erreur (ou, mieux une page d’erreur indiquant "405 Not Allowed" ou "501 Not implemented"). S’il effectue la requête, il est vulnérable à ce problème.
Si le testeur pense que le système est vulnérable à ce problème, il doit tenter une attaque de type CSRF (Falsification de requête intersites) pour l’exploiter au maximum :
* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

Avec de la chance, en utilisant les trois commandes ci-dessus, -modifiées pour s’adapter à l’application et aux besoins du test- un nouvel utilisateur sera créé avec un mot de passe choisi et des droits administrateur.

=== Test de Contournement du contrôle d’accès de la requête HEAD ===
Chercher une page, avec une contrainte de sécurité qui devrait normalement conduire à une redirection "302" vers une page de connexion, ou à une connexion directe. L’URL de test de l’exemple fonctionne ainsi, comme beaucoup d’applications web.
Néanmoins, si le testeur reçoit une réponse "200" qui n’est pas une page de connexion, il est possible de contourner l’authentification et donc les autorisations d’accès :
<pre>
$ nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1
</pre>

Si le testeur reçoit un "405 Method not allowed" ou un "501 Method Unimplemented", la cible (application / framework / langage / système / parefeu) fonctionne correctement.
S’il reçoit un "200" en retour, et que la réponse ne contient pas de corps de message, c’est que l’application a accepté la requête sans effectuer de contrôle d’authentification et d’autorisation ce qui garantit de pouvoir effectuer des tests complémentaires.

Si le testeur pense que le système est vulnérable à ce problème, il doit tenter une attaque de type CSRF (falsification de requête intersites) pour l’exploiter au maximum :
* FOOBAR /admin/createUser.php?member=myAdmin
* JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
* CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

Avec de la chance, en utilisant les trois commandes ci-dessus, -modifiées pour s’adapter à l’application et aux besoins du test- un nouvel utilisateur sera créé avec un mot de passe choisi et des droits administrateur, tout cela avec la soumission de requêtes à l’aveugle.

== Outils ==
* NetCat - http://nc110.sourceforge.net
* cURL - http://curl.haxx.se/

== References ==
'''Livres Blancs'''<br>
* Le RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1"
* Les RFC 2109 et RFC 2965 "HTTP State Management Mechanism"
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
* Amit Klein: "une variante d’attaque XS(T) qui peut permettre, dans certains cas, de se passer de TRACE" - http://www.securityfocus.com/archive/107/308433
* Arshan Dabirsiaghi: "Contourner VBAAC avec HTTP Verb Tampering" - http://static.swpag.info/download/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

User:Vall

2015-10-01T20:39:36Z

Vall:

User:Vall

2015-10-01T09:24:46Z

Vall: