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.

Stockée ou pas ?

On pourrait se dire que le stockage ne change pas grand chose à la nature de la faille. Pourtant, la différence est loin d’être anodine : dans une XSS réfléchie, il faut obliger l’utilisateur a utilisé une URL particulière contenant du script malveillant. Dans une XSS permanente, le script est stocké au niveau du site web et sera rejouée même si l’utilisateur ne parcourt que des URL légitimes, bien formées et exemptes de tout code malveillant. Le ver sera dans le fruit.

Contre-mesures

Filtrage et encodage (échappement) sont encore une fois nos meilleurs amis. Cela doit s’appliquer en entrée, afin qu’en base on ne stocke pas de code malveillant exécutable, mais je conseillerai aussi de filtrer en sortie dans le cas où un attaquant aurait un accès à la base de données ou au système de fichiers. Il faut aussi (en permanence) penser à protéger ses cookies. Pour le framework Django, l’emploi de safe est donc fortement déconseillé puisqu’il indique que le champ concerné est sûr et n’a pas besoin d’être échappé.

Liens utiles

  • OWASP
  • CWE

Voir aussi

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *