2.1 CVE-2012-1004

XSS

 

Plusieurs vulnérabilités de type cross-site scripting (XSS) dans UI/Register.pm dans Foswiki avant 1.1.5 permettent à des utilisateurs authentifiés distants disposant des privilèges CHANGE d'injecter un script web ou un HTML arbitraire via le paramètre (1) text, (2) FirstName, (3) LastName, (4) OrganisationName, (5) OrganisationUrl, (6) Profession, (7) Country, (8) State, (9) Address, (10) Location, (11) Telephone, (12) VoIP, (13) InstantMessagingIM, (14) Email, (15) HomePage, ou (16) Comment. NOTE : certains de ces détails sont obtenus à partir d'informations provenant de tiers.
https://nvd.nist.gov/vuln/detail/CVE-2012-1004

Catégories

CWE-79 : Neutralisation incorrecte des entrées lors de la génération de pages Web ("Cross-site Scripting")
Le logiciel ne neutralise pas ou neutralise de manière incorrecte les entrées contrôlables par l'utilisateur avant qu'elles ne soient placées dans une sortie utilisée comme une page Web qui est servie à d'autres utilisateurs. "XSS" est une abréviation courante pour Cross-Site Scripting. Le terme "injection HTML" est utilisé comme synonyme de XSS stocké (type 2). Dans les premières années qui ont suivi la découverte du XSS, l'acronyme "CSS" était couramment utilisé. Cependant, comme il y avait confusion avec "Cascading Style Sheets", l'utilisation de cet acronyme a considérablement diminué. Utilisez des outils d'analyse statique automatisés qui ciblent ce type de faiblesse. De nombreuses techniques modernes utilisent l'analyse du flux de données pour minimiser le nombre de faux positifs. Il ne s'agit pas d'une solution parfaite, car une précision et une couverture à 100 % ne sont pas réalisables, en particulier lorsque plusieurs composants sont impliqués. Utilisez le XSS Cheat Sheet [REF-714] ou des outils de génération de tests automatisés pour lancer une grande variété d'attaques contre votre application Web. L'antisèche contient de nombreuses variations XSS subtiles qui visent spécifiquement les défenses XSS faibles. Comprenez toutes les zones potentielles où des entrées non fiables peuvent pénétrer dans votre logiciel : paramètres ou arguments, cookies, tout ce qui est lu sur le réseau, variables d'environnement, recherches DNS inversées, résultats de requêtes, en-têtes de requêtes, composants URL, courrier électronique, fichiers, noms de fichiers, bases de données et tout système externe fournissant des données à l'application. N'oubliez pas que ces entrées peuvent être obtenues indirectement par des appels d'API. Pour tous les contrôles de sécurité effectués côté client, assurez-vous que ces contrôles sont dupliqués côté serveur, afin d'éviter le CWE-602. Les attaquants peuvent contourner les contrôles côté client en modifiant les valeurs après l'exécution des contrôles, ou en modifiant le client pour supprimer complètement les contrôles côté client. Ces valeurs modifiées seraient alors soumises au serveur. Si possible, utilisez des mécanismes structurés qui renforcent automatiquement la séparation entre les données et le code. Ces mécanismes peuvent être en mesure de fournir automatiquement les citations, l'encodage et la validation nécessaires, au lieu de demander au développeur de fournir cette capacité à chaque point où une sortie est générée. Avec Struts, écrivez toutes les données des form beans avec l'attribut filter du bean défini sur true. Pour limiter les attaques XSS contre le cookie de session de l'utilisateur, réglez le cookie de session sur HttpOnly. Dans les navigateurs qui prennent en charge la fonction HttpOnly (comme les versions les plus récentes d'Internet Explorer et de Firefox), cet attribut peut empêcher le cookie de session de l'utilisateur d'être accessible aux scripts malveillants côté client qui utilisent document.cookie. Il ne s'agit pas d'une solution complète, car HttpOnly n'est pas pris en charge par tous les navigateurs. Plus important encore, XMLHTTPRequest et d'autres technologies de navigateur puissantes fournissent un accès en lecture aux en-têtes HTTP, y compris l'en-tête Set-Cookie dans lequel le drapeau HttpOnly est activé. Lorsque l'ensemble des objets acceptables, tels que les noms de fichiers ou les URL, est limité ou connu, créez une correspondance entre un ensemble de valeurs d'entrée fixes (telles que des identifiants numériques) et les noms de fichiers ou les URL réels, et rejetez toutes les autres entrées. Utilisez un pare-feu applicatif capable de détecter les attaques contre cette faiblesse. Cela peut être utile dans les cas où le code ne peut pas être corrigé (parce qu'il est contrôlé par un tiers), comme mesure de prévention d'urgence pendant que des mesures d'assurance logicielle plus complètes sont appliquées, ou pour fournir une défense en profondeur. Si vous utilisez PHP, configurez l'application de manière à ce qu'elle n'utilise pas register_globals. Lors de l'implémentation, développez l'application de manière à ce qu'elle ne dépende pas de cette fonctionnalité, mais méfiez-vous de l'implémentation d'une émulation register_globals qui est sujette à des faiblesses telles que CWE-95, CWE-621, et d'autres problèmes similaires. Python Library Manager ne neutralise pas suffisamment un terme de recherche fourni par l'utilisateur, ce qui permet un XSS réfléchi. La plateforme de commerce électronique basée sur Python n'échappe pas le contenu renvoyé dans les pages d'erreur, ce qui permet des attaques par Cross-Site Scripting réfléchies. XSS universel dans le système d'exploitation mobile, tel qu'exploité dans la nature par CISA KEV. Chaîne : une validation d'entrée incorrecte (CWE-20) dans un produit pare-feu entraîne un XSS (CWE-79), exploité dans la nature par CISA KEV. L'interface graphique d'administration permet XSS par le biais d'un cookie. Le programme de statistiques Web permet XSS par le biais d'un en-tête HTTP modifié. Le produit d'analyse des journaux Web permet le XSS par le biais d'un en-tête HTTP Referer modifié. Chaîne : défaillance du mécanisme de protection autorisant XSS Chaîne : liste de dénombrement incomplète (CWE-184) vérifiant uniquement la balise "javascript:", autorisant XSS (CWE-79) à l'aide d'autres balises Chaîne : liste de dénombrement incomplète (CWE-184) supprimant uniquement les balises SCRIPT, autorisant XSS (CWE-79) XSS réfléchi utilisant PATH_INFO dans une URL XSS réfléchi non traité correctement lors de la génération d'un message d'erreur XSS réfléchi envoyé par e-mail. XSS stocké dans un produit de sécurité. XSS stocké en utilisant une page wiki. Stockage de XSS dans une application de livre d'or. Stockage de XSS dans une application de livre d'or utilisant un javascript : URI dans une balise bbcode img. Chaîne : le fichier de la bibliothèque n'est pas protégé contre une requête directe (CWE-425), ce qui entraîne un XSS réfléchi (CWE-79).

Références


 

CPE

cpe start end
Configuration 1
cpe:2.3:a:foswiki:foswiki:1.1.0:*:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.1:*:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.2:*:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.3:*:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.4:*:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.4:beta:*:*:*:*:*:*
cpe:2.3:a:foswiki:foswiki:1.1.4:rc:*:*:*:*:*:*

Exploits

id description date
Pas d'exploit connu

CAPEC

id description sévérité
591 XSS réfléchi
Très haute
592 XSS stocké
Très haute
85 Empreinte d'AJAX
Faible
63 Cross-Site Scripting (XSS)
Très haute
209 XSS Using MIME Type Mismatch
Moyenne
588 DOM-Based XSS
Très haute

Sherlock® flash

Prenez une photo de votre réseau informatique en quelques clics !

La solution d'audit Sherlock® flash vous permet de réaliser un audit pour renforcer la sécurité de votre parc informatique. Analyse des vulnérabilités de vos équipements physiques et virtuels. Planification des correctifs par niveau de priorité et temps disponible. Rapports détaillés et intuitifs.

Découvrir cette offre

Sherlock® flash : 1ère solution d'audit de cybersécurité instantané