A première vue, cela ressemble énormément à du reflected XSS (XSS non persistent). Pourtant il y a une différence de taille : l’action se déroule uniquement au niveau du navigateur, alors que pour du XSS réfléchi ou stocké la vulnérabilité se situe directement au niveau du serveur web.
Continuer la lectureArchives par étiquette : XSS
Stored XSS
Ou persistent XSS en anglais, et XSS stocké ou permanent en français. Cette faille de la famille des XSS (cross site scripting) se différencie d’une XSS réfléchie par le fait qu’elle soit stockée. D’où son nom. Logique.
Continuer la lectureReflected XSS
On dit aussi XSS réfléchi en français, mais la terminologie anglaise prévaut souvent en ce qui concerne la SSI. Une faille XSS non permanente consiste à faire utiliser une URL contenant du script malveillant. Pour cela, il faut communiquer à un utilisateur cette URL pour qu’il clique dessus, par exemple. Rien n’est stocké sur le site web ciblé, à l’inverse d’une stored XSS.
Les champs HTML de recherche sont de bons candidats pour ce genre de faille, car ils doivent souvent laisser passer des caractères variés (par exemple en langage naturel). Comme le contenu d’un tel champ doit être passé ensuite dans une requête GET ou POST, l’absence de contrôle approprié sera forcément dommageable.
Continuer la lectureAttaques XML
XML, comme toute technologie informatique, est potentiellement utilisable de façon détournée par de méchants pirates. Autrement dit, XML est attaquable. Certaines attaques sont relativement communes, d’autres sont plus spécifiques à la technologie elle-même.
Attaques XXE
Une attaque XXE consiste à utiliser le mécanisme XML External Entities qui permet de charger, dans un document XML, des données externes.
Principe
Il suffit donc ensuite que le serveur qui traite le fichier XML ait les droits sur la ressource demandées pour qu’il la récupère. Imaginons que le serveur soit installé sur une instance AWS : on peut très bien mettre, dans l’entité externe à charger, une URL du type //169.254.169.254/latest/meta-data/iam/security-credentials/role/
qui contient les informations d’authentification pour le rôle concerné.
<!DOCTYPE doctype [
<!ENTITY myentity SYSTEM "https://169.254.169.254/latest/meta-data/iam/security-credentials/role/"> ]>
<sell>
...
<product>
<name>Product Name</name>
<price>100.00</price>
<description>&myentity;</description>
</product>
...
</sell>
On récupère alors une réponse :
{ "Code" : "Success",
"LastUpdated" : "2018-02-06T15:12:30Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAJQAPNMGMDOUJ5LGQ",
"SecretAccessKey" : "/jOIiFX...............eNBe0SigqvngXkXsMP",
"Token" : "FQoDYXdzEKj//////////wEaDNzLiriTguzdpCK9A1/LsuWyHIqk...............7LLNrtnR2Sdy/VdfFjuLjzGw...............",
"Expiration" : "2018-02-06T21:29:09Z" }
Contre-mesure
Ce risque est inhérent à l’utilisation de ce mécanisme, et le seul moyen efficace de s’en prémunir est… de l’interdire ! Hélas, chaque parseur XML a son propre paramétrage et il va falloir chercher dans la doc correspondante comment procéder. Pour Python/Django, cela peut donner :
from lxml import etree
parser = etree.XMLParser(resolve_entities=False)
Attaques XPath
L’attaque XPath est plus classique car elle est liée à l’éternel problème du contrôle des données entrées dans un système informatique.
Le principe est le même que celui d’une injection SQL, où on force, via des caractères spéciaux, une modification de la logique de la requête SQL générée avec l’entrée saisie par l’utilisateur. Ici, on modifie la logique du code ou de la requête SQL grâce à des caractères spéciaux introduits dans un champ XML.
Exemple : //coupon[code='ABCD' or '*']
Rien de bien nouveau, à part qu’il faut aussi penser à vérifier systématiquement ses documents XML, comme toute entrée (saisie) d’un utilisateur, notamment en échappant les caractères.
Attaques XSS
Les attaques XSS sur XML sont classiques et le principe est celui des XSS : on force un utilisateur à exécuter un script contenu dans le document XML.
Contre-mesures
Il y a deux façons de contrer ces attaques, qu’on peut combiner :
- Filtrer les données du document XML, en échappant les caractères et/ou interdisant certains motifs (patterns) suspects ;
- Empêcher l’exécution du script en modifiant le header de la réponse au niveau du serveur, en forçant le téléchargement du fichier.
Attaques XSS via un fichier SVG
SVG est un format d’image basé sur XML. Il est possible d’y inclure des scripts, ce qui le rend vulnérable aux attaques XSS comme vu juste au-dessus. Le principe est donc identique, à part que le script est désormais caché dans une image SVG qu’un attaquant cherchera à placer dans le site de sa cible.
Contre-mesures
Là où c’est un peu plus sioux, c’est qu’on peut effectivement faire la même chose que pour les attaques XSS. Mais si le fichier SVG doit être affiché sur une page web, il va être difficile (du point de vue ergonomie) de forcer l’image à être téléchargée ! Cela veut donc dire qu’il va falloir traiter très consciencieusement tout ficher SVG destiné à être affiché…