2.1 CVE-2011-5188
La vulnérabilité de script intersite (XSS) dans le module Support Timer 6.x-1.x avant 6.x-1.4 pour Drupal permet aux utilisateurs authentifiés distants avec la permission "track time spent" d'injecter un script web arbitraire ou du HTML via des vecteurs non spécifiés.
https://nvd.nist.gov/vuln/detail/CVE-2011-5188
Catégories
CWE-79 : Neutralisation incorrecte des entrées lors de la génération de pages Web ("Cross-site Scripting")
Le produit 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. Abréviation courante de Cross-Site Scripting. Utilisé comme synonyme de XSS stocké (type 2). Dans les premières années qui ont suivi la découverte du XSS, "CSS" était un acronyme 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 l'indicateur 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 ID 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. Lorsque 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 de 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), tel qu'exploité dans la nature par CISA KEV. L'interface graphique de l'administrateur 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
CONFIRM Patch
OSVDB
SECUNIA
XF
CPE
| cpe |
start |
end |
| Configuration 1 |
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.0:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.0:beta1:*:*:*:*:*:* |
|
|
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.1:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.2:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.3:*:*:*:*:*:*:* |
|
|
| cpe:2.3:a:tag1consulting:support_timer:6.x-1.x:dev:*:*:*:*:*:* |
|
|
| Running on/with |
| cpe:2.3:a:drupal:drupal:-:*:*:*:*:*:*:* |
|
|
REMEDIATION
Patch
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| Pas d'exploit connu |
Autres (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
sévérité |
| 209 |
XSS Using MIME Type Mismatch
Un adversaire crée un fichier contenant des scripts mais dont le type MIME spécifié est tel que les scripts ne sont pas attendus. L'adversaire incite la victime à accéder à une URL qui répond avec le fichier de script. Certains navigateurs détectent que le type MIME spécifié du fichier ne correspond pas au type réel de son contenu et passent automatiquement à l'utilisation d'un interpréteur pour le type de contenu réel. Si le navigateur n'invoque pas de filtres de script avant de faire cela, le script de l'adversaire peut s'exécuter sur la cible sans être nettoyé, révélant éventuellement les cookies de la victime ou exécutant un script arbitraire dans son navigateur. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire suit tous les liens et actions publics sur un site Web. Il enregistre toutes les zones qui permettent à un utilisateur de télécharger du contenu via une requête HTTP POST. Cela se trouve généralement dans les blogs ou les forums. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et télécharge des fichiers avec du contenu de script, mais dont le type MIME est spécifié comme un type de fichier qui ne peut pas exécuter de contenu de script. Si l'application vérifie uniquement le type MIME du fichier, elle peut laisser passer le fichier, ce qui entraîne l'exécution du script par tout utilisateur qui accède au fichier. [Une fois que l'adversaire a déterminé quels emplacements de téléchargement de fichiers sont vulnérables à la non-concordance des types MIME, il télécharge un script malveillant déguisé en fichier sans script. L'adversaire peut avoir de nombreux objectifs, depuis le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page d'une victime. [Pour que l'attaque réussisse, la victime doit voir le contenu malveillant stocké sur la page Web. |
Moyenne |
| 588 |
DOM-Based XSS
Ce type d'attaque est une forme de Cross-Site Scripting (XSS) où un script malveillant est inséré dans le HTML côté client analysé par un navigateur web. Le contenu servi par une application web vulnérable comprend du code script utilisé pour manipuler le Document Object Model (DOM). Ce code script ne valide pas correctement les données d'entrée ou n'effectue pas un codage de sortie correct, ce qui permet à un adversaire d'injecter un script malveillant et de lancer une attaque XSS. Une distinction essentielle entre les autres attaques XSS et les attaques basées sur le DOM est que dans les autres attaques XSS, le script malveillant s'exécute lorsque la page Web vulnérable est initialement chargée, alors que l'attaque basée sur le DOM s'exécute quelque temps après le chargement de la page. Une autre distinction des attaques basées sur le DOM est que dans certains cas, le script malveillant n'est jamais envoyé au serveur web vulnérable. Une telle attaque est garantie pour contourner toute tentative de filtrage côté serveur pour protéger les utilisateurs. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme une liste de cibles et injecte diverses charges utiles de script courantes et des caractères spéciaux pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser la mesure dans laquelle la vulnérabilité peut être exploitée. En ce qui concerne le XSS basé sur le DOM, l'adversaire recherche des zones où l'entrée est utilisée pour modifier directement le DOM. [Une fois que l'adversaire a déterminé quels paramètres sont vulnérables au XSS, il crée une URL malveillante contenant l'exploit XSS. L'adversaire peut avoir de nombreux objectifs, comme le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page de la victime. Dans le cas d'un XSS basé sur le DOM, le script malveillant peut même ne pas être envoyé au serveur, puisque le navigateur de la victime manipule lui-même le DOM. Cela peut permettre d'éviter les mécanismes de détection côté serveur. [Faire en sorte que la victime clique sur l'URL] Pour que l'attaque réussisse, la victime doit accéder à l'URL malveillante. |
Très haute |
| 591 |
XSS réfléchi
Ce type d'attaque est une forme de Cross-Site Scripting (XSS) où un script malveillant est "réfléchi" à partir d'une application web vulnérable et ensuite exécuté par le navigateur de la victime. Le processus commence par l'envoi par un adversaire d'un script malveillant à une victime et par la persuasion de cette dernière d'envoyer le script à l'application web vulnérable. [À l'aide d'un navigateur ou d'un outil automatisé, un adversaire suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et injecte divers scripts et caractères spéciaux courants pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser l'étendue de l'exploitation de la vulnérabilité. [Une fois que l'adversaire a déterminé quels paramètres sont vulnérables au XSS, il crée une URL malveillante contenant l'exploit XSS. L'adversaire peut avoir de nombreux objectifs, comme le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page de la victime. [Pour que l'attaque réussisse, la victime doit accéder à l'URL malveillante. |
Très haute |
| 592 |
XSS stocké
Un adversaire utilise une forme de Cross-site Scripting (XSS) dans laquelle un script malveillant est "stocké" de manière persistante dans le stockage de données d'une application web vulnérable comme entrée valide. [À l'aide d'un navigateur ou d'un outil automatisé, un pirate suit tous les liens et actions publics sur un site Web. Il enregistre tous les liens, les formulaires, les ressources accessibles et tous les autres points d'entrée potentiels de l'application web. L'adversaire recherche les zones où les entrées des utilisateurs sont stockées, telles que les profils d'utilisateurs, les paniers d'achat, les gestionnaires de fichiers, les forums, les blogs et les journaux. [L'adversaire utilise les points d'entrée recueillis lors de la phase "Explore" comme liste de cibles et injecte diverses charges utiles de script et caractères spéciaux courants pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser l'étendue de l'exploitation de la vulnérabilité. [Stockage de contenu XSS malveillant] Une fois que l'adversaire a déterminé quels emplacements stockés sont vulnérables au XSS, il interagit avec l'application Web pour stocker le contenu malveillant. L'adversaire peut avoir de nombreux objectifs, comme le vol d'identifiants de session, de cookies, d'informations d'identification et de contenu de page d'une victime. [Pour que l'attaque réussisse, la victime doit voir le contenu malveillant stocké sur la page web. |
Très haute |
| 63 |
Cross-Site Scripting (XSS)
Un adversaire incorpore des scripts malveillants dans le contenu qui sera servi aux navigateurs web. L'objectif de l'attaque est que le logiciel cible, le navigateur côté client, exécute le script avec le niveau de privilège des utilisateurs. Une attaque de ce type exploite les vulnérabilités d'un programme en permettant à des hôtes distants d'exécuter du code et des scripts. Les navigateurs Web, par exemple, ont mis en place des contrôles de sécurité simples, mais si un attaquant distant est autorisé à exécuter des scripts (en les injectant dans du contenu généré par l'utilisateur, comme des tableaux d'affichage), ces contrôles peuvent être contournés. En outre, ces attaques sont très difficiles à détecter pour un utilisateur final. [À l'aide d'un navigateur ou d'un outil automatisé, un attaquant suit tous les liens et actions publics sur un site web. Il enregistre tous les liens, les formulaires, les ressources accédées et tous les autres points d'entrée potentiels de l'application web. [L'attaquant utilise les points d'entrée recueillis lors de la phase d'exploration comme une liste de cibles et injecte diverses charges utiles de script courantes pour déterminer si un point d'entrée représente réellement une vulnérabilité et pour caractériser l'étendue de l'exploitation de la vulnérabilité. [Si l'attaquant réussit à exploiter la vulnérabilité, il peut choisir de voler les informations d'identification de l'utilisateur afin de les réutiliser ou de les analyser ultérieurement. [Navigation forcée] Lorsque l'attaquant cible l'application actuelle ou une autre (par le biais de vulnérabilités CSRF), c'est l'utilisateur qui effectue les attaques sans s'en rendre compte. Ces attaques visent principalement les failles de logique applicative, mais elles peuvent également être utilisées pour créer une attaque généralisée contre un site web particulier sur le réseau actuel de l'utilisateur (Internet ou non). [L'usurpation de contenu] En manipulant le contenu, l'attaquant cible les informations que l'utilisateur souhaite obtenir du site web. |
Très haute |
| 85 |
Empreinte d'AJAX
Cette attaque utilise les fréquents allers-retours client-serveur dans les conversations Ajax pour scanner un système. Si Ajax n'ouvre pas de nouvelles vulnérabilités en soi, il les optimise du point de vue de l'attaquant. La première étape habituelle pour un attaquant est de prendre l'empreinte de l'environnement cible pour comprendre quelles attaques fonctionneront. Étant donné que l'empreinte repose sur l'énumération, le modèle conversationnel de demandes et de réponses rapides et multiples qui est typique des applications Ajax permet à un attaquant de rechercher de nombreuses vulnérabilités, des ports connus, des emplacements de réseau, etc. Les connaissances acquises grâce à l'empreinte Ajax peuvent être utilisées pour soutenir d'autres attaques, telles que XSS. [À l'aide d'un navigateur ou d'un outil automatisé, un pirate envoie des requêtes à une page Web et enregistre la réponse HTML reçue. Les adversaires analysent ensuite le HTML pour identifier toute architecture JavaScript sous-jacente connue. Cela peut aider à mettre en correspondance les vulnérabilités connues du public avec la page Web et peut également aider l'adversaire à deviner l'architecture de l'application et le fonctionnement interne d'un système. |
Faible |
MITRE
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
