FusionForge de l'ADULLACT: openMairie - Framework : [#8348] Formulaires: Abandon de la substitution systématique de " par '

Date :
20/06/2016 17:37

Priorité :
3

État :
Closed

Proposé par :
Laurent Groleau (lgroleau)

Confié à :
Nobody (None)

Version cible :
none

Version concernée :
none

Résumé :
Formulaires: Abandon de la substitution systématique de " par '

Description détaillée
Dans ./core/om_formulaire.class.php: -la méthode constructeur formulaire() initialise les champs ainsi: $this->val[$champs[$i]] = strtr($elem, chr(34), "'"); -la méthode recupererPostvar() effectue sur les champs textes des traitements qui semblent initialement prévu pour lutter contre l'injection SQL: Un premier traitement est obsolète depuis PHP 5.4: // Cette fonction a été supprimée avec PHP 5.4.0 et // renvoi toujours la valeur FALSE depuis // @deprecated if (get_magic_quotes_gpc()) { // Supprime les antislashs de la chaîne $value = stripslashes($value); } Un second traitement est d'une utilité douteuse, et perturbe les formulaires (états, lettre-type, sous-état) qui comportent un champ textarea destiné à des requêtes SQL, telle que: SELECT 1 AS "c'est égal à 1"; // On remplace les doubles quotes par des simples quotes ? $value = strtr($value, chr(34), "'"); JE PROPOSE de supprimer cette fonctionnalité : -supprimer dans recupererPostVar() les 2 traitements. -modifier formulaire() pour avoir directement: $this->val[$champs[$i]] = $elem; On peut en revanche étudier sur la fonction recupererPostvar() ou ailleurs des mécanismes anti-injection: SQL: >entier => intval() >chaine hors SQL => pg_escape_string() >chaine SQL => ne pas activer les contrôles >... HTML / JS / CSS htmlspecialchar(), htmlentities() à mettre en perspective avec la migration de DBPEAR vers PDO, le support limité à PG, ...
Dans ./core/om_formulaire.class.php: -la méthode constructeur formulaire() initialise les champs ainsi: $this->val[$champs[$i]] = strtr($elem, chr(34), "'"); -la méthode recupererPostvar() effectue sur les champs textes des traitements qui semblent initialement prévu pour lutter contre l'injection SQL: Un premier traitement est obsolète depuis PHP 5.4: // Cette fonction a été supprimée avec PHP 5.4.0 et // renvoi toujours la valeur FALSE depuis // @deprecated if (get_magic_quotes_gpc()) { // Supprime les antislashs de la chaîne $value = stripslashes($value); } Un second traitement est d'une utilité douteuse, et perturbe les formulaires (états, lettre-type, sous-état) qui comportent un champ textarea destiné à des requêtes SQL, telle que: SELECT 1 AS "c'est égal à 1"; // On remplace les doubles quotes par des simples quotes ? $value = strtr($value, chr(34), "'"); JE PROPOSE de supprimer cette fonctionnalité : -supprimer dans recupererPostVar() les 2 traitements. -modifier formulaire() pour avoir directement: $this->val[$champs[$i]] = $elem; On peut en revanche étudier sur la fonction recupererPostvar() ou ailleurs des mécanismes anti-injection: SQL: >entier => intval() >chaine hors SQL => pg_escape_string() >chaine SQL => ne pas activer les contrôles >... HTML / JS / CSS htmlspecialchar(), htmlentities() à mettre en perspective avec la migration de DBPEAR vers PDO, le support limité à PG, ...

Commentaires (2)
Pièces jointes
Modifications (3)

Message
Date : 05/04/2017 11:26 Expéditeur : Jean-Yves Madier de Champvermeil Discussion déplacée sur le forum : https://communaute.openmairie.org/t/prop0015-formulaires-abandon-de-la-substitution-systematique-de-par/543
Date : 27/12/2016 19:56 Expéditeur : francois raynaud cp du 09/12/2016 non pris en compte en version 4.5.0

Pas de documents joints

Champ	Ancienne valeur	Date	Par
status_id	Open	05/04/2017 11:26	Jean-Yves Madier de Champvermeil
close_date	Aucun(e)	05/04/2017 11:26	Jean-Yves Madier de Champvermeil
Version cible	4.5.0 [FUTURE VERSION]	27/12/2016 19:56	francois raynaud

Powered By FusionForge Collaborative Development Environment

Charte d'utilisation / Nous contacter / Mentions légales

Haut de page