Discussion :

[fredoche]

Salut

Ca tiendrait presque du message personnel à Imikado, mais je crois que ça vaut l'intervention d'autres personnes savantes, étant donné que je n'ai pas la science infuse.

Imikado, je te lisais sur windows 10 et ubuntu, je vois ta signature, je vois ce mot sécurisé souligné et donc hyperlié, je suis le lien, et je lis :

Le xss consistant à utiliser un paramètre (GET/POST...) pour modifier le site, le framework propose d'utiliser la méthode _root::getParam() à la place des variables globales $_GET/$_POST
Le contenu retourné par _root::getParam() filtre les entrées des attaques XSS mais également des attaques de type null byte

Ne connaissant pas cette méthode qui doit faire partie de ton framework Imikado, je cherche un peu et je lis :

Ici, le framework propose de ne pas utiliser les variables d'environnement $_GET et $_POST, mais plutôt la méthode publique statique _root::getParam().

Cette méthode sécurise la chaîne des attaques XSS et null byte.

Les valeurs soumises par les internautes sont également encodées en HTML, quotes comprises, à chaque affichage de la donnée.

Pour information, il y a deux méthodes de sécurisation :

vérifier les chaînes en entrées, et les protéger systématiquement à l'affichage (partout dans le site) ;
convertir les chaînes en HTML sécurisé et les enregistrer converties pour ne pas se soucier des erreurs à l'affichage.

Le framework utilise la seconde, c'est certes une méthode radicale mais elle a fait ses preuves, contrairement à la première. Elle évite d'avoir des failles de sécurité, car un développeur a oublié de sécuriser une chaîne à l'affichage (dans la page et/ou dans un champ de formulaire ) sur la première.

Alors pour moi soyons clair la seconde méthode n'a rien prouvé.
Il existe une 3e voie, probablement la seule valide à l'heure actuelle : c'est d'encoder systématiquement à l'usage et selon le contexte d'usage des données qui ont été transmises à un moment donné.

Je vais pas refaire la leçon, tout est dit ici :
https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet


Aucune prétention sur le sujet, sauf que j'ai eu à protéger entièrement une application web que je développe depuis des années pour le compte d'une institution des jeux, basée sur de l'ASP classic, avec audit de sécurité avant/après. Travailler sur le XSS a été ma plus grosse tache, relecture de tout le code pour encodage systématique en fonction du contexte.

Stocker des données déjà encodées ne sert à rien car on ne peut pas présumer de leur contexte d'usage.

Imikado, tel que tu présentes les choses, tu donnes à tes utilisateurs un sentiment de confiance que de toute façon tu ne devrais jamais donner, quand bien même tu serais très sur de toi. Tu dois inciter les gens qui utilisent ton framework à ne pas être de simples consommateurs, je crois...

Il faudrait strictement encoder en fonction du contexte : HTML pour HTML JS escape pour du javascript, URL escape et ainsi de suite...

Et c'est en toute sympathie que je t'écris cela Imikado, car j'ai réellement plaisir à te lire quand j'en ai l'occasion ;-) Aucune volonté de créer polémique, je te challenge sur cette prétention à être sécurisé.

Quand j'aurais un peu de temps je regarderais ce que tu fais pour le reste des menaces, que j'ai eu à traiter bien sur.

Une grille de test des injections XSS : https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet

PS: as tu essayé des outils automatisés de test/pénétration sur ton framework ? as tu sollicité des gens qui maitrisent ces techniques de hack/crack ?

[imikado]

Bonjour,
Oui, votre remarque est pertinente: on sécurise vis à vis d'un contexte, et par défaut ce framework est sécurisé pour le web, d'ou le choix du htmlentities

Et oui pour information, de nombreuses applications utilisant ce framework ont subit des tests d’intrusion/audit de sécurité avec succès.
Pour information, je travaille depuis des années dans un contexte professionnelle où nos applications "publiques" sont systématiquement testés par des cabinet externe.
Avant nous utilisions d'autres frameworks qui ne passaient pas ces tests d'intrusions

C'est d'ailleurs au fil de ces rapports que j'ai pu amélioré/corrigé le framework en conséquence